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

Summary

In this engaging talk, Helge Penne examines the considerations surrounding the existential threat to C++ due to its memory safety issues. With regulatory pressures mounting, languages like Rust are being considered as safer alternatives. Helge outlines the challenges faced with migrating away from C++ and the potential future of language evolution addressing safety concerns, touching on initiatives like Circle, Carbon, and others. As the programming ecosystem evolves, developers must weigh the benefits of migrating to safer languages to ensure security and sustainability.

Highlights

• Helge Penne shares his extensive experience in software development, especially with C++. 🔧
• He highlights the lack of progress in addressing C++'s memory safety issues. 🚫
• Regulatory pressures from agencies like the NSA urge migration away from unsafe languages. 📈
• Rust emerges as a viable alternative, already adopted by major players like Microsoft and Linux. 🌐
• Projects like Circle and Carbon aim to create memory-safe successors to C++. 🔄

Key Takeaways

• C++ faces growing existential threats due to memory safety issues. 🚨
• Regulatory bodies recommend migrating away from memory unsafe languages. 📜
• Rust is considered a strong alternative due to its memory safety features. 🦀
• Emerging languages aim to replace C++, focusing on safety and interoperability. 🔄
• Successful language migration requires careful planning and organizational support. 🚀

Overview

Helge Penne's talk dives into the challenges and potential future of C++, especially given the existential threat posed by its memory safety issues. With over 30 years of experience in software development, Helge offers an insightful perspective on the current state and future of C++ in comparison to more secure languages like Rust.

Regulatory pressures are increasing, urging organizations to transition away from memory unsafe languages. Helge discusses how agencies such as the NSA are pushing for strategic migrations, which could eventually impact how software development is approached globally. The shift in priority from speed to safety is poised to reshape programming practices.

Helge also explores budding languages such as Circle and Carbon, which are designed with memory safety and improved interoperability in mind. These languages could serve as the future of secure software development if they manage to overcome the significant challenges associated with migrating existing codebases. As the programming world navigates through these changes, developers are encouraged to consider the long-term benefits of adopting safer programming languages.

Chapters

• 00:00 - 01:30: Introduction and Background The chapter titled 'Introduction and Background' opens with a welcome message to the audience as the speaker prepares to discuss the possible existential threat posed to the C++ programming language. The speaker briefly introduces themselves, mentioning over three decades of professional experience in software development, primarily in C++. Despite the challenges, the speaker has found working with C++ enjoyable for the most part.
• 01:30 - 03:00: C++ and Memory Safety Challenges The chapter discusses the challenges of ensuring memory safety in C++. The speaker clarifies that their opinions are based on experience rather than bias, having worked in secure communications for over 11 years. They emphasize efforts to enhance C++ security at their company, Talus Norway, and recognize similar endeavors in other languages like Rust.
• 03:00 - 05:00: Regulatory Pressure and Industry Response The chapter titled 'Regulatory Pressure and Industry Response' addresses the ongoing challenge posed by memory safety issues within the tech industry. It suggests that while the hiring landscape is dynamic, future opportunities may arise, particularly emphasizing non-embedded roles at present. The narrative indicates an intention to share presentation slides for additional clarity, thereby addressing potential concerns from the audience. Despite the brief mention, the overarching theme underscores difficulty in writing secure code amidst a backdrop of statistical insights and surveys reflecting the industry's awareness and reaction towards memory safety threats.
• 05:00 - 07:00: Potential Future without Memory Safe Languages The chapter discusses the concept of memory safe languages and the current state of programming languages like C and C++. It points out that while there are ongoing debates about statistics and data relevance, it's evident that a significant portion of programming still relies heavily on these languages, which lack built-in memory safety features. The speaker mentions that despite awareness of the issue, there has been little progress in moving away from these languages towards more memory-safe options. The chapter implies a focus on the potential risks and challenges of continuing to use non-memory safe languages.
• 07:00 - 09:30: Complexities of Making C++ Memory Safe The chapter discusses the challenges and limitations in making C++ memory safe. Despite modernizations in the language, there has been limited focus on safety improvements. The chapter highlights that speed continues to be prioritized over safety, leading to missed opportunities for simple fixes. The chapter questions whether this approach is responsible.
• 09:30 - 13:00: Industry Movements Towards Safer Languages The chapter titled 'Industry Movements Towards Safer Languages' discusses the growing industry awareness and responsibility towards utilizing safer programming languages. It highlights the societal responsibilities of software engineers and the looming possibility of regulation, referencing a report from November 22 by the NSA regarding software memory safety.
• 13:00 - 17:00: Exploration of Alternative Languages The chapter discusses the push for migrating away from programming languages C and C++. It notes the publication of a report by the Cyber Security and Infrastructure Security Agency (CISA) supporting this move. Additionally, the report garners international backing from various organizations.
• 17:00 - 21:30: Considerations for Migrating from C++ This chapter discusses the importance and considerations for migrating from C++ to other languages. It highlights a report by the NSA released in December of the previous year, which urges organizations to develop and publish a strategy for transitioning away from memory-unsafe languages. The NSA's report adds significant impetus to this transition, emphasizing the need for increased safety and security in programming practices.
• 21:30 - 24:00: Conclusion and Final Thoughts The chapter discusses the pressure and expectations set by authorities for organizations to appoint an executive responsible for implementing specific strategies. It highlights the fine line between guidance and regulation, pointing out the strong suggestions that almost resemble regulatory actions. A subsequent report from the White House is mentioned, but it is noted for not introducing significantly new information.

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

