> Honest question: have you ever actually done any (professional) development in C/C++ or Rust?

I did in C and C++ and ran away screaming from them 12 years ago. I am learning Rust lately and I am actively rewriting several small-to-medium-sized projects that I wrote in Ruby or Elixir in the past.

Accidentally, some of those projects have intersections with C/C++ code I wrote ~15 years ago and the Rust code is much more manageable, it's smaller, more understandable (although it has a pretty quirky syntax at places) and I am confident it will be easier to troubleshoot -- if my 18 years in the area are worth a penny. It doesn't carry invisible gotchas between the lines which is IMO the biggest win when you write a lower-level language.

> Also, I'm calling bullshit that manual memory management lacks "safety and sanity". It's harder. You can screw it up.

Correction: you WILL, INEVITABLY, screw up manual allocation, eventually. That's the crux of your discussion with the other guy here. The mental baggage you have to carry in your brain to avoid this is not worth it for 99% of the projects, at least those in my career. None of my customers and employers ever contracted for NASA or gaming studios, so reaching for C/C++ was a huge waste of human time, most of the time.

If you have to write an embedded OS or there's absolutely no way to use Go or Rust to interface with a hardware piece that still has no driver -- and you are the one writing it -- sure, C/C++ are still a good choice (although I do wonder for how much longer; Zig and Rust look better and better with time but I imagine LLVM still has to improve a lot so Rust is useful for OS/driver development).

If not, using literally everything else on the spectrum -- from Rust to Python/PHP/Ruby/Elixir/JS -- will work fine.

> That doesn't mean that the default should be "pretend like machines have infinite RAM and we'll never run out". We're engineers, we make tradeoffs here all the time.

I don't think anyone here said that but I haven't scanned the whole thread yet. You are indeed fighting an [extreme] straw-man in my eyes as well.

> I am entirely aware of how convenient a garbage collector is. I also don't think "helloworld" should compile to be 1MB. We should have standards.

Now we're getting somewhere! :)

We absolutely should be having standards. The problem is sadly very common: everybody is like "my MacBook could handle Python's runtime inefficiency so meh to you old man yelling at cloud, we got work to do". IMO all programming languages should have a natural way to sink to the bottom of popularity if their runtimes are not improved over time.

I am a good example of how people should pick their tech (given no firm requirements from employers, of course). I tried several dynamic languages and made a pick based on my productivity, the helpfulness of the community, the average quality of the libraries, and the technical prowess of the runtime. I do wish it had a shorter bootstrap time but hey, it's specifically made for servers so I can swallow it.

On the other end of the spectrum, I'd like to make a comeback in the very fast low[-ish] level languages so I am learning Rust. I know I can gain extra runtime speed (and maybe memory efficiency but that's not a given) if I go back to C and C++ but I'd like to balance out productivity with stress and overall ability to get shit done. And especially important: not join tribes that yell "real men use C++!", I am sick of that crap.

---

I don't think you and the other guy actually disagreed but kind of got hung up on a few minutiae.

I also believe we indeed should have standards. (Which means software like Slack should not be used at all.) But we all know that writing compilers and optimizers is pretty damn hard.