Hacker News Reader

Comment by nicoburns | Hacker News Reader

Right, but it's only recently that better alternatives have become widely available. Previously your options were:

- Something like Java/C#, but that would have required users of the tool to manage a second toolchain / runtime just for developer tools - quite a hard sell for widespread adoption

- C/C++ which are quite hard to learn (and use correctly once learnt) for users of interpreted languages which ends up being a barrier to their use.

Now we have Go and Rust which are fast, compile to a single binary, and are much easier to learn than C/C++, which is leading to a whole new generation of tools.

View on HN

I know a few rust programmers who say that they don't want to learn C++ because it's too hard but I don't know if that's actually true.

Learning C++ legalese takes ages but the basic principles really aren't that hard. It feels more performative than most are prepared to admit.

Rust probably has less bullshit but is borrow checking and macros aren't exactly simple in vacuo either

The main problem I had when I tried to learn C++ was getting started with the build system. I could compile a single source file easily enough but adding others, and especially integrating with 3rd party libraries was difficult. And there was extra pain if I wanted it to work portably across platforms. Whereas with Rust, building is a simple `cargo build`. And integrating libraries is as simple as adding a line to the manifest file.

The borrow checker wasn't trivial to learn, but I could at least bash my head against the compiler, and be pretty sure that once it compiled my code was correct. With C++ it is much harder to get that feedback while learning as it's very easy to compile something that segfaults, crashes, or has Undefined Behaviour.

That's fair.

It's more that, after years of programming in C++, when I run a program I'm still not confident it's not going to have major bugs, and if a bug shows up, I know I'll be in for a world of pain trying to track it down.

After a few months of coding in Rust, I stopped having that problem altogether. I still ran into bugs, mind you, but solving them usually became painless.

Really? Since about c++14, the number of memory errors I've experienced in practice is asymptomatically trending towards 0. When they do come up, it's usually in some awkward C library that has been badly wrapped, and would likely necessitate unsafe in rust anyway. I genuinely can't remember the last time I introduced a memory stomp, use after free, double delete or slicing issue in a modern c++ Codebase.

(Replying a bit late)

It's not about memory safety, exactly. It's hard to convey the difference in how I experienced coding in Rust vs in C++/JS/Python/etc.

The big thing is that the absence of shared mutability means you can be very confident that when you "have" a reference to a thing, you "own" it, and it's not going to change value under you. When a bug came up in a C++ codebase I often felt like it could come from anywhere. In Rust the suspect list was much shorter, which made for a more tranquil debug experience.

(I'm told this is also the experience of people writing Haskell, but I've never managed to read any Haskell code, so Rust it is for me.)

rustc gives you astonishingly good error messages though which helps get through the borrow checking hurdles. And all the toolchain you need is cargo.

I don’t know C++. Does it have tooling that makes figuring things out similarly easy?

Not nearly enough, and the best tools for C++ (debuggers like rr) work just fine on programs written in Rust.

Go is 14 years old

Swift is 9 years old

Rust is 8 years old

Zig is 7 years old

Rust is 8 years since 1.0, Zig hasn't even reached 1.0 yet.

If you compare like for like, Rust started development 17 years ago, as did Golang. Though Rust spent longer in the research project phase.

TBF, when a 1.0 is released doesn't mean it's viable right way for things like this. It takes a certain level of market adoption and ecosystem buy-in first.

Also, Zig still isn't 1.0 so if we're measuring languages from when they first became public, I believe those others in your list are much older as well.

I just took "age" off wikipedia. No bias intended.

Sure, but when these languages first came out they didn't have anything like the library ecosystems they have today. In 2023, you can add a JavaScript or CSS parser to your app with a single line of code. Back then you'd have had to write your own.

Jai is 10 years old and it isn't even released publicly

As if those were the only options.

Reply on news.ycombinator.com