Hacker News Reader

Comment by tialaramex | Hacker News Reader

> If we accept that Rust is indeed more difficult to learn than comparable systems programming languages

My problem is with "comparable systems programming languages". To me the only thing that fits there today is C++ and while a great many programming languages would be easier to learn than Rust, C++ is not one of them by a long shot.

I think the C++ Quiz https://cppquiz.org/ and the Rust Quiz https://dtolnay.github.io/rust-quiz/ illustrate handily. Neither of these languages is a walk in the park, but, notice they both have "Undefined behaviour" as a possible answer? Safe Rust doesn't actually have undefined behaviour, so you get to rule out one of the possibilities any time you don't see the "unsafe" keyword, which is in fact every time on the Rust Quiz. In C++ some of the quiz questions invoke UB, but good luck correctly guessing which ones.

View on HN

The difference that at same level of let's say "UB bugs in code", C++ code will compile, Rust will not. So person learning C++ will start producing code quicker even if their level of competence will produce more buggier code.

> will start producing code quicker

This will reinforce bad patterns early on which they will have to unlearn through bug hunting or reading about the edge cases and foot guns.

Or maybe it allows them to complete a fun side project quick enough that they keep their interest in programming altogether.

I’ll say that when I started working on finl a couple years ago, I started in C++ (employing 20+-year-old memories of the language). When I switched to Rust, starting from zero, I found myself instantly productive. Yes, there are some things that are harder, but in general, the if it compiles, it works rule holds for Rust. I can still remember some rather disturbing bugs that should never have even compiled in some of my early C code (e.g., treating argv values as if they were variables and could be modified in place).

> keep their interest in programming altogether

Python will do that too and without reinforcing patterns that produce UB.

Although Python is getting long a little in the tooth. It used to be a simple, easy to learn language, but who can honestly claim its async implementation is 'simple and easy to learn'?

I'm curious if there are any newer alternatives that fit in the same niche.

It still is a simple, easy to learn language. But now if you want to do more complex things with it (async), you can.

Of course, that means that it doesn't fit in that niche - it fills it and then some.

They didn't complete it though, if it doesn't work.

There's a wide gulf between "one-off afternoon-long project done for fun" and "serving all traffic for amazon.com during black friday", so I am receptive to the "I can just do this one off thing in Perl". On the other hand I know that once you get familiar with Rust it can be very productive (the "it hurts when I do that" stops when you learn to preemptively "don't do that" and stop fearing "this code is inefficient because it has two extra allocations!!!1") and I've seen too many "weekend projects" become the backbone of large enterprises. Rust's superpower is being able to scale up and down. But the GP might be talking about a project that falls squarely on the former. Anything that starts to move towards the later, I would immediately push for a language/ecosystem more tuned for "maintainability" than "time to first char on screen".

Indeed, I agree.

This doesn't make sense as a metric though.

The goal of software development is not to write code that compiles, it is to have an executing software system that does the right thing.

> The goal of software development is not to write code that compiles, it is to have an executing software system that does the right thing.

But there are many UB-laden, compilable C++ programs that produce the right result, they just are implemented with bad, non-standard, leaky code. Rust and other languages that detect this bad code and force you to remove it are harder to start with, because you need to learn everything to get to a running program.

Interactive development (especially REPLs!) have shown time and time again that it speeds up the learning process. Rust takes the inverse approach imo.

I use debuggers in languages like rust or go very similarly to how I use repls in languages like python. But I do think interpreted languages have a distinct advantage on this front! Which is why rust (or c++, or go) isn't the best tool for every job.

It's worth noting that safe Rust prevents two things. Please be patient with this explanation, as I'm about to butcher it badly (probably not using the right terms):

1) UB - this is when code is invoked. Basically memory mismanagement. We know the signs: segfaults, etc.

2) Unsound code - this is code that has the potential to trigger UB if called incorrectly.

I think this distinction is pretty important. It explains why small projects in c++ can get going so quickly, and they have issues when they grow. You can prevent unsound code from triggering UB, but that of course gets harder to do as a project gets bigger.

In the future as C++ evolves (it had a hiatus of a decade or more where not much happened) it will be interesting to see how it will compare to Rust.

C++ is performance first at any price. Hence UB.

Rust is also after performance, but will specify implementation details where C++ will defer to compiler writers.

I don't think thats correct.. C++ has UB because of backwards compatibility, which has origins to design choices of C in the 70s. Its not like it is optimized for performance above all else, it had immediate needs to be close to metal, and that is the best they could do back then, there was not some "strongly typed" versus "performance" debate happening at the time.

The creator of C++ would love for there to be safer abstractions, but has the baggage of the past to carry.

Modern C++ is still a safety-third design.

std::optional is relatively new, and supports dereferencing, which when it’s empty is UB instead of an abort.

There are no plans to add checks to any existing APIs, because “it didn’t have a branch before” is also considered a compatibility issue.

> C++ is performance first at any price. Hence UB.

I don't think this is entirely correct, C++ in some cases famously preferred ABI compatibility over maximum performance.

C++ has no ABI defined. Did you mean API comparability? Would help to clarify some examples

While the C++ standard does not define any ABI, some implementations (namely GCC and clang) put a lot of effort into maintaining reasonable ABI compatibility. GCC has only changed ABI twice (afaik) and the second time the only thing that changed was std::string!

Nowadays MSVC tries to maintain ABI compatibility too, so we should stop seeing a proliferation of those msvcrXXX dlls.

Haiku uses C++ for its OS ABI so it relies quite heavily on the fact that ABI compatibility stays very consistent across compiler versions for example.

Same applies to Rust, with the difference that there isn't a story for shipping binary libraries, that is why OSes like Haiku care about keeping the ABI consistent, those BeOS applications aren't going to be recompiled.

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p20...

Instead of breaking ABI compat for `unordered_map` why not define a new type given that it's so different? It can even be called the same thing and just exposed through a different namespace version (something that's been supported for a while). About the only thing real is intmax_t. The rest feel resolvable within a library without changing ABI / breaking back compat.

The committee won't change something if the change would break the ABI of one of the big implementations. It's not a formalised ABI stability promise, it's just a result of implementers having veto power and wanting to keep their implementation's ABI stable.

As anyone who has looked at disassembled C++ code can attest, "C++ is performance first at any price" aka "zero-cost abstraction" is mostly a pipe dream. Whatever sufficiently smart compiler was meant to make it happen has not materialized.

> (it had a hiatus of a decade or more where not much happened)

C++11 is almost as old now as C++98 was when C++11 came out. It's evolved plenty.

Reply on news.ycombinator.com