Current systems programming in unsafe languages has already resulted in many disasters. Rust is too complex to be the language of script kiddies, and neither does the article infer it's direction towards it. Perhaps if devs of old changes with the times we would already had rust 10 years ago.
I write/maintain BSPs and RTOSes for a myriad of embedded systems, every day, for the last 15 years. I can't remember the last time I had a bug like the ones mentioned in the article...
I look at Rust with enthusiasm, but... if they are targeting "system" developers, the ones already doing that job, the last think they (we) worry about is on doing memory management errors. At some point, memory management becomes an automatic process, you just don't think too much about it.
But on the other side, perhaps the scope of a language like Rust is to bring more people from higher layers into developing engines that require performance. The Rust sales-pitch may work on people like a JS programmer but won't click yet on people like me: I just don't want to be baby-sited by a compiler.
I also noticed during my entire life that (reasonable) "fear" that C/C++ produces on developers, and the many recipes for the cure. "Script kiddies" as you call them will never target the C/C++ state-of-the-mind, let alone write system-related software: it just too difficult, and boring, and don't want to deal with truly complicated problems.
You can't solve a "lazy programmer" problem with a "language" solution. I think they're targeting the wrong audience.
> [It] becomes an automatic process, you just don't think too much about it. (...) I just don't want to be baby-sited by a compiler.
Interestingly, as a Javascript developer, I see an interesting parallel here with TypeScript. You hear the argument "TypeScript is for people who don't know Javascript" relatively often - which I think is similar to referring to a compiler "baby sitting". Sure, making sure you use the correct types everywhere and don't rely on implicit type casting is an automatic process for me, but that doesn't mean I'm perfect, nor that it doesn't subconsciously still creates a cognitive load - hence why I still greatly appreciate TypeScript, even though it only helps me with things I supposedly already know very well how to do.
> the last think they (we) worry about is on doing memory management errors. At some point, memory management becomes an automatic process, you just don't think too much about it.
I think the large number of memory-safety bugs in even popular C libraries indicates that this is not the case.
> At some point, memory management becomes an automatic process, you just don't think too much about it.
The thing with Rust is that this becomes literally true. Because the borrowck pass runs automatically with every Rust compile, and tells you where it could not prove that you're managing memory correctly. And yet, the single biggest obstacle for C/C++ developers trying to move on to Rust is that they keep "fighting with the borrow checker", with only a very low understanding of what it would take to fix their code so that it can pass the automated checks. This does not inspire much confidence.
Exactly. But in the "system" industry that reason only is not worth the effort. I already know how to ride a bicycle "by instinct". Why would I use the training wheels again? just in case?
I really hope libraries like libssl and other foundational (but not considered "system") libraries are rewritten in Rust, but also believe that they should not push lower than that (kernel, peripherals, bare-metal).
I'm not sure if I'd compare a type system to training wheels. In general, a type system will be able to tell you that you're doing something wrong, but won't be able to correct it. You're still managing the memory/lifetimes yourself. Something like garbage collection would be more like wheels, since it does the work for you.
I agree; and there's nothing wrong with not wanting to deal with that level of complexity and hair pulling, I don't blame them.
I don't mind Rust either; it doesn't appeal to me, but then many languages don't. If it helps someone move forward, that's a good thing.
What isn't working very well is having Rust stuffed down my throat while being lectured by ignorant assholes who don't even know which side is up. That's going out of fashion fast.
Some of us have been around long enough to see the pattern, go back 15 years and you'll find me preaching the same gospel in the name of C++.
One thing that would help is to stop dumbing down programmers and languages, and start valuing experience and powerful tools again. The full stack developer role is a joke, and not a very funny one.
The problem is that by the time it's warmed up enough to actually run as fast as advertised, the world has already moved on. And when it still doesn't, figuring out why means digging through a giant pile of complexity that you didn't ask for. Thanks, but no thanks; I wasted enough years on Java.
When your life depends on something, nerves will kick in and prevent you from doing well. Ok? I can't find the article on google now, but the experiment was done in India where a worker will be given the equivalent of one year of salary if they can perform a simple tasks. Before being told the stakes were so highly, many could complete, but after being told about the potential reward, almost none can do it.
I know. Just pointing out that it's not scientific. People use that to mean it's important, and hence will bring out your best. But the opposite is true scientifically.
I suggest learning C properly before you make more of a fool out of yourself. It's more constructive, too; because it actually improves your situation. Right now you're just digging a bigger hole.
Should we do a quiz test about which one of us knows C best?
Rest assured, except for the C11 changes to the standard, I do know C pretty well.
I majored in systems programing with focus on distributed computing, graphics and compiler design, so I got to use it a lot, and even teach it to first grade students.
My first job was writing server secure code across Aix, HP-UX, Solaris, Windows NT/2000.
I don't do quizzes, too much code to write to waste time on alpha bullshit. It's not up to me to prove either, plenty of people prefer C, plenty of them more experienced than you; calling them all stupid based on your quiz skills doesn't look very intelligent from here.
That's not evidence, that's restating the claim with more words. (And different ones - your claim was about decent C. There are plenty of experienced C programmers who have been writing indecent C for decades.) Do you have any evidence of the claim?
