[DonaldPShimoda]

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

[josephg]

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 wouldn't start with rust. Zig or C are both much better options when getting started. But learning rust eventually will make you a better programmer.

[estebank]

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.

[brezelgoring]

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

[DonaldPShimoda]

> 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

[DonaldPShimoda]

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.

[lmm]

I'd go so far as to say it's unlikely the average C programmer has ever written a program with defined behaviour.

[spoonfeeder006]

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

[lmm]

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.

[kaba0]

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

[SAI_Peregrinus]

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.