Everything you stated, is literally the reason I said there are caveats, I find it interesting you decided to expand on that, but quoted the second part, pretty much out of context.
Nothing you said is wrong per se, but it’s also not entirely accurate. First, there are very good db connection libraries available to Rust users, with good connection pooling options. Second there are good ORMs if that’s something you enjoy using. Third there are excellent application server options in Rocket and Actix available.
Your comment implies these don’t exist. It’s more the edge cases, and the things outside the DB that will be issues. And even there, you’d need to get into specific areas that would cause issues due to lack of available implementations.
In terms of developers out there that want to work with a language, there’s no better response to that than it’s “the most loved language”, and that may translate to many people adopting and expanding its use.
Rust for CRUD is not a 'Yes with Caveats' - it's a 'No' in all but some very specific cases, and even then it's a 'maybe'.
It's outclassed by other stacks in almost every way for this purpose, and provides no material advantage most of these scenarios. Null safety never was a problem in CRUD apps, and, though performance usually is, it never boils down to 'speed of execution'. And of course, the long list of disadvantages, the most obvious of which is inflexible and slow development, especially in scenarios that require adaptation.
I can't think of a scenario wherein it would make sense for a CRUD app. Some associated micro-services, sure, but not for the core of the app.
That is a very narrow perspective on the usefulness of languages and glosses over all the other reasons why someone would want to use Rust. You do it because you like the language, with the caveat that you may have extra dev work to fill in gaps.
As a Rust dev coming from Java, I will tell you nulls and proper error handling in Java are still major runtime issues, a cause for many rollbacks and emergency fixes.
There is even the promise now with wasm and other tools to use Rust from the bottom to the top of the stack without any compromises (in terms of performance, memory usage, or type safety).
Rust might not be the language for you and that’s fine, but your opinion is not shared by everyone.
> And of course, the long list of disadvantages, the most obvious of which is inflexible and slow development
This claim requires some data to back it up. I know at least a few people (including myself) who are more productive in Rust than in other mainstream languages typically used for CRUDs like Java, C#, Python, Ruby or PHP.
Nothing you said is wrong per se, but it’s also not entirely accurate. First, there are very good db connection libraries available to Rust users, with good connection pooling options. Second there are good ORMs if that’s something you enjoy using. Third there are excellent application server options in Rocket and Actix available.
Your comment implies these don’t exist. It’s more the edge cases, and the things outside the DB that will be issues. And even there, you’d need to get into specific areas that would cause issues due to lack of available implementations.
In terms of developers out there that want to work with a language, there’s no better response to that than it’s “the most loved language”, and that may translate to many people adopting and expanding its use.