Or take the ORM as an example. Doesn't even begin to compare with 2012's ActiveRecord from Rails land. Not to be surprised, as Rails used a lot of dynamic magic that is simply not doable in Rust.
Granted, it's more than enough for a lot of use cases but it wouldn't seem to me like the most appropriate approach for, say, and e-commerce platform in terms of maintainability and time to market. Of course, the performance speedup would be huge on the other hand.
Conversely, active record can’t generate the SQL you can learn in a few minutes in a database class. I’d much rather have highly precise sql serialization and deserialization code and emphasis on minimal client overhead in a systems language than the ability to rapidly spike a data model and query it in the space of a PowerPoint slide.
But then you have also stated the point: systems language, which is the perfect use case for Rust. The original article talks about a "server language", as in application server, and my whole point was that for building business applications this is a weakness, not a strength.
I don’t see what excludes building an application server with a systems programming language. Business applications have maintenance costs that the ORM backloads; it’s not like all businesses need to do this. There’s nothing inherently “business logic friendly” about an ORM.
Granted, it's more than enough for a lot of use cases but it wouldn't seem to me like the most appropriate approach for, say, and e-commerce platform in terms of maintainability and time to market. Of course, the performance speedup would be huge on the other hand.