Comment by apatheticonion
10 hours ago
I've been writing Rust professionally for the last 5 years (where my first decade of professional experience started in frontend, then moved down the stack TypeScript/Node, Go, C# and so on).
From the perspective of high level application development, I can't see a technical use case for a language other than Rust these days. If wasm worked (and MacOS/Windows/Android/iOS native UI support existed), I would write my backends and frontends exclusively in Rust.
From a low level programming perspective, the high performance of Rust combined with the self-describing type system makes it very ergonomic to use (trying to figure out how a C function signature translates to behavior is a frustrating experience for me).
The thing I have been most saddened about is the lack of professional opportunities for Rust, particularly in Sydney (where I live). I considered moving to the US for the higher salaries and access to Rust roles but recently landed a role here.
What is wrong with C# and WinForms/WPF? It is an excellent platform to write enterprise desktop apps. Also, developer efficiency is way higher in C# compared to Rust. The language is much simpler, and the VM supports garbage collection. Again: For enterprise apps this is a big win.
Win forms/WPF is essentially legacy, and using C# consumes much more resources than Rust (even for UI, see Windows Reactor C# vs Rust).
Additionally, I don't think C# is that simple anymore. By now it has so many features added and the list is still increasing this day. Rust is more difficult to get productive, but the actual language complexity isnt that big.
LLMS makes onboarding to Rust much easier though if you even still write code yourself. I don't think the productivity difference is that large.
> From the perspective of high level application development, I can't see a technical use case for a language other than Rust.
Bit of a red flag if you really can't.
I know, haha. It's a bit of an absolute statement but as far as all of the features I look for in the context of creating scalable and maintainable software (especially in the age of agent-assisted coding) - Rust has been the most productive, least frustrating language I have worked with.
It's basically TypeScript but runtime exceptions are impossible. If it compiles, it works - so the _only_ thing you worry about is how you organised your code (abstractions, domains, etc) and if the logic is correct.
It saves a lot of time in PR reviews because you only really complain about logic or code organization.
By contrast, C#, Go, Java all have runtime exceptions for things like null pointers and race conditions. That means, when reviewing code, you have to be on the lookout for those things in addition to the logic and structure.
On the single threaded side, TypeScript is great, but JavaScript runtime performance and resource utilization is obscene. With Rust basically being TypeScript but without those limitations (and also natively supporting more frontend frameworks without transpilers), what is the use case for TypeScript (other than legacy software already being written in JavaScript or TypeScript)?
You can write Rust with your eyes closed and it'll probably work.
Interesting perspective. I toyed with rust a bit from the perspective of a c# background (and a bit of java, php, classic asp, JavaScript, typescript, etc) .
I like rust, but I've come to still prefer c#'s object oriented features. Perhaps it's my naivety, but I've found c# AOT compilation to do plenty of trimming and startup performance optimization that I don't see it as a bad option.
Have you made a personal comparison on Rust vs Object Oriented Languages like c#?
From a software design standpoint, it certainly takes some adjustment going from OOP to the compositional architecture and structural trait system used by Rust, but it's not that big a shift.
The biggest downsides are the poor standard library that ships with Rust and the non prescriptive project structure which puts too much authority on the writer to figure out.
The biggest wins are that runtime exceptions and concurrency bugs are impossible. So you can basically write Rust with your eyes closed and, if it compiles, it's probably right.
Due to the high level of trust the compiler gives you, PR reviews (and reviewing AI generated code) is limited to design decisions and logic implementations.
I only really think about architectural decisions, like "this code belongs to X domain, so I should put it in X crate" or "my project should use a hexagonal architecture, does this change violate that? Should I create a package/crate to contain this logic?"
If you don't care about optimisations, a naive implementation in Rust will effortlessly outperform C# and use orders of magnitude less resources, but optionally, the pay off for optimisation is high.
We've seen several anecdotes where JIT languages (e.g. Java) outperform Rust in throughput and latency in long-running server programs.
If wasm worked is a pretty big caveat still. DOM APIs are still significantly slower in rust using wasm than pure js last I checked.
Still, it's fast enough that Rust frameworks can compete with the fastest JS frameworks on UI benchmarks [1]
Imo bundle size is a bigger issue.
[1] https://youtube.com/watch?v=4KtotxNAwME
Yes, that contributes to the "if it actually worked" sentiment.
It doesn't have to be slow, if the browser exposed C-like ABI for DOM access and web APIs like LocalStorage, the FileSystem API, ServiceWorker, etc - Rust bindings can be made and that boundary could be well optimised.
All we need is;
<script type="application/wasm" src="./main.wasm"></script>
The rest is just browser optimisations.