The existential threat against C++ and where to go from here - Helge Penne - NDC TechTown 2024

[@BowBeforeTheAlgorithm]

To denote ownership with shared pointers one should use the shared_ptr /weak_ptr pointer paradigm. It seems like the pattern is not well known, but I figured at least one person in that room would have suggested it.

[@muzikleringucu]

Great talk but there are few parts which is kinda misleading (please correct me if I these are wrong) at 9:32, the option _GLIBCXX_ASSERTION(or equivalent macros) is not in the standard so it is not correct to say that c++ has range checking even if operator[]. For example in embedded system, there are different compilers which doesn't support such a functionality. And one thing: isn't it obvious that cpp needs a refactoring? why cpp committee postponing this? are they waiting cpp to vanish? some people will compliant about these ideas because these will break everything but so what? if safety regulation will be released, they must re-write their legacy code. in the end, either refactoring cpp or safety regulation will break everything. as speaker's example for std::span::at, such a basic safety feature had beed rejected. I believe it is time either to switch to different language or get rid of cpp committee?

[@nigelstewart9982]

Bounds checking is not the norm for arrays, std::vector or std::array. Not clear that std::span should be different (and go slower) than those.

[@xybersurfer]

@@nigelstewart9982 the at method of std::vector::at() does have bounds checking

[@naur82]

@nigelstewart9982: but we have at() with bounds checking for all of those container types. Performance cost is not an issue if you have a choice to use operator[]. Why then should std::span be different and not have at()? Even std::string_view, which is conceptually similar to std::span, has this accessor.

[@c2ashman]

Feels like every other C++ talk. Nothing changes.

[@toby9999]

What were you hoping for?

[@c2ashman]

@toby9999 Change, maybe.

[@toby9999]

​​@@c2ashmanMy main gripe is the whole C++ is dangerous mentality. Yeah, so are cars, power saws and knives. Lets have cars that never crash and knives that are never sharp. I've worked for a multinational as a C++ developer for 25 years, including assisting support and product mantainance... it's safe to that 99%+ of bugs are logic errors, not memory issues. Rust and Zig aren't going to fix that.

[@c2ashman]

@@toby9999 I am developing C++ for about 20 years. But you are OK with no automatic out of bounds checks? Or using your analogy, even if cars could be made crash safe, you would still vote for cars that could crash and kill people? Just using your analogy.

[@nigelstewart9982]

@@c2ashman I think C++ requires a level of scrutiny and testing beyond what other languages and paradigms do. I'm happy to do bounds checking for testing purposes but in production, performance matters.

[@simonfarre4907]

And 11:34 an epiphany should have entered the speakers mind. This is *exactly* what you need to do in Rust as well. No borrow checker in the world can save you from that. And ownership isn't unclear, it's 'a + 'b for those two shared_ptrs - rust won't help either. Mutual exclusion has to be introduced in Rust as well, so an Arc and a mutex *has* to be slapped on.

[@alfredomoreira6761]

Yep, but won't Rust force you to use mutual exclusion while c++ would not ?

[@SonOfRamenEgg]

One nugget I think is key 17:00 , is performance vs safety ("correctness"). It is a false choice. If the program isn't correct, who cares how many fippitybits/second it runs?

[@TanzinulIslam]

This is why software testing (with extra-checked debug builds) with coverage reports is important. But in a released production environment all these features will slow down execution.

[@robfielding8566]

The NSA is thinking about hostile code, facing hostile inputs; not so much "great programmers that don't make mistakes". Imagine the nightmares they get from open source; making it into everything.

[@zantrua]

It's been fun as a functional programmer over time watching every language realize that they needed to add lambdas and first class types, and correctly manage capturing the closure on the functions. I'm wondering how long it will take before people realize that they actually need dependent types to correctly express what properties they want to check to the compiler.

[@lajos76nagy]

