Concur on most interesting! I really hope it works out, but am cautious.

It is surprising to me seeing the rust web backend scene; many libraries, server frameworks, and users, but they are all Flask-analogs, without the benefit of the reasonably-robust ecosystem Flask has. My suspicion is that people are using them for micro-services and not websites/webapps, but I haven't been able to get a straight answer on this about how people are using these tools. I.e. even though rust is my favorite overall language and see no reason it couldn't be used for web work, I still use Django.

Axos, Axum, Rocket, Diesel etc, are all IMO not in the same league as Django. My understanding is that addressing this is Loco's Raison d'etre.

Another aspect of the Rust web ecosystem: It's almost fully gone Async.

> Ruby always drives me nuts how things are just in-scope and we don’t know why or where they came from.

irb(main):005:0> Foo.new.method(:bar).source_location => ["tmp/test.rb", 5]

> I certainly wouldn’t want to go back to working in dynamic languages without typing on top. That takes too much brain power, I’m too old for that now.

> and at times you’re fighting to convince it that a value actually is the type you say it is.

Might just be allocating that brain power to the same task but calling it a different thing.

Are we that far gone that "hand coding" is a term now? I hope there's an /s missing

Doesn't matter because LLMs also benefit greatly from typed code bases in that they can run the type checker and fix the problems themselves on a loop.

TS doesn't "bin off" duck typing, it's a fundamentally structural type system. It's statically analyzed ducks, all the way down - when nominal behavior is preferred, people have to bend over backwards. Either you are using the wrong vocabulary or I don't think you've bothered to actually learn Typescript. In any case, it's the programming language that successfully brought high-level type system concepts like type algebra, conditional types, etc. to their widest audiences, and it deserves a ton of credit for that. The idea that JS and Ruby and Python and PHP developers would be having fairly deep conversations about how best to model data in a type system was laughable not that long ago.

Likely a typo of State Of The Art.

It is easy, and people tend to do what is easy. It takes more effort to minimise dependencies. Your boss or your client will not even notice.

Obviously there are some dependencies that you cannot easily avoid (like the things you mention). On the other hand there is a lot off stuff used that is not that hard to avoid - things like wrappers for REST APIs are often not really necessary.

I was talking about total deps, not direct. By installing something like Celery, you get 8-10 extra dependencies that, in turn, can also have extra deps. And yeah, extra deps can conflict with each other as well.

The issue with that is, that the longer you wait to upgrade dependencies, the more pronounced the problems upgrading it will become generally speaking, because more incompatibilities accumulate. If those 5-6 year old projects were updated every now and then, then the pain to get them updated would be far less. As you point out, security is an aspect too, so you can leave the project inactive, but then you might hit that problem.

The real issue with Rails apps is keeping up with the framework and language versions. There are really two categories of dependencies.

One-off libraries that don't have a runtime dependency on Rails are typically very low-maintenance. You can mostly leave them alone (even a security vulnerability is unlikely to be exploitable for how you're using one of these, as often user input isn't even getting through to them). For instance a gem you install to communicate with the stripe API is not typically going to break when you upgrade Rails. Or adding httparty to make some API requests to other services.

Then there are libraries that are really framework extensions, like devise for authentication or rspec for testing. These are tightly coupled to Rails, sometimes to its private internals, and you get all sorts of nasty compatibility issues when the framework changes. You have to upgrade Rails itself because you really do need to care about security support at that level, even for a relatively small company, so you can end up in a situation where leaving these other dependencies to fester makes upgrading Rails very hard.

