Hacker News Reader

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

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.

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

That'd be a dream to me.

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

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

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.

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.

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;

The rest is just browser optimisations.

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

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.

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.

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.

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.