11 ms·

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 Type

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.

ThunderSizzle 6d ago
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#?
- apatheticonion 6d ago
  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.
  - za3faran 6d ago
    We've seen several anecdotes where JIT languages (e.g. Java) outperform Rust in throughput and latency in long-running server programs.
    - apatheticonion 6d ago
      Performance isn't really the selling point for me. It's the fact that runtime errors are essentially impossible, making writing, reviewing, testing code very easy. It also means LLMs can spin it out with the compiler, and if it compiles, it probably works. You just need to organize the code.
    - throwaway273748 6d ago
      It is mathematically impossible for a Java program to be faster than a well optimized Rust program, so long as the JVM exists and requires non-zero resources to run (to say nothing of GC etc). This isn't me glazing Rust, this is just the boring observation that a VM language is necessarily going to be outperformed by a language without a VM. VMs have good attributes, but they are never zero cost.
      - za3faran 5d ago
        Key is "well optimized". At some point and scale, it becomes almost impossible to chase those manual optimizations, not to mention that usage patterns at runtime can change in such a way that make such an optimization prohibitively expensive, if not outright impossible. And even then, you would end up matching what the JVM JIT offers anyway. What I mentioned is already something that people have observed for both Rust and C++ against programs written in Java. Now add features like observability, profiling, debugging, and dev productivity, and it becomes a worthwile tradeoff a lot of the time. For constrained environments, GraalVM offers native image.
        deleted 5d ago
        [deleted]
drzaiusx11 6d ago
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.
- apatheticonion 6d ago
  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.
- tcfhgj 6d ago
  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 https://youtube.com/watch?v=4KtotxNAwME
strix_varius 6d ago
> 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.
- apatheticonion 6d ago
  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.
  - throwaway273748 6d ago
    This is giving real "if all you have is a hammer" vibes. I also have years of experience with Rust, but I moved off Rust a few years back simply because I'm sick of the anemic stdlib and lack of mature ecosystem around anything even one inch off the beaten path. Cargo is a shitshow and Rust forces you into an npm-like experience for a whole bunch of functionality that ought to be included in the box. You're juggling libraries with versions like 0.1.2 of which there's seven, none of which are feature complete and five of which are semi abandoned. Then you run into the orphan rule trying to fix or extend any of them. I kind of think some other language will come along, take the borrow checker, take all the type conveniences that Rust stole from OCaml that make Rust so nice, glue it all to a Python/Go/dotnet style fat stdlib, complete with an optional GC for all the things that don't actually need bare metal performance (just stick an arena in stdlib), and Rust will feel like a clunker by comparison.
throwaway2037 6d ago
> From the perspective of high level application development, I can't see a technical use case for a language other than Rust these days. 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.
- tcfhgj 6d ago
  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.
- apatheticonion 6d ago
  I do have fond feelings towards winforms and wpf from years ago, but I can't use it to write cross platform applications. There really isn't anything other than web that covers that use case, sadly. C# still has runtime exceptions and race conditions. With Rust, once you figure out the borrow checker (which is honestly pretty simple), you're at least as productive but with fewer bugs

ThunderSizzle 6d ago

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#?

apatheticonion 6d ago
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.
- za3faran 6d ago
  We've seen several anecdotes where JIT languages (e.g. Java) outperform Rust in throughput and latency in long-running server programs.
  - apatheticonion 6d ago
    Performance isn't really the selling point for me. It's the fact that runtime errors are essentially impossible, making writing, reviewing, testing code very easy. It also means LLMs can spin it out with the compiler, and if it compiles, it probably works. You just need to organize the code.
  - throwaway273748 6d ago
    It is mathematically impossible for a Java program to be faster than a well optimized Rust program, so long as the JVM exists and requires non-zero resources to run (to say nothing of GC etc). This isn't me glazing Rust, this is just the boring observation that a VM language is necessarily going to be outperformed by a language without a VM. VMs have good attributes, but they are never zero cost.
    - za3faran 5d ago
      Key is "well optimized". At some point and scale, it becomes almost impossible to chase those manual optimizations, not to mention that usage patterns at runtime can change in such a way that make such an optimization prohibitively expensive, if not outright impossible. And even then, you would end up matching what the JVM JIT offers anyway. What I mentioned is already something that people have observed for both Rust and C++ against programs written in Java. Now add features like observability, profiling, debugging, and dev productivity, and it becomes a worthwile tradeoff a lot of the time. For constrained environments, GraalVM offers native image.
      - deleted 5d ago
        [deleted]

drzaiusx11 6d ago

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.

apatheticonion 6d ago
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.
tcfhgj 6d ago
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 https://youtube.com/watch?v=4KtotxNAwME

strix_varius 6d ago

> 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.

apatheticonion 6d ago
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.
- throwaway273748 6d ago
  This is giving real "if all you have is a hammer" vibes. I also have years of experience with Rust, but I moved off Rust a few years back simply because I'm sick of the anemic stdlib and lack of mature ecosystem around anything even one inch off the beaten path. Cargo is a shitshow and Rust forces you into an npm-like experience for a whole bunch of functionality that ought to be included in the box. You're juggling libraries with versions like 0.1.2 of which there's seven, none of which are feature complete and five of which are semi abandoned. Then you run into the orphan rule trying to fix or extend any of them. I kind of think some other language will come along, take the borrow checker, take all the type conveniences that Rust stole from OCaml that make Rust so nice, glue it all to a Python/Go/dotnet style fat stdlib, complete with an optional GC for all the things that don't actually need bare metal performance (just stick an arena in stdlib), and Rust will feel like a clunker by comparison.

throwaway2037 6d ago

> From the perspective of high level application development, I can't see a technical use case for a language other than Rust these days. 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.

tcfhgj 6d ago
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.
apatheticonion 6d ago
I do have fond feelings towards winforms and wpf from years ago, but I can't use it to write cross platform applications. There really isn't anything other than web that covers that use case, sadly. C# still has runtime exceptions and race conditions. With Rust, once you figure out the borrow checker (which is honestly pretty simple), you're at least as productive but with fewer bugs