• 00:00 - 00:30 okay uh welcome everyone to this talk about the potential existential threat against C++ um let's let me just start about with two words about me um to give you my background I've been doing software development professionally for a little over 30 years most of that has been C++ um so that has been fun I've really enjoyed it most of the time uh I've also done
• 00:30 - 01:00 work in other languages including rust also for production so what I'm trying to get across is that I'm not some sort of rust undercover agent trying to bash C++ uh this comes from experience um the last 11 years has been at a company called Talus Norway and we do secure Communications so for that time I've tried to make as secure secure uh C++
• 01:00 - 01:30 code as possible which is very hard at times um we are usually hiring we're not hiring embedded people right now but if you check back in a while it might have changed it usually does so here's the link if you need it uh I will try to publish the slides afterwards so don't worry if you don't get this so what is this uh threat well we have a memory safety problem um there's been a lot of statistic itics and service about this
• 01:30 - 02:00 people can argue about the numbers um and what sort of data that's relevant and so on but you can have a look at this if you like uh this percentage is typically for stuff that has a lot of c and C++ content uh so have a look if you're interested uh I won't Aug statistics here we can do that afterwards if you like um little progress has been made on this it's been known for quite a while
• 02:00 - 02:30 and in many ways the language has not truly responded it's been modernized generally but there hasn't been much work done specifically to make it safer beyond that um and importantly it's hard to see any detectable change of priorities uh speed still seems to be more important than safety and many of the easy fixes are not made so are we Behaving Badly are we acting in a in a responsible manner well
• 02:30 - 03:00 are we fulfilling our responsibility to society if you look at this from outside you might be tempted to say no and the dangerous thing about that is that irresponsible professions will eventually be regulated and there are some signs that this might be starting to happen uh some of you have seen this it's a report from November 22 by the NSA about software memory safety
• 03:00 - 03:30 and this caused quite a stir uh you can have a little look at that if you like so they basically want us to migrate away from C and C++ specifically um a while later uh the cyber security and infrastructure Security Agency uh quite a mouthful published a report that backs this up and they also got a lot of other organizations from around the world to
• 03:30 - 04:00 coign this to add weight to it um and then in December of last year the NSA came out with another report which which turns up the heat quite a bit there's quite a lot lot of text on this but this is a quote from the report and what they want organizations to do is to write and publish a document with a strategy to move away from memory unsa languages
• 04:00 - 04:30 basically and well they urge us to do that and they also want us to name an executive who shall be personally responsible for carrying out this strategy yeah this is not vague this is almost as close to regulation as you can get without actually doing it and then there's a report from the White House a little after that again uh which sort of backs it up but it doesn't bring much new to the table except that
• 04:30 - 05:00 they want to make security measurable which is interesting because you can build stuff on that um so what are the next logical steps well governments could come with requirements they could require us to make this plan and follow it uh they could require us as suppliers to document the extent of unsafe languages in our products um if they put out uh tenders
• 05:00 - 05:30 and we submit bids for that they could penalize us if we use unsafe practices uh you could possibly see accountability and liability if you have a security breach and that causes someone to lose money uh you could be liable for that uh finally prohibition I don't think we will get there but you know it's it's the end State um there was also this which is a report from Google which is quite interesting it's a good read
• 05:30 - 06:00 uh I recommend you have a look at it if you are interested in this topic um this seems a bit like an answer to to NSA is uh asking for a migration plan um and the strategy they seem to outline or well they're considering actually uh is to write new code in Rust uh to rewrite high-risk components in Rust and to try to make the remaining C++ code as safe as possible uh it mentions carbon uh but that does not
• 06:00 - 06:30 seem to be part of the strategy as of yet um that's not because they don't believe in carbon I'm sure but you know it will take a while for carbon to be ready and they have stuff they have to fix now they don't have the luxury of waiting for a new language uh other ma players like Microsoft putting rust in Windows uh migrating net internals to rust as far as I can tell and famously Linux has just adopted rust as its second language um
• 06:30 - 07:00 so you can try to draw some predictions from this uh these are my personal ones uh yours might be different but I think the era of memory unsafe languages is ending it's not the end but you know maybe the beginning of it and I think that there will be no future popular languages that are not memory safe I think that's done so so why can't we just make C++
• 07:00 - 07:30 memory safe and you know what does memory safe mean anyway well a a good definition is surprisingly difficult um um there is this paper that you can have a look at uh it will take you deep down into computer science theory which can be fun if you have the time and inclination uh but it's hard um and most of us will get by with just an intuition about what isn't that's what we usually do and there are
• 07:30 - 08:00 a few things that are obviously not memory safe uh you know read and write out of bounds we've all done that that usually goes under the heading spatial memory safety uh use a free temporal memory safety uh using uninitialized values initialization safety popular topic on on conferences like this um casting appointed to the wrong type goes usually under the category type safety and so on iterator invalidation which is also an
• 08:00 - 08:30 example of temporal memory safety dat races thread safety we probably all fallen into that trap as well most of us and then you have the big one anything else that is undefined Behavior you know undefined Behavior can give you nasal demons and nasal demons are not memory safe so that's a big one so what can we do with C++ to make a memory safe or something close to it well
• 08:30 - 09:00 it requires a safe subset somehow so what has to go and I'll go through a few examples but wait oh that was that was silly uh yeah we have to forbid poter arithmetic for one fundamentally and safe and range checking for out of bounds I skipped a bit faster because that's when this comes wait we have rain shaking in C++
• 09:00 - 09:30 actually even for the indexing operator you just use this one you define G cxx assertions so let's see a show of hands how many of you already knew that okay and how many of you used that in debug okay so about five and how many of you use that in production
• 09:30 - 10:00 there's one okay good that's it right so what can we learn from that memory safety must be the default if you make it opt in then people won't use it plain and simple it needs to be opt in opt out means nobody uses it uh I go into a bit more detail about things like that in my talk from last year if you're
• 10:00 - 10:30 interested uh temporal memory safety we need to get rid of old school new and delete obviously but that doesn't pain anyone we just use small pointers instead but it's not that simple um here's some simple code using unique pointer so we have a class A which owns a b so their lifetimes are the same but then someone else needs to
• 10:30 - 11:00 communicate with B at times so Class C has a pointer to b a dependency and if someone comes along and deletes a then B goes with it and if you still have the C then it's left with a dangling reference so storing references or pointers in members or globals is unsafe you can always come up with examples that break everything so what to do
• 11:00 - 11:30 prohibiting that well very difficult it breaks everything uh you could use a rust borrow Checker maybe the only current thing that works you don't want to go to garbage collection so this makes it very difficult to make the language safe um you could say well use share pointer but that has its drawbacks too it's a bit slower if that matters um but it also removes ownership semantics if it gets very hard to about the lifetime of
• 11:30 - 12:00 things you know how when does the be actually get destroyed so it's not ideal and it gets worse storing references or pointers in parameters or locals is also fundamentally unsafe simple example you have a function that takes an A and that happens to be in a different translation unit you call the function to get a B from a and then you call this whatever function on a which happens to delete
• 12:00 - 12:30 the B and then you call the function on B and boom you have a use off the free and the problem here is that you store the reference locally for too long and the language allows that and there's nothing that compiler can do about this um same thing almost iterator and validation um you get an iterator to the beginning beginning of a vector you push back which means it can get real at and
• 12:30 - 13:00 then you reference boom now static analysis can detect some of this but what if you pass this iterator to another translation unit then it can't very difficult to analyze so iterators invite UB just as pointers do and are also fundamentally unsafe and to fix that you probably need a new standard Library so for temporal
• 13:00 - 13:30 the problems tend to span translation units and makes them virtually undetectable by the compiler or static analysis without language changes or restrictions so can we be Memory safe well it requires some very difficult things we need a borrow Checker of some sort or we need to forbid references and pointers which breaks everything the iterators will have to go because they are fundamentally unsafe and we need to remove undefined Behavior
• 13:30 - 14:00 which is all over the language and all over the standard Library as well so it doesn't help just to fix the language the library needs replacement as well and of course thread permites uh invite dat races so this is incredibly difficult um and all safety features must be on by default or they will not be used as we saw and it's difficult to claim to be safe
• 14:00 - 14:30 otherwise so this will break all C++ coas Cod bases and will in fact be like a new language so what's happening with the standardization are there any improvements coming well there is significant low hanging fruit if you want to fix things you could have spatial safety for container
• 14:30 - 15:00 you could fix some important issues with optional and unique pointer you could trap if someone tries to D reference one and it's not defined it's not difficult and the Gip cxx assertions do that so it's available uh you could have guaranteed initialization of variables um so what's coming in 26 there is a paper that has been approved for initialization of local variables which is great it doesn't do anything for variables on the
• 15:00 - 15:30 Heap um it would be nice to fix that too but this is a start there is a St span at coming which is nice uh stud span did not have a safe way to index things it was proposed but it was voted out someone thought it was not important to have a safe API for St span um I won't say public what publicly what I think about that I can tell you over a beer it it's not uh something I want on on
• 15:30 - 16:00 tape um and then you have a fix for some UB in connection with INF infinite Loops which is nice but it's not a big big thing and I may have missed something but that seems to be about it uh there are some other proposals um B stup has a paper on using uh the CPP call guidelines uh to make some security profiles but it seems to be
• 16:00 - 16:30 not very concrete and actionable at this point uh there's a lot of work left to be done and if you want to make something usable out of this um I think you have to break basically everything so I'm not sure if this is going to work uh there's a paper on constrained numbers which is cool it's a safe numerics if you like which can fix a number of problems um but that's also oped in and not much else that I could see on spatial or temporal member safety um I'd like to hear it if if you see
• 16:30 - 17:00 something I've I haven't and I haven't checked back in a few months so there might be more but I think we need to see more soon and if I could make a wish what I would like to see is a coordinated effort for security improvements and that we make safety more important it is the most important thing in my opinion at this point and the willingness to trade per for
• 17:00 - 17:30 safety modern compilers are incredibly good at optimizing away unnecessary checks um and to do the low hanging fruit um but I think what we can expect is that there will be few and minor improvements for security in 26 uh I feel that we won't see any significant progress until 29 at best which means are five to six years
• 17:30 - 18:00 away from any real Improvement uh and that's at best it could be 32 and according to Norwegian law I could be retired by then I would like to see something good happen before that point they'll probably change the law before they changed the language so maybe that just works out um so why is this um is the way the committee is organized
• 18:00 - 18:30 hampering project progress um or do the problems just go too deep and wide to fix properly I'm not an expert on this but it frustrates me a bit and does this constitute an existential crisis well we have this combination of of security threats that the language does not seem to be able to handle and respond to we do not seem to be able to adapt fast enough and the
• 18:30 - 19:00 problems are deeply rooted and possibly unfixable and you know this does not look sustainable long term so is C++ the new cobalt eventually yes I think so but it will take time but these security problems will drive the language towards obsolescence they will be a a big factor in that and you know our inability to respond May accelerate this and you know if people do not believe that the
• 19:00 - 19:30 language can meet the challenge they will eventually move away so something to think about it C++ will be around for a long time but these things will affect the demise of the language it will accelerate it so if you want to go somewhere else where would you go um this is easy stuff though uh there are some existing languages that you could have a look at uh some are partial fits they don't fit all ues but they may
• 19:30 - 20:00 fit some and then of course the the drop in replacement that will eventually always be mentioned when you talk about these things um just a quick run through go garbage collected which most of us are not big fans of fans of because we are embedded developers many of us uh it's compiled which is nice it's memory safe when single threaded which is very
• 20:00 - 20:30 nice uh but data races are not memory safe which is unfortunate because you know threads are one of the things that go is supposed to be good at bit slower than rust and C++ um it's Google owned so you you are at the mercy of Google in terms of its future um also not that Google migrates much of its code to C++ oh from C++ to rust uh not to
• 20:30 - 21:00 go which is not because it's not a good language but because much of the code they migrate I suspect is something that sort of needs C++ and go is maybe not a perfect fit for that uh Swift I haven't used it personally I've had a look and it looks rather nice uh not garbage collected but it uses reference counting and copy on right it's memory safe and then the really cool thing um in
• 21:00 - 21:30 Swift 6 it's also thread safe which is quite an achievement so cuos to to Apple on that really really nice work uh C++ interoperability seems to be good uh but again it's a propri proprietary language owned by Apple so you are now at the mercy of Apple um Java uh some might be surprised I even mentioned that but it's memory safe data are memory safe too which is cool um if
• 21:30 - 22:00 you have a datab Ras you can get an unexpected value which is a bug but it's still memory safe uh it's reasonably efficient but it is garbage collected um so not ideal for lowlevel system programming but you can build embedded systems in Java if you just put some some C or C++ underneath it's been done I've done it myself once it was fun um then that's rust you know memory safe free from data Ras is uh good for lowlevel programming performance is good it's fairly mature
• 22:00 - 22:30 tooling is is really great um and it's the only current dropin replacement for C++ if you can use C++ you can typically use rust as well um some say it's a little harder to learn and uh they talk about fighting the borrow Checker and stuff um in my experience uh C++ is also hard to learn well know we we wouldn't have this big conference talking about all sorts of
• 22:30 - 23:00 strange things if it wasn't and if you're smart enough to learn C++ then you're probably smart enough to learn rust it's not harder um but we also have some interesting stuff going in terms of successful languages so languages specifically designed to replace C++ uh lot of cool stuff uh CPP front by hubter uh Circle carbon higho probably more um
• 23:00 - 23:30 so I I thought about this and I thought well what would the requirements be for something like that and this is just something I came up with so it's my personal uh ideas yours might differ but these are the ones I came up with it needs to be a cooler language than C++ you know or people won't use it um and it needs to be Memory safe and this is where it gets a bit serious um as far as I can see it there
• 23:30 - 24:00 is just no say business case for switching to a su successful language that is not memory safe why would anyone fund that in this day and age it just doesn't make sense so any successful language needs to be Memory safe so it means that any successful language that is not memory safe is just a hobby basically will be dead on arrival and it needs better C++ interoperability
• 24:00 - 24:30 than rust because you know otherwise just use rust it's available now you don't have to wait for anything um so this one CPP front aim to be a better safe better safer language than C++ uh but so far it does not seem to aim to be Memory safe so you know it's cool but I'm sorry I don't believe in it
• 24:30 - 25:00 uh circle on the other hand uh really interesting project uh it's a single man effort by a guy called Sean Baxter and it's probably the best jaob application in history in terms of programming uh it's a C++ compiler built on uh the llvm back end with non-standard extras and it's a Memory safe C++ um you can have a look at this site uh it's incredible interesting very very impressive uh he
• 25:00 - 25:30 has built a borrow Checker safer apis all sorts of language features uh there's a demo out as well uh which I recommend that you watch it's really cool um and what he does is that he puts rust inspired features on top of C++ uh and this is just a small list there's a lot more uh all these features are put in not because they are are cool at least not just because they are cool
• 25:30 - 26:00 uh they are all necessary in order to achieve the memory safety memory safety uh in circle and you know also notice that there's a new standard library in this because this is also required the one we have is not memory safe uh he he doesn't show a complete new standard Library just the stuff he needs for the demo so as a proof of concept and and there's lot more features he has a long list that you can have a look at um so how do you migrate from C++ using
• 26:00 - 26:30 Circle well safe and unsafe code lives side by side and functions are either safe or unsafe and there's a safe keyword to annotate them with and safe functions can call Save functions but save functions do not call unsafe functions that will break which means you can migrate incrementally so you know the uh interop is taken care of which is cool it's a nice solusion
• 26:30 - 27:00 but the migrated code must pass the borrow Checker so if you find your F find yourself fighting the Bor Checker in Rust you will find yourself fighting the Bor Checker in circle um but you get interrup for free um but note that if you want to migrate to safe code the borrow Checker will require you to restructure your code
• 27:00 - 27:30 because that's part of what the Bor Checker does it does require you to structure your code in a certain way in order to pass the rules so you're not just rewriting line by line you are actually redesigning parts of your code and you also need probably to rewrite for the new library you can't use Vector anymore you have to use the two Vector so it's a bit of work but I don't think it gets much easier than this so where will this go can we bring it
• 27:30 - 28:00 into the standard well Sean Baxter estimates that this requires 300 pages of Standards proposals um which is a lot uh that's a great interview with him on on the CPP cast uh podcast I think it's episode 383 uh where Tim OD dumler one of the hosts estimates that this will take 10 to 20 years of standard committee work so you know probably impossible and I think the best way
• 28:00 - 28:30 forward is probably that someone buys this and funds it and pushes it as a as a fork or something I don't know but it's a cool attempt I think I I wish him well I hope he succeeds uh carbon and if there are any carbon people here and I say something wrong you know just shout um seems to have promising interrup ability will will be unsafe at first in
• 28:30 - 29:00 no1 and then as far as I could tell they they TR try to int they plan to introduce safety incrementally in O2 and it seems from the talk I've seen that safe carbon and unsafe carbon will coexist which suggests a two-step migration that you migrate at scale to unsafe carbon using tool support and then you migrate from unsafe carbon to safe carbon with which seems maybe to end up
• 29:00 - 29:30 in the same terrain as Circle this second point and I also saw some suggestions that safe carbon will probably use a borrow Checker there aren't that many other Solutions in town um there's a talk by chander cruth from CPP now I believe which goes into thread safety and sorry memory safety and carbon uh so it goes a bit beyond uh the talk from
• 29:30 - 30:00 yesterday on those topics so it's worth a look um my fear is that the migration to safe carbon will be a bit expensive because it's like with circle you need to restructure your code to pass the borrow Checker and you need to rewrite for new libraries you can't call the old ones they are not safe there's UB everywhere so there is a risk that and this goes for Circle as well there's a risk that a lot of code will stay unsafe because your boss will not fund
• 30:00 - 30:30 it the the final migration and also of course as with circle if safety is oped in is it a memory safe language opinions will differ on that um I've also noticed there a new language called Hyo coming up uh which seems to use mutable value semantics and might be easier to use than rust um maybe that will make it more restrictive I'm not sure I haven't looked closely
• 30:30 - 31:00 enough yet uh It looks interesting but it's early days and it seems to be slipping a bit versus the road map I they probably need more people working on it but it could be a very very interesting language um and we need to know more about interop but okay could be a contender should we wait for this well I think that depends on your application these languages are
• 31:00 - 31:30 five years away at least and you know new languages the likelihood of success is is not always that great um for many of us they will arrive a little late I think if you're going to migrate eventually to something else then maybe your best bet is to use an existing language instead of waiting 5 to 10 years for something that may not arrive and and during those 5 to 10 years you will write a lot of new C++ codes that you will also have to migrate
• 31:30 - 32:00 later so what to do and why do we need to do anything at all well you know some will say that you know our programmers make few mistakes the problem is just that people use C++ wrong well you've probably seen this before all car drivers consider themselves better than average almost all and I think all programmers that are
• 32:00 - 32:30 car drivers definitely consider themselves better than average so you know we tend to overestimate how well we can do things uh humans make mistakes and M's law still applies so I don't buy that one tools and discipline will get us safety use sanitizers use static analysis
• 32:30 - 33:00 well people are not disciplined not all the time and we tend to opt out of security because we want to deliver software right now and we have pressure to do so and sanitizers only catch the errors that your tests trigger the other ones go undetected static analysis well it usually works for single translation units I'm sure there are tools that can do global analysis but the ones most of
• 33:00 - 33:30 us use if we use anything they do not do that um I've been trying to do this for more than a decade and it's incredibly hard it's not impossible you can get close but it's very very difficult it's not for everyone so you know safety is not important we make stuff that's not critical lots of people have thought that and have been proven wrong
• 33:30 - 34:00 so what do we do the these are my personal recommendations you know you can make your own um but I think we should consider not using C++ for new products if you have the luxury of starting a new product a new project without having to relate to Old C++ code consider using something else maybe it's no longer the right tool for
• 34:00 - 34:30 the job we are engineers and we should use the best tool for the job and given given today's security threats well it could be that this is not C++ anymore and if C++ becomes the new cobalt it's because of this if you are making a new major component in an existing product well consider if you should do this in a new language um and if you're doing something where
• 34:30 - 35:00 security is important do a security analysis of your system find the attack surfaces and consider rewriting those in a safe language this is I guess to a big extent what what Google is doing and this is really in my guess what the NSA and others want us to do they don't expect us to go and rewrite everything that's not going to happen
• 35:00 - 35:30 but they would like us to write as little new C+ C++ code as possible plain andum so if you do migrate are there some things you should think about um well yes interfacing your legacy code um most languages support this but usually through the
• 35:30 - 36:00 cabi um some languages have good C++ interoperability as well uh Swift seems to be good at this rust and go has some support um the rust support is improving but it's hard um you can migrate gradually this way bottom up or component by component this all depends on what your architecture looks like and you need to take a close look and try to find opportunity ities in the architecture that you
• 36:00 - 36:30 have um there are other things you could consider as well uh you could put new code in separate processes you could use some sort of communication infrastructure to communicate between the old code and new that will give you pure C++ processes and processes in new languages um this works especially well if you have message passing architectures actor models for example uh um and you could migrate one actor at a time or one microservice or
• 36:30 - 37:00 what have you um another thing you should think about is to try to start slow this is this is change management which is notoriously hard um you need to ensure support from key players in your organization you need to have management behind you uh you need to have the Architects on board and there will be other key players in your organization that do not have formal roles even that you need to
• 37:00 - 37:30 convince um you also need to find a good candidate for migration something where migration will be a big Improvement and by good I also mean likely to succeed because you don't get two or three chances at this you need to make this a success and then you can build some momentum from that developers will enjoy
• 37:30 - 38:00 this so if you can make it a success and and uh get people to to uh see it as that and they will talk about it to other developers and then things will start rolling um just be a bit careful because uh especially in the rust Community there are people that are too enthusiastic you know they become almost almost like missionaries like like religious fundamentalists and and they do damage you know they they drive
• 38:00 - 38:30 people away it becomes polarizing and you don't want to go there because that damage takes a while to repair um and because I don't do this often and tend to be a bit nous I do this in record time when I go on stage so I I finished this 10 minutes earlier than when I rehearsed so um any questions or opinions even yes you did not mention
• 38:30 - 39:00 right uh you mentioned Sig uh no I did not mention Sig it looks cool I haven't looked very closely at it because it's it's a successful language for C right yeah as far as I've heard it has some memory safety issues but it's probably not fully memory safe yeah um it's not a good fit for what I do it might be a better fit for what you do do uh and if it improves the safety versus
• 39:00 - 39:30 C then yes sure consider it uh that's also a one man effort isn't it I think so so hopefully he will get some more backing because you need a uh you need a community around this right so the ball is rolling yeah absolutely if it if it uh if it improves safety then sure what languages
• 39:30 - 40:00 are um for the products that use C++ we are making a shift towards rust we have other languages as well uh but um yeah we have we have new products and we have old products we have we have big teams maintaining 30y old products and of course mating that is difficult yeah is using I'm sorry is
• 40:00 - 40:30 using chips from we are using system on chip from several suppliers yeah but are you contributing back to the NRF or the embedded projects are you involved with those organizations um contributing back is sometimes difficult for us because that might re reveal information about products and libraries that we use so for some products that
• 40:30 - 41:00 that can be difficult but we would like to do it when we can um but we haven't done much of that yet unfortunately it's a little difficult yes isort going Curr comp oh something uh no not that specifically um but that would be
• 41:00 - 41:30 cool um yeah we tend to have to choose operating systems also based on what sort of platform it runs on so we're not free to choose anything we want of course yes anything else no ah uh still exist or ah um yeah that's a good question um I went to a talk by
• 41:30 - 42:00 Robert Secord about two years ago and he presented himself as you know a standard C standard committee guy and said that they plan to outlive C++ um and I think he's right I think they will uh C++ has a niche that will probably always exist not just because of Linux but it's the language of choice for board support packages and example programs for microcontrollers and that sort of thing uh um and you need an an easily accessible language for that so I
• 42:00 - 42:30 think that's that's something that you know there will always be C I think what is your thought for the socaled C++ for.net uh you mean this this uh what did they Ed to call that I wrote some code in that once I think you know you you run it on the virtual machine if you like yeah wasn't that something Microsoft did for interfacing purposes
• 42:30 - 43:00 mostly is it safer I don't know I don't know much about that sorry yes right um at the moment we are running the rust code as a separate process or several actually and then we use communication mechanisms to talk with it uh it was
• 43:00 - 43:30 easier for us we had the infrastructure in place to do that easily that worked well yes mention MSC have youing that also um actually okay um I you asked if if we had used
• 43:30 - 44:00 Gacy uh I haven't used that myself I mentioned it because it's so common uh and well tested uh we are not using that ourselves uh there are those uh there's a lot of stuff you can use uh so find the one that suits you but you will want one that is good for the language you have and the language you're moving to so you have to test before you invest money in that
• 44:00 - 44:30 yeah yeah you don't want to use soap now there are better things available okay any last questions no okay well thank you for [Applause] listening e