Hacker News Reader

Comment by antirez | Hacker News Reader

It's very hard to accept the statement that writing fast programs is now simpler with Go/Rust. I think that what happened is more like this:

* With Go is now possible to write reasonably fast (not as fast as C) programs in a simpler way. That's great indeed, but is not exactly the above statement.

* With Rust it is possible to write programs that have a speed that is comparable to the one of C programs, that are memory safe. So Rust made memory safety simpler, but writing a fast program in C is often simpler compared to writing a fast program in Rust, if we ignore memory safety. Overall Rust made programming harder: something that I'll hardly excuse to it.

EDIT: The blog post was modified, so it only lists "Go" in the section about fast programs. My comment refers to the version of the blog post I read.

View on HN

> writing a fast program in C is often simpler compared to writing a fast program in Rust

I think it really depends on what you need to do. If you need a HashMap or a BTree, getting your hands on high-performance implementations of those structures in Rust is much easier than in C. Also "sprinkling some threads" on existing serial code can be much easier in Rust, using a library like Rayon. But I take your point that designing new data structures and doing unsafe things with pointers can be more complicated.

> Overall Rust made programming harder

This is certainly a matter of opinion, but I like to argue that writing large, correct systems software was always this hard. Rust frontloads a lot of the difficulty, forcing you to handle every error condition, lifetime mismatch, and potential data race before it will even consent to run your tests. When you're first learning Rust, or when you're writing toy code where safety doesn't matter to you, this can feel like an unnecessary burden. But I think we've learned from experience that writing large systems software without this discipline leads to an endless stream of memory corruption and concurrency bugs.

I would agree. I feel like we keep seeing these “software has become more complicated!” blogs. But it’s really just that modern languages/stacks don’t focus on making software development easier for the individual, they focus on making it easier for the organization.

Related anecdote: I have been using GraphQL at work and holy shit it is boilerplate galore but I swear we hardly have to train new hires on how to structure their software to look like ours.

On top of that, our security standards have also gotten higher. No one was worried about corrupt spreadsheets causing segfaults in 1995. But today that corrupt spreadsheet is just as likely to be a malicious file from some attacker on the internet, deliberately crafted to exploit the buffer overrun behind that segfault. Any piece of software that might conceivably touch attacker-controlled input needs to be hardened against this sort of thing.

We're also going to be seeing more and more pressure to make things multithreaded. So so much of the old software was designed back when concurrency just wasn't in the picture. That's why PID reuse races are so nasty in child process management. And why anything that touches the environment (which lots of standard libc functions do under the covers: https://rustsec.org/advisories/RUSTSEC-2020-0159) is unsound in multithreaded programs. Making everything threadsafe is genuinely hard.

I suspect it's pretty hard to make the case that the average Rust program is harder to write than the equivalent C program. I suspect it is quite the opposite. The language provides so many tools that didn't exist in the age of C -- high level concepts like Iterators, destructuring match statements, deriving debug printing for free, etc.

But both of our opinions are just opinions.

Here is the initial version before it was modified.

https://web.archive.org/web/20220220150536if_/https://jvns.c...

"Building fast programs, with Go/Rust"

> Overall Rust made programming harder: something that I'll hardly excuse to it.

Rust isn't much harder than any other language once you understand lifetimes. Non lexical lifetimes made it easier than ever. It's a month of dealing with speed bumps as you learn, and then you're good to go.

Rust makes it insanely easy to write multithreaded applications. I write servers on a daily basis with shared in-memory caches, worker thread pools, async jobs, and all kinds of fun and useful things that I wouldn't dare do in any other language.

I'm developing apps in Rust at near Rails speed.

Would you care to share your library stack for that?

I've sometimes dreamt of trying playing around with building a rust-based web site/app, but then I spend that afternoon reading about different web frameworks, db access libraries, etc. and never really got started.

Given you seem to have a beaten path here I'd love to know what it looks like :)

I think you're point is correct around rust in that writing rust is harder than writing C due to the constraints the compiler places on what you can do. So far I'm happy with this tradeoff because I've had some very gnarly C concurrency bugs that took weeks to understand and debug. If the rustc compiler can point out that I'm doing something stupid and save me two weeks for a bit of pain immediately I'm all about it.

Reading the article and I didn't see writing fast Rust programs as easier listed(only Go). The callout was for sharing data between threads which I think is an area where Rust has the edge over other languages.

Why do you feel that way?

Because the article was modified.

[Note] Another HN user mentioned that the statement was dubious, cited the original statement, got downvoted to hell: https://news.ycombinator.com/item?id=30406644

They got downvoted not because of their disagreement, but because their comment was low quality. "Sure, bud." is a mere quip and doesn't add anything substantial to the discussion.

Good point.

> Overall Rust made programming harder: something that I'll hardly excuse to it.

Shouldn't this also be:

Overall Rust made programming harder if we ignore memory safety: something that I'll hardly excuse to it.

Reply on news.ycombinator.com