Live data from Hacker News

Ask HN: Rust or C or C++ in 2023?

news.ycombinator.com

51–56 of 56 posts

Re: Ask HN: Rust or C or C++ in 2023?

#51

Learn enough C to encounter the pain points C++ & Rust are trying to solve. C is simple, but not easy. Then learn enough Rust to be productive. Then learn enough C++ to interact with the enormous amounts of existing C++ code. Once you know a bit of all 3, decide where to focus based on the work you're trying to do. Rust is the easiest, but least widely supported. C is necessary either way, unless you're working for M…

> C is simple, but not easy. I think I know what you're trying to say, but unfortunately C is anything but simple. The semantics are riddled with surprises of all kinds. It's unlikely the average C programmer has never written a program with undefined behavior, for example.

Yes, I suppose "small" might be clearer than "simple". C is simple partly because of how little of what a computer can do it actually defines. That makes it more difficult to use, but the well-defined language is quite simple. Safe Rust tries to define all of that, so you can do everything the underlying processor is capable of, and becomes far more complex in return.

Re: Ask HN: Rust or C or C++ in 2023?

#52

Earlier quoted context omitted.

> C is simple, but not easy. I think I know what you're trying to say, but unfortunately C is anything but simple. The semantics are riddled with surprises of all kinds. It's unlikely the average C programmer has never written a program with undefined behavior, for example.

> It's unlikely the average C programmer has never written a program with undefined behavior I'd add that the average C programmer can't spot UBs before they cause a problem, they are not your average bug. Unless you're very well read or are just told about them, that is.

> the average C programmer can't spot UBs before they cause a problem

No, the average C programmer probably can spot some UBs, but I think there are many more undefined behaviors than most C programmers realize. John Regehr wrote a series of blog posts about some of the trickier UBs, starting here: https://blog.regehr.org/archives/213

Re: Ask HN: Rust or C or C++ in 2023?

#53
post #30

Earlier quoted context omitted.

> C is simple, but not easy. I think I know what you're trying to say, but unfortunately C is anything but simple. The semantics are riddled with surprises of all kinds. It's unlikely the average C programmer has never written a program with undefined behavior, for example.

Right. But you can fumble through writing a lot of (maybe subtly wrong) C code. I certainly did for many years. You can't fumble through writing Rust. Its an order of magnitude more difficult to learn because the compiler won't compile "bad" code. Unlike C all the pain happens up front. Rust hurts when you're learning it. C hurts when you're trying to debug your program. If you've never written low level code before,…

I'm not sure I agree: the biggest pain point of Rust is that it makes some common patterns from C and C++ non-representable (outside of unsafe). People coming from other languages will likely encounter patterns they are used to that are cumbersome but still representable, with a judicious use of Box, Arc, RwLock, and friends. This means that someone that wants to "just" get something working can implement the same things they were used to, just with a nagging reminder that "they are not being as efficient as they could be" (which annoys a certain kind of people, a category I belong to too). And from this I believe that people that start learning programming with Rust will have a hard time understanding the reason for a lot of its rules, but will not have a hard time following and relying on them. I am convinced that the people with the worst Rust learning experience are experienced low level developers, looking for high performance, that have been experts for so long that they have forgotten what "learning something new" feels like.

With all that said, there are lots of things that Rust could do to make itself easier to learn. I believe it will get there, in time.

Re: Ask HN: Rust or C or C++ in 2023?

#54
post #42

Earlier quoted context omitted.

So my 5k lines of C code project from back in college is all... undefined?

Almost certainly. Of course the only way you'll find out is when you upgrade GCC and it suddenly leaks the contents of your memory to the whole world.

No need to wait for that, running it through valgrind will surely uncover some UBs (but do note that even if it didn’t uncover anything, it doesn’t prove their absence, only that this particular run through the state space didn’t encounter any valgrind looks for).

Re: Ask HN: Rust or C or C++ in 2023?

#55
post #15

The key to any of embedded, system, or low-level programming is as much about learning how the computer actually works to a reasonable degree. You are not programming to an abstract computation model. You are moving bits and bytes around and generating assembly code and talking to the machine at quite a low-level . So while Rust and C++ are higher-level languages with all kinds of nice features to be safer, concise,…

Disagree, C is not at all lower level than Rust or C++. It is much less expressive, but there is nothing that would be possible in C that can’t be done in C++/Rust. Hell, these latter two are even closer to the hardware due to having proper SIMD primitives.

C++ is the de facto “most performant” language for a reason.

Re: Ask HN: Rust or C or C++ in 2023?

#56

Earlier quoted context omitted.

> It's unlikely the average C programmer has never written a program with undefined behavior I'd add that the average C programmer can't spot UBs before they cause a problem, they are not your average bug. Unless you're very well read or are just told about them, that is.

> the average C programmer can't spot UBs before they cause a problem No, the average C programmer probably can spot some UBs, but I think there are many more undefined behaviors than most C programmers realize. John Regehr wrote a series of blog posts about some of the trickier UBs, starting here: https://blog.regehr.org/archives/213

Looking at my own comment a day later and I think I had misread the parent comment as suggesting that "the average C programmer can spot UBs", which I felt the need to dispute.

I dunno how I made that mistake even after copy/pasting, but I did, so I apologize for that.

Post reply on HN