(I run a startup that's a software-enabled service to upgrade old Rails apps).

Dependency hell. Usually how it goes is you have to develop a new feature, you find a library or a newer version of the framework that solves the problem but it depends on a version of another library that is incompatible with the one in your project. You update the conflicting dependency and get 3 new conflicts, and when you fix those conflicts you get 5 new conflicts, and repeat.

I agree, but let's say you are looking for a library to solve your problem - you see one repo updated 2 weeks ago and the other one updated 5 years ago - which one do you choose?

I think you could only get around this by forcing your whole dependency chain to only add non-breaking security fixes (or backport them for all versions in existence). Otherwise small changes will propagate upwards and snowball into major updates.

"Security fixes aside" is too dismissive. Transitive dependencies with real CVEs can feel like the tail wagging the dog, but ignore them at your peril.

Indeed that’s what a lot of Elixir and Erlang packages do, if it’s done then it’s done.

Laravel is extremely stable and consistent.

My experience has been the opposite, especially since Rails has included more batteries over the years. You need fewer non-Rails-default dependencies than ever, and the upgrade process has gotten easier every major version.

I also think it's the opposite, since the dependencies are almost guaranteed to be compatible with each other. And I think Ruby libraries in particular are usually quite stable and maintained for a long time.

My medium-sized Django projects had close to 100 dependencies, and when you want to update to a new Django version, the majority of them must be updated too.

Thankfully, updating to a new Django version is usually simple. It does not require many code changes.

But finding small bugs after an update is hard, unless you have very good test coverage. New versions of middleware/Django plugins often behave slightly differently, and it's hard to keep track of all the changes when you have so many dependencies.

There are two types of devs: those that ship and those that fill out surveys (and not because their stacks are so much more efficient that they have time to fill out the surveys)

Rails is definitely older than Django. Django wasn’t released publicly until 2005.

Django had private use before then, but rails was also in private use before it was released.

And for a lot of folks that just doesn’t matter. Paying 50 or 100 USD for a server per month won’t be the thing that breaks you.

Before you get to a scale where Rails become a problem you need to have a product that drives a pretty significant engagement, that’s where most fail.

I'm surprised hiring is tough. The job market is such trash rn and I feel there are a lot of Rubyists, or ex-Rubists interested in returning to it, around. Maybe not? (Edit: spelling)

Not the guy, but I used rails at my old job for one and a half year, and used it in some personal projects. I looked into Elixir(and Phoenix) during this time, and Phoenix felt like it was designed for more modern websites, where RoR is built for older and tries to adapt to handle modern ones. It just feels that when you want to do something more responsive in Elixir, it's designed for it, but in Rails, it feels like you're doing something unorthodox or something that is added as an afterthought. Obviously this isn't quite accurate, but it is the vibe I got.

Elixir is also a very cool language in a lot of ways. I wouldn't go all in on Elixir/Phoenix, but that's because there's not a huge demand for it, at least where I reside. I would 100% consider it for some smaller projects though, if I stood between that and Rails, and I wouldn't mind having to get more comfortable with Elixir.

Edit: I haven't used Rails 8, and haven't followed the ecosystem since a bit before, so not sure how this feels nowadays. I *really* enjoy Rails backend though, but the frontend stuff never quite clicked.

When I first started out with Elixir, it was more the overall architecture that first sold it to me. It is remarkably robust, my impression is that you can more or less yank RAM modules out of the server while it is running, and the last thing which will crash is Elixir. And it is absolutely top in class when it comes to parallel processing and scaleability. Not only how it does it internally, but also how it abstracts this in a way that just makes sense when you are working with it.

When it comes to web development specifically, what really got me hooked, was LiveView from the Phoenix framework. It keeps a persistant WebSocket connection to the client which it uses to push DOM updates directly. Instead of the usual request/response cycle on the client side, the server holds the state and just pushes the diff to the browser. It just made so much sense.

Not OP, but I made the move from Ruby/Rails to Elixir years ago, so I'll try to answer from my perspective.

Elixir is a functional programming language based on the "BEAM", the Erlang VM. We'll get back to the BEAM in a moment, but first: the functional programming aspect. That definitely took getting used to. I remember being _very_ confused in the first few weeks. Not because of the syntax (Elixir is quite Ruby-esque) but because of the "flow" of code.

However, when it clicked, it was immediately clear how easy it becomes to write elegant and maintainable code. There is no global state in Elixir, and using macros for meta-programming are generally not encouraged. That means it becomes very easy to reason about a module/function: some data comes in, a function does something with that data, and some data comes out. If you need to do more things to the data, then you chain multiple functions in a "pipe", just like how you chain multiple bash tools on the command line.

The Phoenix framework applies this concept to the web, and it works very well, because if you think about it: a browser opening a web page is just some data coming in (an HTTP GET request), you do something with that data (render a HTML page, fetch something from your database, ...) and you return the result (in this case as an HTTP response). So the flow of a web request, and your controllers in general, becomes very easy to reason about and understand.

Coming back to the BEAM, the Erlang VM was originally written for large scale (as in, country size) telephony systems by Ericsson. The general idea is that everything in the BEAM is a "process", and the BEAM manages processes and their dependencies/relationships for you. So your database connection pool is actually a bunch of BEAM processes. Multi-threading is built-in and doesn't need any setup or configuration. You don't need Redis for caching, you just have a BEAM process that holds some cache in-memory. A websocket connection between a user and your application gets a separate process. Clustering multiple web servers together is built into the BEAM, so you don't need a complex clustering layer.

The nice thing is that Elixir and Phoenix abstract most of this away from you (although it's very easy to work with that lower layer if you want to), but you still get all the benefits of the BEAM.

I've put together a number of resources here: https://elixirisallyouneed.dev