I applaud the sentiment that memory safety is important but I dispute the conclusion that you can be both safe and fast if you just use Rust. The borrow checker is such a straight jacket in multi-threaded programs that you just end up with reference counting (aka shared_ptr) everywhere. Congrats, you just reinvented garbage collection... a crappy, manual version of it. Honestly, just bite the bullet and admit you can't be as fast as C++ with arena allocation and use Java or Go or Haskell (if you want the Real McCoy and not the knock-off version... aka Rust). C++ can be safer and Rust can be faster, but you will never be as fast as an unsafe language or as fast as a safe language. Deal with it.

[@xealit]

making "security measurable" - there was a talk by Steven Bellovin "Thinking Security" where he opened by mentioning how the main problem with security is that we have security regulations that fix old and outdated practices that don't matter anymore. Probably worth to re-watch that talk.

[@dwight4k]

Great recommendation. Thanks for sharing.

[@gast128]

The first mistake here is that security isn't an issue for everyone. Many applications are local only and not connected to the internet. With use of modern C++ most of above issues are rare or non existing. A compiler / safety profile / static analyzer could even enforce it with extra constraints on C++ use; banning potential dangerous uses (e.g. holding pointers or iterators) and extra checks everywhere. It will certainly hurt performance. For example 11:40 is solvable by using an observer_ptr which gets notified when parent dies (e.g. through boost::signals). Costly but doable and easier than switching to Rust.

[@alfaeco15]

COBOL is memory safe 😊

[@alfaeco15]

What about Ada?

[@BowBeforeTheAlgorithm]

Overall, I'm pretty ambivalent about the talk. Aircraft and car and healthcare-equipment manufacturers achieve safety with C/C++ by using subsets of those languages combined with stringent certification/qualification. Think Misra, various isolation methodologies, or special compilers and checkers...

[@MikhailStrelnikov-q4p]

Only slogans, no specifics. Have you fallen victim to this primitive propaganda, Jimmy?

[@xybersurfer]

who is Jimmy?

[@alfaeco15]

We are just not using the right languages.

[@disekjoumoer]

I don't know. I think employing hackers, i.e. security researchers who actively try to hack your product is a must. I think this sort of applies to any code.

[@fburton8]

Nasal demons?

[@SVVV97]

It's a commonly used phrase. Citing Wikipedia: In the C programming community, undefined behavior may be humorously referred to as "nasal demons", after a comp.std.c post that explained undefined behavior as allowing the compiler to do anything it chooses, even "to make demons fly out of your nose".

[@fburton8]

@@SVVV97 Thanks, that's a new one for me.

[@alfaeco15]

C will outlive C++, so true

[@zantrua]

I don't understand why a replacement language would need or even want to interface with C++, the whole goal is to get away from the existing C++ nightmare as quickly as possible. Interfacing with C or C++ is essentially impossible outside of calling into clang or gcc to ask them what the ABI of a function is supposed to be, and even then they get it wrong sometimes.

[@heavymetalmixer91]

The answer is simple: Without interop there's no smooth transition, and without a smooth transition the answer will always be "NO".

[@zantrua]

@@heavymetalmixer91 I suspect if tech companies were actually held liable for all the bugs that their language choice creates, they'd switch over rather quickly, invariant of the cost. Tech is the only industry I can think of where a click-through bubble that says "WE MAKE NO CLAIMS OF THIS SOFTWARE'S UTILITY OR APPLICATION FOR ANY PURPOSE AND ARE NOT LIABLE FOR ANY DAMAGES IT MAY CAUSE" is even legal, let alone the universal standard of the entire industry.

[@womiro]

First, it's unfeasible to just rewrite a large enough application in one pass. This needs to be done step by step, and for this we need interop. Also, there are just so many useful C++ libraries with years of work in them. It will take some time to recreate all of this software in a new, memory safe language. Until then, we need interop. It's also not all bad: The Google Android team has presented statistics that the largest fraction of memory errors is found in new code, while the rate of CVEs found in old code tapers of exponentially with age. So using a memory safe language for new code while depending on old unsafe code (for a while) is not as futile as it sounds.

[@robfielding8566]

