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

[@dbug64]

Alternative fictitious video some decades back: "MS-DOS is dying - How to utilize your hard-earned loadhi+TSR skills in a new landscape"

[@bobweiram6321]

Ada, introduced back in the 80s, already solves all of these safety issues while still being fast and efficient.

[@chrismcgowan3938]

As an Ada programmer for almost 10 years ( mainly the 1990's) Ada had some serious flaws. #1 was the time it took to write and compile and #2 rendezvous , whilst a good idea had HORRENDOUS overheads for any real time system, #3 variant records, quite mad. Causes random errors however days or weeks after running. And finally #5 Exceptions. The worst and slowest exceptions of any language. Any real time embedded system had to ban the use of exceptions, and possibly have a try catch in EVERY function. Nice things. 1# very strict typing (too strict sometimes) #2 Can print out enum value names, #3 no inheritance until someone added into Ada95. Ada Tasks were very sensible. The best feature was that you could add C code -- This is how I learnt C and still use it to this day.

[@paherbst524]

@ t might have gotten better since the 90s. its been updated several times, is now part of gcc. and variant records rock!

[@bobweiram6321]

@ Unfair comparisons. 1. Sounds like you were using a bad compiler. GCC GNAT builds as fast as the C++ version. 2. Never heard of rendezvous. 3. Variant records or discriminated unions have been adopted in other languages, including Rust and Swift as optionals and or parameterized enum types, and C++ through templating. It's a powerful construct and elegantly solves a lot of problems. 4. Sounds like bad programming or again a really bad compiler. 5. Exceptions work fine, but are not recommended for resource constraints devices. In any language, including C++, exceptions handling across function calls are costly. Oddly enough, C, your favorite language doesn't even support it. Ada isn't perfect, but most of the criticisms levied against it are made by lazy, undisciplined, poorly trained, cowboy programmers who write shoddy code. It is a comprehensive language well ahead of its time with lots of bells and whistles for addressing a wide range of domains. It's one of the many reasons it survived along with its safety and reliability. It's not the sexiest language, but it runs satellites, airplanes, nuclear power plants, air traffic control systems, and medical devices.

[@tserica]

Ada did some of this very well, but it never really caught on. And it's probably a worse successor to C++ than Rust is.

[@lars-ovekvalstein9294]

I have to agree. The real strength of Ada, is the strict compiler and type safety. - and readability of the code. What about SPARK? Both should receive renewed attention when it comes to safety of software.

[@alfaeco15]

COBOL is memory safe 😊

[@Orion2349]

Can't have memory errors if you never allocate memory. *taps forehead*

[@alfaeco15]

​​@@Orion2349memory errors are possible in C/C++ even without allocating memory, just write beyond límits of statically defined array, or assign arbitrary value to s pointer and write to it.

[@petarpetrov3591]

THIS !!!

[@foobarf8766]

@@Orion2349 can't have memory errors if the hardware features memory tagging either, intel and amd missed that boat

[@ariesmarsexpress]

The internal security teams at companies all over the world will read those NSA papers, and they will make it a requirement to shift away from memory unsafe languages. It's pretty much the same thing as regulation.

[@thecollector6746]

LOL...not they won't. 1. The VAST majority of software written in both the Public and Private Sectors has been implemented in GC'ed languages for the last 30+ years. 2. Having worked in and out of IT Security for the US Government I can assure you that there is already approved lists of programming languages that are allowed for software implementation.....that getting an exemption for is nearly impossible. 3. No one is going to be re-writing anything that is non-trivial in scope and size...especially if it is "mission critical". The best you could hope for is implementation of secure code practices for any further maintenance and feature additions.

[@actualwafflesenjoyer]

@@thecollector6746 the world doesn't change on a dime, and rewriting "hardened" systems is unrealistic. however, in this age of interconnectedness and near-constant state of "cyber siege" by hostile state-sponsored attacks, this is an increasing concern.

[@saulocpp]

Meanwhile, that stupid C++ committee keeps cramping useless junk to make is "generic as possible". They will probably "solve" the memory safety problem with a virtual machine.

[@hrmIwonder]

Generics are cool and all and should be there, but in my experience they tend to be most useful for library/framework type code, which most of us aren't writing day to day(we're using libraries and frameworks).. now the committee is doing a ton of work to do compile metaprogramming, again mostly useful for specific things that most of us don't do..

[@pn2543]

I feel so blessed to have retired from a career in embedded software engineering having never had to learn or use C++ or C#, my sincere condolences to all those programmers still suffering with them.

