Programming

I appreciate your answer, but I mentioned systems programming, because I was more interested in languages that do not rely on a garbage collector.

To be fair, Swift uses reference counting instead of garbage collection which has different tradeoffs than GC but does incur a performance penalty.

Software engineer for almost two decades at this point, programming off and on since a kid in the late '80s: Rust is harder. It did seem to get better between versions and maybe it's easier now, but definitely harder than a lot of what I've worked in (which ranges Perl, PHP, C, C++, C#, Java, Groovy/Grails, Rust, js, typescript, various flavors of BASIC, and Go (and probably more I'm forgetting now but didn't work with much; I'm excluding bash/batch, DB stored procedures (though I worked on a billing system written almost entirely in them), etc.)

That said, I don't think it's a bad thing and of course working in something makes you faster at it, but I do think it's harder, especially when first learning about (and fighting with) the borrow checker, dealing with lifetimes, etc.

The availability of libraries, frameworks, tools, and documentation can also have a big impact on how long it takes to make something.

I like Rust a lot, philosophically and functionally... but it is WAY harder. Undeniably very hard.

Just try and do anything with, say, a linked list. It's mind-boggling how hard it is to make basic things work without just cloning tons of values, using obnoxious patterns like .as_mut(), or having incredibly careful and deliberate patterns of take-ing values, Not to mention the endless use of shit like Boxes that just generates frustrating boilerplate.

I still think it's a good language and valuable to learn/use, and it's incredibly easy to create performant applications in it once you mastered the basics, but christ.

C# dev with reasonable experience with java, python, and rust:

Rust is harder

The most manual way is what C does, which is requiring the programmer to check memory safety by themselves.😛

The difference is, Rust will throw a tantrum if you do things in an unsafe way. C/C++ won't even check. It'll just chug along.

Rust is really not that harder than Java or Python.

As someone who's done all three, the fuck it isn't.

If you are familiar with C/C++ best practices to any operational level, those things will translate over to Rust quite nicely. If not, that learning curve is going to be fucking ridiculous with all the new concepts you have to juggle that you just don't with either Java or Python.

There's no situation where you want buffer overruns.

I want buffer overruns in my game consoles for jailbreaking purposes lmfaoooooo

That's one reason I mentioned pass by reference "smart" languages will do it automatically depending on the size of the argument, some languages (including my beloved PHP) even have a copy-on-edit functionality where everything is technically passed as a mutable reference but as soon as you mutate it (unless it was explicitly marked as a mutable reference) it will copy the original object and have you edit the copy instead of the original.

Is being explicit about when copies happen almost always a good thing - yea the overhead of that system is undesirable in performance sensitive situations - but for a high level scripting language it's quite nice.

I get kinda bad vibes from this comment and I'd like to explain why...

If somebody said "We're building a point of sale terminal and to make it secure we're going to be using C++" I'd probably have a dumbfounded expression on my face unless they immediately continued with "because there are libraries we can lean on to minimize the amount of code we need to write."

C++ has an extremely mature ecosystem - Qt is essentially it's own language at this point! There are reasons to still consider building in C++ and saying "C++ is not a language for the future" feels dogmatic and cargo culty to me. Algol, Cobol and Fortran still have programming communities and while I agree that C++ is outsized in presence for the danger it presents there are still good reasons to choose it for some specific domains - high performance graphical programs being one of those in particular.

C++ has a plethora of foot guns and you need to be aware of them but when you are they're easy to avoid in fact your quote:

Even if you tried to actually enforce these habits, you'd just end up inventing a new language and it would be incompatible with previous C++ too.Even if you tried to actually enforce these habits, you'd just end up inventing a new language and it would be incompatible with previous C++ too.

Is probably the thing I agree most with - well built C++ isn't incompatible with regular ol' C++ but it feels like a different language... but as a not too old old-man-developer different projects often feel like different languages - each company/project has tools and libraries they use and it'll cause code written in the same language to read really differently... I'm a functionally oriented programmer with a pretty particular style, my C++, Python, Java, PHP, Node and Rust all look nearly the same except for language specific peculiarities.

So yea, discipline is needed and nobody's default choice should be C++ but if you follow best practices your C++ can be quite safe.

... that all said... I fucking hate the concept of definition files being sseparate from code files so I'm not going to use C++ anytime soon.

And the one you choose is always the one that's weak to the specific vulnerability you didn't think of!

There's always a trade-off. In rust's case, it's slow compile times and comparatively slower prototyping. I still make games in rust, but pretending there's no trade-off involved is wishful thinking