Or theorem provers, and you may not need to change the language; change programs to pass theorem checks.

[@zantrua]

Or just fix the language to have a reasonable type system so that it can have a nice built in theorem checker

[@womiro]

@@zantrua Yeah, that's the catch. It's (next to?) impossible to theorem check unconstrained C++.

[@ronmc1677]

Tons of ads, really annoying

[@janhwillems10000]

Use brave

[@pookiepats]

Oafish to think these talks are about anything other than selling more products, do you think these nerds get funded to put these things together out of the goodness of our hearts? If you’ve ever attended one of these events you know this-there’s a gang of frothy pilled out sales reps waiting in the back of the room; scanning those badges and taking leads back like hunted game.

[@programmer1356]

How about Go where you can (not sure about Google owning it though), and Rust where you must? I've not tried Zig but there are serious users out there.

[@krumbergify]

Go is really productive and fast as well! If your program does a lot of network I/O, then its lightweight goroutine model could potentially outperform a naive use of one thread per connection in C or C++. Sure, it is not thread safe, but you can compile with go build -race and ship it into production and have it trap whenever a race occurs, so at least you won’t run into undefined behavior. The Go toolchain is amazing with builtin support for testing, cross compilation, profiling, coverage and fuzzing. The language is small and really easy to learn. My team became really productive in less than two weeks. I’m currently learning Elixir which runs on Erlangs BEAM VM. It is functional and performs really well. Worth considering if if your application does a lot of I/O and networking.

[@AGeekTragedy]

Zig mitigates a lot of risks (probably more so than Rust with "unsafe") but is unlikely to be considered "memory safe" for the purposes of any coming regulation

[@krumbergify]

@ Exactly. Zig doesn’t claim to be fully memory safe, but it sure is a good upgrade for programs written in C. What I lack with the Zig toolchain is integration with ASAN and TSAN. Valgrind is too slow and covers a smaller scope than ASAN/TSAN/UBSAN.

[@robfielding8566]

Go is a great language for writing web services. It's good for situations where the input is hostile; at least better than trying to do this in C++. Anything with a garbage collector in the core isn't good for real-time code. That's where people move to Rust. Rust is way way harder to use than Go, but you don't have so many problems parsing hostile input. Even C++ could be saved by sticking to subsets and using theorem proving. So much more for garbage-collected languages. But Rust proves a point that you should not make garbage collection required in the core of the language. Any language that can be manipulated well with an AI, makes it easier to do TLA+ like modelling, and GOOD libraries for handling hostile inputs. It's really really serious that if you use C/C++, C++ will die if handling hostile input does not improve. Some scripting languages like PHP are not so good for dealing with hostile input (due to type-guessing); so it's not just about raw pointers. Maybe Mojo. It does the borrow checking like Rust, and it does data paralleism; one of the things that pushes people into C++. It's strange for the government to use language as the way to regulate safety. I thought the free market will chase the best options, given that everybody has to pass the same sort of safety standards.

[@krumbergify]

@@robfielding8566 ”Anything with a garbage collector isn’t good for real time code” Depends on what you mean by real time and if you mean hard real time or soft real time. In some real time applications like games or video streaming it is not fatal to drop a frame once in a while. Erlang has a GC and it was used to create demanding systems like telephone switches and Whatsapp.

[@pookiepats]

Can c++ build an app that eliminates mouth smacking coming through the mic, this should be table stakes by now. It’s *smack* horrifying *smack* honestly.

[@perghosh8135]

A guess is that about 90% av all machine code that is executed on computers are compiled C/C++ code. C++ will not go away... But C/C++ is not for all developers, a small minority and the problem is that these are too effective. Creating code in C++ today it will work +20 years from now. Many C++ developers knows how to create general code that doesn't break because some is adding domain logic or something else that destroys it. And with AI I think that the C++ dominance will increase because AI makes it a lot more easy to use advanced C++ components or add C++ code to existing projects. Because this is a problem, good C++ code is often hard to use and you need a lot of documentation. In this area AI is a great help. Memory is not a problem for the average C++ developer, and it's not about memory. It's architecture. Creating applications and components you need to know how memory is stored and you have to learn that. Most "safe" languages also brings frameworks that developers follow, and this is what they feel is the safe memory problem.