[@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.

[@FluffyFluff-yj8tg]

Rust for example doesn't do dependent types. Affine types do the job just fine.

[@bryanedds8922]

dependent types are massive overkill, even for functional languages / programs. The juice ain't worth the squeeze.

[@zantrua]

@@bryanedds8922 They're as simple as system F if you want them to be, you don't need to formally prove every property you care about. It's a strict upgrade that gives you more power where you need it, but gets out of the way when you don't.

[@zantrua]

@FluffyFluff-yj8tg Affine types help, but why not have both? Idris has both, so it's certainly possible.

[@iilugs]

What are these dependant types you mention?

[@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.

[@carstenrasmussen1159]

A lang which was not mentioned is D which is now 25years old and which covers a lot mention it even have a borrow check maybe it still needs some work and it also has subset language named betterC which can be used for MCU without the drunrime

[@edgeeffect]

I got interested in D for a bit and thought it was quite interesting but the "programming bros" that I showed it to just weren't the slightest bit interested. I don't understand WHY no one else was interested but one thing I can be sure is that most people just don't like D. :(

[@CN_SFY_General]

C++ is C with more facilities; C is a portable assembly language. Nothing will change. It will be a new language if someone tries to change it; this creates a new programming language.

[@zantrua]

C++ changes all the time. C does too. The compilers change things, then the "standard" retroactively covers the changes and makes them "official". No one is writing C89.

[@MrGerdbrecht]

It does not change, you can write C++ 1998 if you like, it got enormous additions of syntax and features. This community is just awesome. Most of them are much cleverer than me and i have a high salary living thanks to them and the internet. I contribute to free open source to say thanks to all of them.

[@CN_SFY_General]

@@zantrua The nature of C is a language close to metal: this characteristic will not change.

[@Jianju69]

@@zantrua This is why I avoid C++; all of these different ways of using it are just too confusing. I'm working in Rust and find it to be a much sounder design.

[@zantrua]

@ What metal is C close to? Do you run a PDP-11, because that's what C was designed for. C looks absolutely nothing like how CPUs work now. Also, if you want to talk to the CPU, just use assembly(which you end up doing in C anyway) and bypass all the complexity of C.

[@NotherPleb]

Very happy to see Sean Baxter work here! But after the 5 year android report, he gave up on that idea, he also reached the conclusion that the path to memory safety is not making the language safe but to write new code in safe languages.

[@isodoublet]

Sean Baxter's whole thing is to try to destroy C++, lol. He didn't "reach this conclusion", he preordained it.

[@isodoublet]

Of course he "concluded" that, his entire goal is to destroy C++.

[@NotherPleb]

@isodoublet yeah, a guy who built his own compiler of C++ must really wanna destroy it

[@tivorum]

I wonder what is the reasonable roadmap for the embedded programmer (beginner), since the industry standart is still C/C++, which is reflected in the tutorials, techdoc, textbooks? How do you learn to use, for instance, Rust with, say, ARM or C8051 or whatever else for real time development if you are a beginner?

[@foobarf8766]

I think memory tagging is the answer (rather than dumping C/C++) could even say IBM 'solved' this on Power 30 years ago, ditto Intel Itanium / HP-UX. Good to see ARM are bringing it back on the new Apple silicon.

[@davidboreham]

Burroughs machines from the 1960s.

[@Nesbiteme]

No matter how "great" a C or C++ programmer you think you are if you never woke up screaming in a panic in the middle of the night over some memory management issue you may or may not have overlooked then you are NOT a C or C++ programmer. But if you do then you are, no matter what the language of the day is, you are a programmer!

[@christofferlerno]

People are raising Zig here as an alternative, but while Zig has sanitizers built in, but also embraces UB in release mode and deliberately picked less safe alternatives than Rust (look for example at how overflow of a + b is handles in Rust versus Zig, Rust is much less aggressive and unsafe in release mode). Other alternatives to Zig, such as C3 and Odin bring their own additions for safety that Zig does have: C3 with pervasive contracts, and Odin with no UB and checks also in release mode, opting for safety by default to a much higher degree than Zig. So Zig is actually the worst alternative for safety when comparing alternatives.

[@scorpia3215]

Zig has a release mode with safety checks: ReleaseSafe.

[@jameskingcodes]

From what I understand some UB is necessary in order to reach all possible hardware targets. There's not much software can do when the hardware has edge cases.

[@christofferlerno2633]

@@jameskingcodes Zig is adding UB where even C doesn't have it.

[@christofferlerno2633]

@@scorpia3215 Well, then Zig has to decide, either it's about as fast as C/C++/Rust/C3/Odin and is unsafe, or Zig runs with safety on and is not competitive with them. 1. Unsafe and fast 2. Safe but slower than the alternatives Pick one.

[@scorpia3215]

@@christofferlerno2633 Actually, you can pick both. You can set safety on a function by function basis. So you can choose for the most critical parts of your code to be as fast as possible with no runtime checks, then turn the full set of runtime checks on for the parts of your code dealing with untrusted data. Zig doesn't have to decide, it gives users the tools to decide.

[@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.

[@rawpointer]

And it's atomically thread safe, and operations order safe.

[@BowBeforeTheAlgorithm]

@rawpointer 100%

[@zactron1997]

Speaks volumes to the magnitude of the C++ safety issue. It's all well and good to have safe options in C++, but if they aren't enforced they're largely pointless.

[@dminik9196]

@@BowBeforeTheAlgorithm It's not so simple (of course nothing is simple in C++). There are cases in which weak_ptrs can keep the object alive even if all shared_ptrs are gone. Not to mention that due to C++ move semantics you can still get use-after-frees (or rather nullptr derefs) from unique_ptrs (and shared_ptrs too I think).

[@BowBeforeTheAlgorithm]

@@dminik9196 @dminik9196 weak_ptr is designed to check whether the shared_ptr it refrences is valid before accessing. After accessing, it can ensure that its shared_ptr remains valid during the access. After the access ends, the shared pointer, if there are no other references to it, is cleaned up.That's the point of weak_ptr... Use after free errors with move in unique pointer? Your assertion is ust wrong. The standard explicitly states that if I std::move a unique_ptr (example up2 = std::move(up1)) then up1.get() will return nullptr after the move. So the only way we're getting an error is if we blindly use up1 without checking its validity first. Unique pointer doesn't exempt us from needing to check the validity of pointers before using them.

[@rokker333]

Everything was already there in the past. ADA, certified compilers and tool chains etc. All these regulations do not really help. Still the Ariane 5 blew up and on the other side people were brought on the moon with "non-safe" SW. It is all about the engineering. While I still think having certified compilers and tool chains are a good thing.

[@milaro222]

In which areas does the notorious memory safety matter at all and what proportion do they represent? Wouldn't it be the case that for 99% this problem doesn't matter at all?

[@zantrua]

It's responsible for 70% of the bugs at Microsoft and Google. It's a huge problem. There's several entire classes of bug that are unique to C/C++ becuse they have manual memory management, and they're super common(use after free, double free, etc). Anyone who believes they can write correct manual memory management code either has a very simple program or believes they're smarter than the combined forces of Google, Microsoft, and the Linux Foundation, all of which have had major bugs caused entirely by failing to manage memory correctly. If you want to see what it takes to actually get correct output from a C program, look at seL4, it's the only C program I know of that actually comes with a top to bottom proof of correctness

[@zantrua]

It's a huge problem across all software, it's 70% of the bugs in Chrome for instance.

[@defeqel6537]

It's a big problem actually, but much of it boils down to things we already have an answer for in C++, but which just aren't used; buffer overflows and such. Use-after-free is perhaps an issue that is not totally solved, but proper use of smart pointers goes a long way. (btw. use-after-free also still happens in Rust)

[@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.

[@freedoompictures6839]

Memory safety issues can be fixed in hardware too. Out of bounds can be checked in hardware. All pointers can be made unique by naming them in hardware.

[@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.

[@nigelstewart9982]

@@naur82 Ah, indeed. at() is there for string and vector bounds checking. Thanks for the correction. Alas for performance reasons we tend to avoid and discourage the use of (built-in) bounds checking. I don't mind that it's there, but it feels vaguely like garbage collection - a hidden cost. In debug mode, sure. In production, no.

[@petarpetrov3591]

it is correct to say vector.at() is the range checker ;)

[@halneufmille]

When C++ was released, people didn't care too much about drunk driving or wearing seatbelts. Those good old days of recklessness are truly gone.

[@RobertFletcherOBE]

thats not a good comparison. the risks that make memory safety an issue were not clear when C and C++ were created. They were made in good faith with the limitations of the time.

[@oysteinsoreide4323]

Even C# done incorrectly is not memory safe.

[@paherbst524]

Ada ftw!

[@bobweiram6321]

Yup!!!

[@h..h]

Only valid alternatives to cpp i have seen so far, are circle and go...

[@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.

[@zactron1997]

Exactly. It's trivial to make a correct solution fast compared to making a fast one correct.

[@SonOfRamenEgg]

@@TanzinulIslam I'm not against debug builds for specific reasons but as you pointed out performance changes in production. And it is production where you really care because it is... Production. So in the scenario you describe, the debug builds will only "tell" you so much because it isn't the true runtime system. Better to get confidence in the design rather than extrapolations from debug builds.

[@titfortat4405]

Safety and correctness aren't the same thing; you can write sound software using unsafe constructs. That being said, you can also correctly shave your beard with a steak knife. You might do it right the first 1,000 times but it only takes one mistake to regret your choices.

[@zactron1997]

@titfortat4405 Exactly. And when you're in the business of making shaving kits that up to 8 billion people across the whole planet could be using, 1 in a 1000 tends to happen a lot of times....

[@xpusostomos]

I'm curious, what are all these applications that can't cope with garbage collection?

[@juliantinao8278]

All the "real time" ones...

[@xpusostomos]

@juliantinao8278 which are... ?

[@nutellaj1778]

​@@xpusostomoskiller drones, terminator t-900, unmanned flying chainsaws and etc.

[@bryanedds8922]

drivers and OS kernels

[@ziotom78]

Complex videogames

[@romangeneral23]

What existential threat ? There is literally millions upon millions of new C++ code being made every year. It is not going anywhere. That being said if I may have a moment about Zig. As a C++ developer I have given Zig a good run and I must say it has massive potential as one of the future languages to use (Once it reaches 1.0). This was a good talk but sorry I do not think there is an existential threat to C++. Bjarne said himself that the language can be written in a "Memory-Safe" way. The issue is the literal billions upon billions of existing C++ code that is running the infrastructure. The slide about the NSA saying you must move away from C/C++ and to memory safe languages honestly is complete BS. U.S. government moves at slower than a snails pace and by the time you get any sort of movement going. The administration (politics) change and you back to square one. The rust cultist love to use that NSA report as proof that C/C++ is dead and rust is the future. But from what I have seen and coded in rust. I do not see that happening anytime soon. Excellent video!

[@JeremyWall]

The reason I think you are wrong is because I don't trust anyone including Bjarne to consistently write C++ in a memory safe way even if it's theoretically possible. And the larger the codebase the less I trust the developers to do so. This is why in practice 70% of the highest impact security issues are still to this day memory safety issues.

[@SVVV97]

@@romangeneral23 Bjarne of course says that - he's been sticking his head in the sand for a good while now.

[@foobarf8766]

That is the question... I thought it was a white house report talking about Rust? That carried no legislative weight. Not actually an existential threat from the NSA, the NSA just made recommendations (and fair enough they must see some shit). Same time that report came out the white house was also having it's arm twisted into accepting blockchain scams, which might explain a lot.

[@Zel-kr3qj]

Sigh, did you actually watch the video? The presenter quoted multiple reasons -- policy makers are sending signals about memory-unsafe languages, Google/Microsoft are writing/porting safety critical code in/to Rust, among others. You can blindfold yourself and keep thinking "I do not think there is an existential threat to C++", but the world does not revolve around your beliefs, and in fact, if anything, things are changing, and not in the way you think is going.

[@RustIsWinning]

Zig could never. Yoda is clueless deluxe as always 🤣

[@DiscussIT_137]

New languages need to support 1) built-in read only and thread-safe arrays/collections, 2) offer garbage collection but allow programmers to force collection of known references and allow non garbage collected instances, 3) have in mind that AI will write code, so auto translation into a higher level editors are needed to understand/tweak code

[@alfaeco15]

What about Ada?

[@jakubpavlik2961]

*Eiffel joins the party* (of established memory-safe higher-level languages without serious hope to get traction in C++ circles)

[@ZenoLee0]

Biggest question is the quality of community edition GNAT, otherwise, you are dependent on a private company, AdaCore, which puts you in the same position as Swift and Go.

[@gautierdemontmollin3753]

@@ZenoLee0 There are other Ada vendors, notably PTC (ObjectAda)

[@RustIsWinning]

Nobody knows what Ada is 😂

[@alfaeco15]

​@@RustIsWinning 😅

[@fernwaerts]

I truly believe that C++ will become a legacy language such as COBOL. The syntax and feature set gets more complicated with each release while the fundamental problems with the language and specially the ecosystem is not changed. Best example is the build system which is awful compared to other languages. Try to convince a novice to learn an entire new language (cmake) just to compile your program. And C++ claim to always be backward compatible bloats the standard with every iteration. Sure it becomes easier (to some extend) to write c++ with the modern standards but on the otherhand you will have large code bases using older standards therefore you need to know and understand them as well. And for me the steep and long learning curve of c++ is not worth it for what it advertises: Speed. You can see this shift: While new programs where written in C++ only some years ago you'll see more and more emerge written in Rust or (to some extend Zig). Good news though is that we have a loooot of legacy software written in C++ so our jobs are safe for the next ~20 years :D

[@JaapVersteegh]

Big weakness in the arguments here are that there appears to be the implicit assumption that memory safety implies safety. Not true, as Herb Sutter nicely explains. Although memory safety is very important and should be addressed, it in no way guarantees software safety, so switching to a memory safe language will not magically solve your safety issues.

[@pacukluka]

good talk with proposed solutions and alternatives.

[@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 ?

[@droggisch]

Not Arc and Mutex, Rc and Refcell are enough depending on the threading model, and way cheaper than shared_ptr that is necessarily thread-safe. Rust - by being strict here - also encourage other patterns that are inherently safer. And more costly to implement and maintain. But still safer, and that’s the context here.

[@edgeeffect]

I wish he'd mentioned Zig and Odin. Partially because I'm a fanboy but mostly to hear some empirical arguments for why they might not be what we're looking for.

[@williambyrne6855]

resource guardrails are antithetical to C/C++ and the functional tier the language most effectively serves

[@ruslankhl]

And what about memory safety for assembler? Is it memory safe? Why author dont provide same issues in other safe languages, like he did with smartpointers example? What is the situation with the safety of knives and forks? In some scenarios, spoons are also unsafe.

[@alfaeco15]

C will outlive C++, so true

[@CN_SFY_General]

C++ is C with more facilities; C is a portable assembly language. Nothing will change. It will be a new language if someone tries to change it; this creates a new programming language.

[@alfaeco15]

"C is a portable assembly languafe" totally agree. And let it be just that.

[@isodoublet]

"X language is bound to fail because it doesn't put on a pedestal this one design goal that I personally like" Presenter is fundamentally unserious.

[@Argoon1981]

Totally agree.

[@DomainObject]

“Memory Safety” is more than a “personal like”, is is an essential property of a modern programming language. A property that C++ does not have. As an engineer, that should not offend you.

[@isodoublet]

"is is an essential property " In your opinion.

[@alexeykononov5596]

As usual, there are always other ways - like using memory-safe guidelines (of course, this limits the subset of the language to some extent) and complete safety without even thinking about security is wishful thinking - you need to care about security in any language.

[@jamanjeval]

This is what happens when you give users all the power to do nearly anything even if it means being able to do the wrong things for the wrong reasons. A huge problem is that C++ tutorials don’t start by teaching memory safe approaches, they default to the “simple and standard” way of doing things. This has long been a problem where c++ was just taught as if it were just C with “some other stuff that makes simple things harder to do”

[@afterthesmash]

Life in a democracy gives citizens the freedom to do nearly anything, even if if means being able to do the wrong things for the wrong reasons. C++ is a statically typed language. It's already enforcing most of the "thou shalt nots" from the 10 commandments. If you use the Modern C++ subset, you never even touch malloc/free. If you use RAII you never have uninitialized variables. C++ is not the wild west with no sheriff in town. It has rules, but the rules are rather Libertarian. It doesn't prevent you from owning a gun merely because you can hurt yourself by owning a gun. Many governments do prevent their citizens from owning most types of guns. Most of the modern tutorials *do* start by teaching the almost entirely memory-safe Modern C++ idiom.

[@ChrisJackson-js8rd]

Operationalizing memory safety as "was this code written in a language other than Rust?" is highly problematic. Appropriate defaults will make our code safer, but it is not going to be caught by the current metric. Better tools to quantify memory safety are essential despite being non-trivial to development and implement.

[@MrWorshipMe]

Instead of a unique ptr and raw ptr, use shared ptr and weak ptr. This preserves the ownership but indicates to the non owner when the pointer is no longer valid.

[@CN_SFY_General]

It is crazy to talk security with about C, C++. These two languages are designed to be as close as possible to the metal of the processors. The processors are designed to execute codes efficiently. The safety of the programs depends on the programmers to write safe code. The languages shall not do anything in place of the programmers. If you want any people without much of knowledge of programming to write safe codes, use Java or C#, or python, smalltalk. Or you ask to have safe processors, or hiring people knowing how to write safe C, C++ codes.

[@zantrua]

Programmers are not capable of writing correct manual memory management code. Saying "skill issue" doesn't explain how Google, Microsoft, and Linux all regularly fail to correctly implement memory management and have security bugs as a result. People's brains did not evolve to verify the correctness of millions of lines of abstract logic, but we made computers specifically for that task.

[@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....

[@gauravtejpal8901]

Something fundamentally 'unlikable' about this dude

[@RustIsWinning]

Nobody asked guaraf teipal 😂

[@edgeeffect]

I love his comments about the "fanatical religion" in certain parts of the Rust community... It made me actually laugh out loud.

[@PanzerschrekCN]

Look for language named Ü. It's memory safe, doesn't use garbage collection and has nice C interoperability.

[@ronmc1677]

Tons of ads, really annoying

[@janhwillems10000]

Use brave

[@RustIsWinning]

Get premium mr broke

[@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...

[@mileselam641]

*Boeing 737 Max has entered the chat

[@BowBeforeTheAlgorithm]

@mileselam641 A comparison between apples and oranges has entered the chat.

[@khhnator]

@@mileselam641 the boeing 737 MAX was not a code issue, it was a design issue. the program worked perfectly, it just was made to do something stupid

[@BowBeforeTheAlgorithm]

@@khhnator I couldn't have said it any better myself. I should have been nicer and explained, but I was feeling a bit snarky at that moment.

[@foobarf8766]

This is a little-endian Intel and AMD problem, Power and ARM have memory tagging extensions. Of course the keys for tagging then become the target, but it's not the software engineer failing at that point and the CPU manufacturer needs to fix it.

[@xamidi]

I will still write C++ in 50 years (given I'll still be alive), memory safety doesn't affect me in the slightest. It is only relevant to bad coders. There is no other language anywhere near as good, and memory safety tends to make languages more ugly.

[@titfortat4405]

It's relevant to anyone who wants to write code that other people will use. If you're the only one who will use your code, then sure. Go crazy with those segfaults to your heart's content.

[@MrPetzold123]

Haha, another UFO- like programmer...please don't.

[@xamidi]

@@titfortat4405 I am already not the only one using my code. My passion project currently has 19 stars on GitHub despite concerning niche research. 1/2

[@xamidi]

@@titfortat4405 I am already not the only one using my code. Also my code is high-quality, so there were no segfault issues so far. I would provide details but YT censorship prevents it.

[@xamidi]

@@titfortat4405 I am not the only one using my code. Furthermore, it is high-quality. There were no segfault issues in my open-source passion project detected by others so far in several years.

[@JeanNoelAvila]

At last, a hard realistic look on C++ memory safety, and hopefully some proposals.

[@CN_SFY_General]

The changes will create a new language. C, C++ will ever be a language close to the processors.

[@dminik9196]

Unless you're running on a PDP-11 C (or C++ for that matter) isn't really close to how your CPU works. Funilly enough C isn't even specced based around real hardware. It's specced to run on an abstract machine.

[@JeanNoelAvila]

@@CN_SFY_General As @dminik9196 wrote, the machine architecture model embedded in C and C++ languages is not, even remotely, related to modern CPUs, and I would dare to say that it is obsolete and no longer pertinent in this regard. Take LLVM as an example of how a lot of "less low level" languages would compilte to identical machine code, unless you take great care to write for a specific architecture.

[@jameskingcodes]

This isn't anything new. There's been dozens of "hard realistic looks" on C++ since the rustaceans created Twitter accounts. It's a tired talk frankly.

[@CN_SFY_General]

@@dminik9196 C is not based on real metal, but it's very close to it: transferring C codes directly to the assembly languages of real metals in an almost one-to-one relationship is easy.

[@thecollector6746]

Speaking as someone who has been writing software for the US government for longer than I care to admit....the White House's memo regarding the suggestion that all development should move to "memory safe" languages is pretty much useless given the fact that The US Government and Private Institutions (and pretty much all governments at this point) haven't regularly implemented software using languages that aren't garbage collected in some manner since the late 80s.....and C/C++ at this point are only used within specific niches across the board for specrific reasons. This presentation isn't anything more than more anti C/C++ FUD.

[@TheEvertw]

Learning Rust may be hard for c++ programmers because they have to unlearn many bad habits they picked up. It is easier for new programmers.

[@oysteinsoreide4323]

the irony is that much of the lowes level of code, runs C or C++ code through API calls.

[@3Rton]

does anyone have the link for the proposal of safe std::span increment and who voted against it?

[@cryophos2044]

I learn C++, should i abandon now?

[@khhnator]

you shouldn't learn only one language

[@3Rton]

I mean, billions of lines of code wont disappear over a decade, it really depends do you plan to get a job in 5, 10, 15, 20, 25, or 30 years if you are aiming for +20 then maybe, but there is no guarantee that Rust will be the next successor either at those time scales

[@khhnator]

the thing is that you should learn to program, not a language. languages will always change, heck C++ itself is not the same language it was long ago; what programming is has however remained the same. learning your first language is just your first step. once you get good at programming, you will be learning new languages easily. because they all do the same thing, just in different ways.

[@rockstar-technology]

No you should not.

[@xamidi]

C++ is still the best programming language in terms of elegance and efficiency, and it will probably stay this way for a long time, now that people focus on memory-safe designs (which are ugly/restrictive). But C++ is really hard to master. Are you intrinsically motivated to learn it, e.g. because you wish to write the most excellent code some day? You should only abandon it if that is not the case (and you just want to make money, or similar).

[@lanceatone]

Java is not memory safe! Any object at any time can be assigned 'null'.

[@voradfils]

Why would nobody be interested in using a safe subset of the language (opt-in for the critical bits at least) if they were willing to entertain using a completely different and more restrictive language altogether? People follow all kinds of "best practices" with religious fervor already. How would that be any different?

[@mileselam641]

Because you can't go 200 cycles without hitting library code, and the existing libraries out there are not using your safe subset. Many actively dismiss the safe subset option, forever claiming the problems highlighted here and elsewhere are just "skill issues". Then there's the issue of "best practices" in C++ being far too subjective and disjointed in the community. As the author of Circle eventually found, it's a LOT easier to migrate to a safe language than retrofit C++ (and its community!) to meet modern safety standards.

[@Heater-v1.0.0]

Can you reliably draw a circle around the supposed "safe subset" of the C++? Can you create a compiler that enforces use of only that subset unless a desire for opt-out is indicated. It's great that people follow all those "best practices". I cannot fathom why they would not want a compiler to do a lot of that tedious checking work for them.

[@voradfils]

You guys are nerding out too much. I just addressed the argument that opt-in safety would not be viable in general because people wouldn't want to use it.

[@foobarf8766]

Yeah, there are trade-offs in engineering, Rust is making impossible promises I think. At least Python, Java and C# do not pretend to be smaller or faster than they are. The size of Rust executables gets silly (I never hear Rust proponents mention this) so I question how it will make serious inroads to embedded applications.

[@anotherelvis]

If a convenient safe subset existed, then people would probably use it. But according to the speaker this would require a new standard library among other things.

[@alexeyvl]

not sure I understand one thing regarding safety language without considering OS. Before we have OS implementing on Rust it’ no sense by my opinion to talk about safety language.

[@nickbarton3191]

It's dead, even for real-time code, C# has constructs to avoid heap allocation, the enemy of performance. But on a performant hardware, just not worth the risk except for specialist applications.

[@bartlx]

I hope one day you'll find out that C# is just Microsoft Java, a corporate invention, or should I say rip-off, at a time a lot of people were convinced that speed of execution was guaranteed by Moore's law. Misguided individuals.

[@OlaInTheClouds]

Swift is not proprietary

[@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.

[@NotherPleb]

This is so blatantly false. C++ and Rust are on par in terms of performance, no question about it. Rust has stronger guarantees and enables optimizations that C++ can't. And for multithreading even more false, it tells me you barely touched Rust.

[@Heater-v1.0.0]

Use of reference counted pointers is not garbage collection. Data is freed as soon as it is no longer in use, it does not hang around like garbage waiting for some collector to clean it up. Of course you can have safe and fast. As a long time user of C and C++ one other the first things I did in Rust was implement a bunch of codes in Rust that I had previously written in C or C++, just to convince myself I could reach similar performance in Rust as C/C++- I managed it easily.

[@khhnator]

you are right, using Arc everywhere is just Garbage collection but worse. that's why you don't. if you are putting everything in your program in a Arc, you have a design issue that would blow in your face in C++ or any language as well.

[@foobarf8766]

It's like the saying, choose any two: speed, reliability, security

[@isodoublet]

@@NotherPleb " And for multithreading even more false' Nope, multithreading is precisely where Rust's model shows itself to be a cruel joke. Easiest parallel program in the world: take a vector of doubles, compute the square root of each one. Now do it in parallel. _Trivial_ in C++, you better _beg_ the borrow checker in Rust. Rust puts the "embarrassing" in "embarrassingly parallel". No easy feat.

[@RalfPinkaire-f7w]

Cpp is a mess. No thank you

[@patricktaylor7614]

There's is no existential threat to one of the most used legacy languages ever.

[@RustIsWinning]

Clueless 😂

[@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.

[@Heater-v1.0.0]

Given the statistics on security vulnerabilities published by Microsoft, Google and others (as shown in this vid) showing that around 70% of security issues are traced to mistakes in memory usage (buffer overflows, use of uninitialised, use after free, etc, etc) then I think "No". The NSA is thinking about all that. they realise that to make progress on security we need to get stricter all around. Hence the request to use memory safe languages. Also, this statistics I mentioned above (also this vid) are about memory misses issues in closed source code by MS and others. So I don't think the NSA can sensibly have more of a nightmare over Open Source.

[@isodoublet]

@@Heater-v1.0.0 Yeah, and then you actually read those CVEs, and realize none of that code looks like code I would write, or allow any of my teammates to write, and realize that Microsoft, Google et al have a critical competency problem and this whole safety thing is barking up entirely the wrong tree.

[@Heater-v1.0.0]

@@isodoublet Now read the CVE's of all the non- MS/Google etc software cause by mistakes in memory usage. That "critical competency" problem is everywhere. I have never worked for an MS or Google but having worked in many companies in a few different countries over decades that is what I have seen. Other than critical fields like avionics or military software where extreme effort is taken to ensure correctness. You are making the "perfect programmer argument", which is fine but such programmers and teams are few and far between.

[@isodoublet]

@@Heater-v1.0.0 It's not about programmers being "perfect". It's about programmers not being critically incompetent. These places are hiring some of the worst programmers out there and letting them loose with zero oversight. It's obvious that'll cause problems. I don't need to move to a worse language because of them.

[@zantrua]

@@isodoublet Anyone who thinks they can write manual memory management code better than Linus Torvalds, Microsoft, and Google is so far beyond arrogant it's actually funny. "I never make mistakes in millions of lines of abstract logic, it's not a problem of human brains being bad at this task they didn't evolve for, it's just that those specific programmers are bad"

[@alfaeco15]

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

[@mikedougherty1011]

Probably government ruse to implement new language backdoors

[@RustIsWinning]

Meds

[@Jack-s9k9p]

What a naive and poorly thought through reason ? Why would a government bother with trying to introduce backdoors that are clearly visible to every other government ? There are so many easier more obscure ways to introduce backdoors elsewhere. This reason may be well intentioned, but poorly thought through.

[@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.

[@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.

[@edgeeffect]

I thought I was mishearing.... if U.B. can actually lead to demonic infestation up yer nose... then we really really do need to look out for it.

Be careful with Rust, it promises more than it can deliver. For one, lifetime deduction in Rust is completely borked. People already demonstrated "memory safe" crashes with this.

[@AlainPaulikevitch]

The exitential threat mentionned is the same all accross tech. Fashions and trends adopted by the unfortunately numerous idiots out there end up dominating genuinely well thought and appropritate technologies. One ends up regreting the days norms were driven by consortiums.

[@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.

[@k04jg02]

The number of local only apps is dwindling, just about everything consumer facing uses Internet now

[@mileselam641]

Think Stuxnet. Not everything that thinks it's airgapped is actually safe. And reliability is its own security issue. You don't need a network connection to fall over due to use-after-free bugs.

[@isodoublet]

@@mileselam641 Except use-after-frees are extremely uncommon in practice (when using the already available tools) and it's silly to jump hoops trying to avoid them while making _other_ types of bugs more likely by making the language harder to use.

[@foobarf8766]

'Ostrich' security gets you things like TempleOS: God told him networking was a sin. The inputs were all too dangerous.

[@zantrua]

@@isodoublet 36% of Chrome's security bugs were caused by use-after-free specifically. It goes up to 70% if you include other manual memory management bugs.

[@johnphamlore8073]

I seriously have to ask if all Rust advocates are sociopaths / psychopaths. You are criticizing C++ and advocating a language Rust that refuses to publish a specification or language standard. So in what sense does Rust really exist as a language?

[@troyfrei2962]

START WRITTING YOUR CODE IN DELPHI !!!!

[@carlosleyva-calistenia6400]

How is it doing nowadays? I used to love it up until 2015 or so, but Embarcadero made a mess of the language and I sadly had to let it go.

[@troyfrei2962]

@@carlosleyva-calistenia6400 Its very good now. The IDE is very good. You can write your program, and the program can deploy to your Phone, PC, or to a Android , Apple phone, Mac computer, Just by telling the IDE what you want to deploy to. Just my one setting. NO REWRITEING CODE!!

[@opa-age]

How about just remove pointers or just pointer arithmetic from the language

[@DomainObject]

Don’t forget to “just” rewrite the standard library while you’re at it…. And all the legacy code that depends on pointers and pointer arithmetic. Or maybe just use Rust.

[@lindalaguna8066]

@@DomainObject I don’t think people realize how much work has gone into the c standard library. A couple of months ago I was messing around in x86 trying to see how things work and I started looking at the library code for the first time and I was blown away by the sheer amount of work in there

[@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.

[@simonmassey8850]

Planck’s Principle. He state: “A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it.” Old men say they prefer speed over safety and they say hire and expert like them to fix their code. When there are less old men there will be less use of unsafe 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.

[@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++.

[@NotMarkKnopfler]

Memory safety/borrow checking ala Rust is coming to C++. Chill out.

[@OCTAGRAM]

C++/CX ?

[@markbratcher9095]

Interesting topic and good presentation. (A friendly colleague may want to pull the presenter aside and politely mention his slurping habit. :D)

[@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.

[@mileselam641]

@@alfredomoreira6761And he's publicly stated it may not be worth the effort over just migrating to existing memory safe languages. 10-30 years of standards body negotiations in the optimistic scenario (as was highlighted in the video)? Not gonna happen.

[@isodoublet]

@@alfredomoreira6761 Sean Baxter is a bad actor trying to destroy C++, not some starry-eyed developer trying to bring fire from the gods. Safe C++ would require a completely new standard library with a different API and idioms btw

[@foobarf8766]

There are always trade offs. Anyone saying otherwise is selling something. Building with --hashed-pointers might be slower but you need to remove creature comforts to go fast in motorsport too.

[@moofymoo]

boss, just start rewrite everything in C++ movement, it did wonders for javascript.

[@mileselam641]

JavaScript is memory safe at least. Slower, but provably memory safe. Rewriting everything into C++ makes the global corpus of code far less safe.

[@fg-zm2yu]

As it will be mentioned in a famous youtube channel: skill issue.

[@codewizard58]

Why do you call the libraries part of the language ? The language has grammar, syntax. So it is the libraries that are not memory safe ?

[@johndowson1852]

C++ stdlib is part of the ISO standard.

[@johndowson1852]

C++ stdlib is part of the ISO standard.

[@AdrianBoyko]

If I had to say “two words” about me, I’d choose “hoopy frood”.

[@nisonatic]

Your towel will never let you down.

[@alexisfibonacci]

No mention of Zig?

[@RustIsWinning]

Zigfault 🤣

[@ivanyanakiev4544]

Good luck telling people in HFT they cannot use unsafe pointer arithmetic to optimize their code. This is how these people make their money (these people is me). C++ should never become safe by default but only opt in. People in the defense sector okay use safe C++. But why force everybody when people like game developers, finance they need the performance they cannot sacrifice performance. Absurd talk. Just go and use rust if you care so much. You cannot force people to rewrite billions of lines of C++. I bet defense companies are stuck on C++98 good luck making them migrate to your new C++29 with safety features. The damage is done it cannot be undone. That's why you need good programmers. For greenfield projects okay use Rust if you want. Let C++ be what it is. A beautiful mess

[@Zel-kr3qj]

HFT people are not the audience for this video. This video targets people working on safety critical projects, many of which work on embedded devices. I think this is more than clear enough.

[@ivanyanakiev4544]

How is it clear when this guys is yapping about safety by default for all c++. Leave c++ allow and go do rust balder.​@Zel-kr3qj

[@RustIsWinning]

What on earth is HFT lol

[@eliasboegel]

​@@RustIsWinningHigh-frequency Trading

[@erik7726]

Good, automated tooling helps a lot. And the tools will get orders of magnitude better with AI. C++ will live for many more decades.

[@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++.

[@DomainObject]

⁠@@gulagz1549 Yes, however that very same software, is also likely riddled with memory safety issues. Just because it runs doesn’t mean it’s safe or secure.

[@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.

[@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.

[@mileselam641]

One of the main holes in Rust adoption is a stable ABI. Without it you don't get shared libraries in Rust. As it stands, Rust has to pretend to be a C shared library or (kinda sorta) a C++ shared library in order to play in the greater sandbox. If it did have a stable ABI, mapping to other popular interfaces such as C++'s would be comparatively trivial.

[@heavymetalmixer91]

@@mileselam641 Why is there no stable ABI for Rust?

[@MikhailStrelnikov-q4p]

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

[@xybersurfer]

who is Jimmy?

[@h4ndle_yt]

""""""""safety"""""""" lmao

[@alexanderryndin6686]

Just add AI to the compiler and let it fix that problem automagically 😆

[@alfaeco15]

We are just not using the right languages.

[@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.

[@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.