You're in a Rust thread, I think the general response is going to be, "Yes!"
And I personally, say yes. But that comes with some caveats. You will be entering an ecosystem that doesn't have all the libraries that folks coming from the rich history of Java has, so you will most likely be signing up for some extra work.
But, this is also a great opportunity, because it means that you could be responsible for building a missing library or feature.
"But, this is also a great opportunity, because it means that you could be responsible for building a missing library or feature. "
Ok, so this is an 'opportunity' for some, but a 'big cost' for others.
So remember there are very few Rust devs out there, it is a little bit hard, and though a good chunk of devs might jump at the chance to learn, others, not so much.
It would be a really hard thing to rationally do a 'crud app in Rust' at this moment in time due to all the above reasons. There's a lot of added risk for really no benefits.
If you have a core team that has the skills, ability and is willing to commit to it, then maybe. But we have to think beyond that, when you need another 100 devs ... and people maintaining it ... one can see how other things factor into the equation.
If there is some specific reason and the conditions are right, and if that reasoning is not warped by our own natural tendencies to 'want to use Rust' then there might be an opportunity ... but generally not.
As team members get more excited about 'the problem they are solving' and less 'the tools they use' - you might see an inclination towards other tools, for the most part, at least today, for CRUD-ish kinds of things.
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.
And I personally, say yes. But that comes with some caveats. You will be entering an ecosystem that doesn't have all the libraries that folks coming from the rich history of Java has, so you will most likely be signing up for some extra work.
But, this is also a great opportunity, because it means that you could be responsible for building a missing library or feature.