[jesse__]

It's definitely true.

Memory allocation takes a very small percentage of my time. I'd guess < 1%. Debugging memory issues used to take me more time, but these days it's basically inconsequential, too.

Having written interpreted languages previously to jumping to C & C++ (>10y programming exp), there's a massive cost to using interpreted and/or GCd languages that comments like this one never seem to acknowledge. Random package bit-rot, high-difficulty memory leaks, high-difficulty AND high consequence manual memory management (to avoid the GC), poor performance tooling, nearly completely opaque performance characteristics, inability to optimize performance past a surface level... etc.

If you're building anything more complex than simple web apps, this shit all adds up to a lot. I've worked at a couple shops that these issues hit like a ton of bricks.

[pjmlp]

The joy of debugging memory corruption issues on production, while helpdesk keeps pinging dev team several times a day.

Yep, I have multiple scars and gray hairs due to them.

[lelanthran]

> Yep, I have multiple scars and gray hairs due to them.

Look on the bright side: at least you have your hair :-)

I swore off C++ because (maybe coincidentally, maybe not) I started losing hair around the time I was a f/time C++ developer.

I'm liking Go and C# (and some Java and Kotlin, sometimes) these days for programs that are not suitable to be written in plain C.

I've tried liking Python/PHP type languages, but getting a type error only when it is encountered in production gives me the heeby-jeebies.

[neonsunset]

What kind of GC-based languages were the source of issues for these use cases? Was C# among them (in any recent time)?

[lelanthran]

I've not used C# in recent years.

While I actually liked the language, it's complexity is increasing with diminishing returns.

There's no point in getting to a complexity level of, for example, C++ for any language - people who want such levels of complexity will be happy to use C++.

[neonsunset]

While it certainly will eventually die C++'s death (can't remove language features, only add), it's luckily far from that predicament today.

I don't think you could reasonably compare the two in amount of tacit knowledge one has to posses to avoid all kinds of footguns and get best results. The rule of thumb today for C# is to go with simplest way to do something and don't ignore IDE/analyzers' suggestions or warnings. A lot of focus has been put on terseness and simplicity.

[jesse__]

The experience I was referring to was JS, Python and Ruby

[naasking]

Literally all of the costs you list apply to C/C++ as well, except you have the additional hazards of having to worry about memory safety and leaks all of the time rather than only once every 5 years. Sorry, I don't find your claims plausible at all. It's just too easy to forget what you actually spend your time on.

Edit: and the most significant evidence for this is in comparing all the CVEs for C/C++ vs. memory safe languages like C#/Java.

> I've worked at a couple shops that these issues hit like a ton of bricks.

What you're missing is that 99% those shops wouldn't have existed at all if they had tried to go the C/C++ route because their products just wouldn't have gotten to a viable state. What your experience shows is that working in memory safe languages is so much easier that even average or mediocre programmers can get a viable product.

[jesse__]

In my experience, GC'd languages leak much more frequently because people figure 'oh, the GC will take care of it for me.'

There are excellent tools for detecting memory leaks/safety issues in C, and you can even write all your own allocators for your own edification / amusement / sanity, but in a GC'd languages, you're pretty much fucked across the board. There's some tooling, but it pales in comparison to the tools available for C.

I would also like to acknowledge the topic of CVEs you brought up. Yes, mistakes in mission critical systems happen. And for those systems, maybe something with better memory safety features is more productive in the long run. The original comment I replied to suggested C can be surprisingly productive with just a few tools, which I stand by supporting.

> What you're missing is that 99% those shops wouldn't have existed at all if they had tried to go the C/C++ route [...] average or mediocre programmers can get a viable product

Hard disagree. The two places I have in mind hired average/mediocre people to do somewhat challenging graphics work. Both had interesting products that may have actually been viable (think matterport, figma) but both failed because the UX sucked .. due to what can only be described as UI jank.

Lastly, it is easy to forget what you spend time on. I ve been tracking all my bugs that took more than 30 minutes for the last 10 years. The vast majority are graphics bugs due to API misuse. Very few are memory safety bugs, especially recently.

EDIT: also, half the costs I listed were related to performance. How the fuck do you justify the statement that those apply to C? What language would you pick to have more control over the assembly the machine is running.. other than assembly I guess..

[naasking]

> In my experience, GC'd languages leak much more frequently because people figure 'oh, the GC will take care of it for me.'

"Frequent memory leaks" has never happened to me in 20 years of programming in GC'd languages.

> There are excellent tools for detecting memory leaks/safety issues in C

A process you don't even need in GC'd languages. I think I've had maybe a couple of non-critical leaks in those 20 years due to finalizer bugs.

> also, half the costs I listed were related to performance. How the fuck do you justify the statement that those apply to C?

The vast majority of performance issues are related to algorithmic choices. With the right choice of algorithms and data structures, any language will likely get within a constant factor of C.

Sometimes that constant factor matters, most often it does not given the added costs of eliminating that constant factor, eg. in dev time and risk of introducing bugs or security vulnerabilities. And even where it does matter, you're almost certainly better off writing the performance critical kernel in C and then calling into it from a higher level language, as is common in machine learning.

[lelanthran]

> Literally all of the costs you list apply to C/C++ as well,

But we aren't talking about C/C++.

At least, we weren't, but your comments make a lot more sense in the context of C++.

> Edit: and the most significant evidence for this is in comparing all the CVEs for C/C++ vs. memory safe languages like C#/Java.

Wasn't the most expensive RCE the world has ever seen written in Java?