Merry Christmas, friends. And a special cheers to everyone that makes this community possible. It’s one of the last bastions of all that is good about this internet.
I'm using this with a Bun project for my testing needs. I spin PGLite at the beginning, throw it all away at the end. It's not as nice as transactionally isolated testing (a la Ruby on Rails, or Elixir), but it's a fine replacement until I have time to replicate it.
I'd rather use SQL than an ORM. Kysely is basically a wrapper for the SQL query syntax inside typescript which has the benefit of composability and incredibly rich typescript support
I checked it out and it looks good on paper but it only runs on Bun.
Don't get me wrong, I use Bun and I'm happy with it, but it's still young. With Hono/Drizzle/Zod I can always switch back to Node or Deno if necessary.
> But I still needed background jobs, real-time updates, and two-way communication that just works. Those things are possible in Rails and Laravel, but they take a bit more effort to set up.
I'm pretty sure this isn't true at all with Rails. Out of the box you get Solid Queue (jobs), and Solid Cable (real time messaging).
I think what the blog post is getting is OTP and the mystical/but not mystical GenServer / Supervisor/ distributed pattern. It's baked right in there as a core part of the Erlang VM. I think the post glances over the fact that in rails land solid queue may be right there to use (I've not really used rails in over 10 years).
Thing is with Elixir though, yes the tools are right there, but you do have to take time to understand them. I've been on and off with Elixir since 2016 and I'm currently wrapping up on a fairly complex elixir project with zero UI. (connecting Shopify GraphQL to a series of 3rd party fulfilment providers who use SFTP (gross). So yes, GenServer, Supervisor etc are all right there as first class citizens, but whilst they are relatively simple to start using, you can end up with some horrifically structured code that would have been much better written without the distributed stuff.
Personally, I prefer Django. Been using it since 2006 and as a person who started off in design but ended up as an engineer, nothing beats Django's template engine (braces for incoming). Django isn't perfect but nothing is. When I have to get something done quick and there's UI work for me to do, I go to Django. When performance or no UI, I go elixir. If someone else is doing the UI, I go phoenix.
That's also where I'm at. For any project with UI (and auth/auth etc) I went back to Symfony (and Vue). I can't stand Phoenix templating especially layouts and I couldn't convince José of the greatness of template inheritance like with jinja2 in python ;)
But I'm happy running worker type things in elixir & Phoenix if I can.
IMHO Django's templating engine is its worst feature but that only proves how subjective all these matters can be. I'm currently making money both from Django and Rails. I made quite a bit of money from Phoenix years ago. Customers choose their platforms, I can choose customers.
About OTP's primitives, they are great but a background job system has more features than those primitives offer. We wrote a fair amount of extra code to get what we needed for our production system. I'm using Sidekiq in Rails in my current Rails project and it's more feature complete than what we built for Phoenix. I'm using Celery with RabbitMQ in my current Django project and we would like to get rid of it. It's too fragile.
Take it from someone that uses both systems in production, they are not equivalent. Oban is leagues easier to use and obvious than Solid Queue. Solid Queue has no easy way to rerun a successful job, in Oban you can just update some dumb table columns and done, the Oban supervisor will sniff it out and workworkwork.
Solid Queue has a ton of database tables. Oban has `oban_jobs` and `oban_peers`. Oban just runs, simple on the same app. Solid Queue you can do that but it requires reading a lot of obscure blog posts and changing the settings. No sane defaults.
Just as a whole the Erlang and Elixir primitives allow oban to be built truly in the most retarded, obvious way and get away with it. It's wonderful to use as a dev.
Solid Queue I'm bearing because I get other stuff I need from Rails.
I did not mean to diminish the implementation, of course it must be incredibly complex. I meant all that complexity is hidden from me, the developer. It's really easy to understand what to do. :D
Solid cable is quite a bit of setup though,compared to Liveview. The way LiveView manages the rendering for your is leaps ahead of how actual rails SolidCable development feels.
If you go to "Settings > Notifications > Desktop meeting detections notifications" you can turn this feature off. I haven't verified if the mic and traffic sniffing is correspondingly turned off though.
reply