[@dwight4k]

Great perspective. So, it all comes down to skill issues? How to fix that?

[@perghosh8135]

@@dwight4k Well, you are not going to solve it by removing possibilities to train on getting skilled

[@dwight4k]

@@perghosh8135 Maybe there needs to be an external community to do that? I don't know. This language needs skilled people to work with it, because it's not going away anytime soon.

[@toby9999]

There is a lot of irrational sheep-like hate toward C++. Mostly clueless folk who just like making a loud noise. C++ is a great, versatile, mature, flexible, performant language. The whole "unsafe" thing is a skills issue. There is a massive amount of C++ code out there not crashing every day. C++ is not going away any time soon.

[@nigelstewart9982]

I do wonder if AI is ultimately the solution for safer C++. Such as an AI fuzzing framework that torments and stresses software in ways that humans don't have time for.

[@toby9999]

A whole bunch of replacement languages that only solve 1% of the issues, whilst creating a whole lot of new ones. You don't eliminate bugs by throwing away a well proven language. You do that by increasing skills, both in development and testing.

[@daven9536]

Every year they find new vulnerabilities in code that was written and reviewed by the most top notch experts. This is not a skill issue. Humans make mistakes - always.

[@vytah]

You don't need seatbelts, just increase your skills in not crashing your car.

[@gast128]

@@vytah If there is a maximum speed of 20 km/h no serious accident will ever happen. Safe languages come at a cost. C++ requires skill; without that other languages are better suited indeed. C++ can be made safe by allowing only a specific subset but one will pay a performance fee.

[@vytah]

@@gast128 So you're in favour of official C++ licenses that would be required to legally program in C++?

[@gast128]

@@vytah Family of Cathy Newman? You should not program if you are not competent. If you don't know modern C++ stick to Python; C# etc.

[@alfaeco15]

Talking about Safe C/C++ is like talking about safe Assembly language.

[@adrianconstantin1132]

This video makes it sound like C++ is so broken ! Do you really think committee members are too stupid to think about the memory safety ? The NSA people must be quite arrogant to think they found a problem in the software industry, that other people did not find before !

[@robfielding8566]

It's not "arrogance". I know people that can jump into arbitrary code-bases and find whatever bugs they want to find. If you "trust" the developers, imagine the NSA trying to use open-source, when "the enemy" is contributing to everything. They want a language where you can ask a bot to prove that certain problems are impossible.

[@zantrua]

Everyone in the industry knows about the problem, it's why C and C++ are losing devs every day, it's a broken language and always has been and there's no way to fix it without completely scrapping the language more or less. It's not arrogance, it's the feds finally waking up to what specialists have known since the 80s

[@vytah]

15:10 for some info about what the committee thinks about memory safety. Only after everyone started switching to Rust they started thinking about it.

[@gulagz1549]

@@zantrua Literally every piece of software used in writing, sending, and displaying your "C and C++ are broken language" comment was written in C and C++.

[@MrGuardianX]

If C++ trades speed for safety it will become obsolete very quickly. However committee is aware of safety demands and already do some abominations to the language standard in a futile attempt to catch up to Rust or Python. It actually makes C++ worse language. Let NSA have their Ada slow safety and leave speed for commercial software. It already become unforgivably slow despite orders of magnitude faster hardware we have now.

[@alfredomoreira6761]

sean baxter is actually writing a proposal to add the rust features to c++. But you are right, the syntax he came up with is horrible. But hopefully it will change for a better syntax. But at this point, migrating away from c++ is a better approach. No solution will make c++ safer without rewrites anyway.

[@AMSabuncu]

Thirsty

[@Evan490BC]

Drink some water.

[@viktorkot992]

LLVM 😂😂😂= c++ == rust

