> it may become less attractive for other use cases. For instance, I find it highly questionable to develop a web app in Rust...
I mean who'd want to and why bother trying to support that use case? Basically none of Rust's value proposition exists for a web app while nearly every single one of the downsides do.
Hard disagree. Rust brings a lot to the table for a web app. Compiled vs interpreted makes it easier to catch (syntax) errors beforehand. You can even go as far as compiled templates. Mapping JSON (or whatever) to strongly typed objects is great. Dependency management is best in class. I rather like diesel.rs (although it is very much an acquired taste) especially if you treat it like a safe query builder rather than an ORM.
The single biggest problem I've run into is that there's no real good story for a web app framework (especially since everyone's gone crazy over async). Rocket is perhaps a bit too magical for rust folks and it's been abandoned, but I rather liked it. I've warmed up to axum, but all this async stuff still rubs me the wrong way.
Or Java, F#, Scala, Kotlin, Haskell. If we were to randomly pick a language, chances are it could be a good fit for these — Rust became as well-known as is because it was made for a different niche, where there were no competition.
Hell, even Python can map JSON to a strongly typed object. I am a firm fan of Pydantic and its competitors when dealing with JSON blobs. No-one deserves a KeyError in prod code.
Yeah, I ask because the JVM world has had that since... whenever Maven's central repository came about [0][1][2], I guess, and it ensures that there's no debate about namesquatting [3], nor typosquatting attack vectors [4].
I am constantly baffled that NPM, PyPi, crates.io etc. didn't copy this idea for those last two reasons. In my mind, it's not quite best in class without it.
Although all of those things are true, I think the main point being made is why choose Rust for that, instead of Go, .NET, etc, any of which offer everything you've outlined as being worth having, while having fewer of the downsides of Rust.
To me, one thing missing from most popular web languages is the single best part of Rust: A well-defined handling of the non-happy path.
I'm talking about things like exhaustive "switches", built-in, ENFORCED handling of "missing" values (null, undefined), and finally useful error handling.
I actually don't need any of the baremetal features of Rust. It's just that most of it's "zero-cost" abstractions are still far superior to those of other languages.
They don't, that's the "problem". Off the top of my head dependency management in Go is not best in class to put it charitably. .NET will tie you more closely to Windows. Sure, mono is a thing but you'll have more packages to choose from and fewer compatibility issues running .NET on Windows.
Perhaps. But TS is still Javascript under the hood which means implementation details leak and they smell awful. If they didn't it'd come down to a preference for compiled vs interpreted.
The number one syntactical beef I've is operators. e.g. == vs ===, ""+number.
>"I mean who'd want to and why bother trying to support that use case"
I write my web apps in C++. They tend to be little bit more than just query database / update database. They're exposed as JSON based RPC and can be accessed by JS front end from browser or third party systems we interact with. The performance is stellar and the code size is not much different comparatively to using PHP / Ruby / Python / your_pet_goes_here.
I mean who'd want to and why bother trying to support that use case? Basically none of Rust's value proposition exists for a web app while nearly every single one of the downsides do.