[oblio]

There are many, many programmers, you can see their comments right here, that fit (for many, probably despite their age), into what you could call brogrammer/cowboy coder/lone star/rockstar developer types and that will try to shame developers making mistakes or present certain types of failures as inevitable, "you just need better developers".

You can frequently see them come out in Rust threads, they're generally against it, coming from C/C++, it seems a common attitude amongst low level devs in my experience (there's a thing with "hardware" sounding "hard" which I guess makes them feel more "hardcore").

It's obviously not universal, but it's super easy to find if you search for some programming language discussions.

[salawat]

Okay, that criticism is legit, but they also have a point, and more importantly, they have docs, tooling, and cross-compiling experience. When you're implementing the basic C machine, or kernel, or drivers on which every other tool chain ever conceived at some level relies on for new architectures and hardware, you are operating in the most constrained setting of just about any programmer today. It is different, and you have to think different because you're trying to make sure you're getting the foundation right.

When the docs exist, and are accurate they can somewhat hide behind "get better programmers"; when they aren'the some can be even moreso, because there is nothing worse than trying to drive poorly documented hardware. It either works or it doesn't.

T. QA guy amongst a bunch of dev types who regularly points out how they do a great job implementing the wrong thing on a regular basis, and helps shape process to make that harder.

The fact they come out in Rust threads has more to do with Rust's evangelist types running afoul of the long standing love of "things that work". Somewhat in the cowboy camp's defense, none of theach no guardrail's type ever turns down a good static analyzer or test suite once you figure out how to get it smoothly integrated into their process. That's where I think Rust gets their outreach wrong.

Don't try to sell development on a brand new lang to learn and replace what they are using. Use the lessons you learn with making that lang, and improve the tooling they are familiar with. We don't have an infinite capacity to learn a new lang and library ecosystem every 6 months to just keep doing what we do. Once you get savvy enough with C and where the spec holes are, you've gotten to a point where you've gotten insight into how things actually work many levels more accurately than just about any other programming toolchain, and also onenjoy of the only languages completely divested of licensing lock-in on the planet.

There is also the point that you can'take really argue against C's effectiveness. It's always the first code to be made functional on any new silicon. I'm interested to see if Rust supplant's it, but I'm weary of any language that's heavily reliant on LLVM as I'm getting more savvy on how licensing risk tends to play out in the long run.

You can't beat the immortality and ubiquity of GPL. It is as close to the unrevocable toolbox from the public domain you'll ever get.