[@KushLemon]

Baldy blabbering on about nothing.

[@pi5549]

Thank god we've got you here, eh!

[@TheMachina42]

Zig would be a great replacement for C++.

[@SVVV97]

@@TheMachina42 it's not safe

[@TheMachina42]

@@SVVV97 none of the languages mentioned are safe either. There is no such things as "safe software" what's important is the tooling, and the discipline, better languages helps regardless of whether they are interpreted by a jit, or have a borrow checker. I would consider Zig safer than a lot of "safe" languages, because it's very simple in the sense you can inspect and test everything. I would still use Rust for something that needs to be safe imperatively, but it's not bulletproof far from that.

[@testtest-qm7cj]

@@TheMachina42 IIRC "It's simple, hence trivial to reason about, therefore safer (than your higher level language)" is one of the key arguments of C programming language community to defend their beloved language; I think Zig needs other stronger argument for itself if it wants to differentiate itself from others in terms of safety.

[@TheMachina42]

@@testtest-qm7cj That's true, but the real problem with C is simply that it's type system is non-existent, that compilers defaults are terrible, and although UB existed and was used for a reason, There is no reason why modern languages should not actually defined those UB. On top of that the tooling around C is bad, making it even harder to actually make safe code. This is why Rust is so awesome, it provides a strong type system, a powerful suit of static analysis tools through the borrow checker / lifetime annotation system. The defaults in Rust are sane defaults. But the things I've just mentioned are not something unique to Rust, what they are at their core is good tools. Which is why I think Zig is actually a very safe language too, it's not as safe as Rust that's for sure. But it doesn't need a borrow checker and static lifetime annotations to get there. What Zig needs to reach Rust level of safety is simply to provide the tools to ensure that the code is correct and safe. Because the true measure of a language safety potential is not just that it can be safe. C code can be made as safe as Rust, same goes with C++ or Assembly, the reason they are not considered safe, is simply because there is very few tools inside or outside those languages to ensure correctness and safety, and their defaults assumptions are also terrible. Which means that realistically to make safe and correct code in those languages you have to invest a ton more time into proper infrastructure, testing, etc. Which is tedious and means you can't ship as fast, so most companies simply skipped this part. But Zig already provides a lot of tools to ensure safety and correctness, and more importantly those tools are very easy to use and they fit perfectly with the language, if you add that Zig is very strongly typed, and comes with the sanest defaults, has very simple syntax/semantic, provides unit testing, fuzzy testing, has allocators which provides protections against, double free, use after free, protection against any UB because Zig doesn't accept any UB. You end up with a mix where it's actually quite hard to make unsafe code out of the box. It's not perfect and it will improve in the future. But the point is simply that Yes with Rust you are 99% guaranteed that the code you wrote is valid and safe. And with Zig it might be only 80%, but because of every tools provided and how easy they are to use, ironing out the last 20% is actually quite easy. So in practice you can expect safer code than C despite the fact that both languages are relatively similar. Because again safety is not a feature of a language itself, it's a feature of the tools the language comes with to ensure safety (compiler, fuzzer, unit testing, memory sanitizers, sane defaults, not allowing UB to be used by the compiler, bound checking, protection against use after free, double free, use of uninitialized memory, use of null pointer etc.)

[@TheMachina42]

@@testtest-qm7cj Having said that if I were to make some code where I need to be 100% it's safe, I would indeed be more confident to achieve that in Rust. But unlike C I wouldn't discard Zig to achieve that goal, it would probably require some thinking ahead and some really good testing (unit testing, fuzzing, simulation, etc etc) but it's not that hard to get there, and so unlike C it would be reasonable to achieve that goal in a timely manner. Because again that's the main reason C isn't considered safe, it's not because it can't be safe it's simply because it can't be achieved in a timely manner in most scenarios.

[@streetfashiontv9149]

The speaker says that Sean Baxter's Circle as a replacement for C++ is a "good attempt" but then writes on his slide that its 'probably impossible' lol 😂 trolling....