To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/TravisMedia/ . You’ll also get 20% off an annual premium subscription.
8:28 "It removes some rarely used keywords like 'union'" - such an easy step to porting from C a hell of a problem. Don't know about you, unions are in every project I face
unions are needed for polymorphic structures. all of people who triying cut some basic functions from simpliest language as c-idiots. 30 years exists practices how to write a safe code, with microsoft copirights. and...that kind of idiots didn't want to learn practices.
@@LedoCool1 nah nah nah rust makes you put in the work to make your software safe, and then slaps you for not sufficiently proving to the compiler that your code fits the safety model. And you'll never guess or anticipate why. Fully automatic push-button safety is big copium.
@@LedoCool1 top projects which are heavily linted still have a ton of security vulnerabilities, with memory issues specifically the ones rust's model solves being responsible for around 2/3 of them. They'rre also sanitized fuzzed statically analysed they've got coverity and still doesn't change, C amd C++ just have too much space between the cracks for these issues to hide in. Seen massive companies run around like headless chickens from iterator invalidation so many times.
Sorry, but there is nothing new here whatsoever. We have been here before. For example, the Ada language (1983) which was for a while mandated by the US Govt. This solved many software problems ... but was killed by lazy managers, coders, recruiters and especially software contracting firms on government contracts. And then we have MISRA-C, a coding standard and associated tools intended to ensure safe(r) use of C. Note that MISRA-C does NOT need new compilers - just super-LINTers. Again, software developers hate that because it 'blocks their creativity' etc etc etc. C was developed as a 'portable assembler' .. but sadly was then hijacked as an application development language ... a stupid error. Note: I spent decades developing safe C applications and Ada applications. I was also one of the original authors of MISRA-C back in 1998.
If the Rust hype was only about memory safety that would be one thing, but the embrace of functional paradigms, the ergonomic error handling, and the robust linter all set Rust apart from it's predecessors as well. I agree that it's awesome that memory safety gaurenttes are being added to C and C++ for the sake of the huge portion of existing codebases in those languages, but I don't think that this should or will greatly discourage developers from starting new codebases with Rust.
@@santitabnavascues8673 For real? The implementation of std::variant itself relies on C++ features such as classes and operator overloading that don't exist in C. And even if they did, the resulting code would be an extremely complex, utterly unreadable and unmaintainable mess. And all we wanted to do was something dead simple in the first place.
This all seems a little silly to me. The reason we still have languages like c and c++ that aren’t safe is for efficiency in execution speed, memory used, and the size of binaries. It’s also heavily used in safety critical systems where they don’t use dynamic memory at all, they allocate all at start and never free or allocate more. Safe languages, which ironically can still throw memory errors it’s just a lot harder, were developed because we recognized different situations have different needs. Turning c into a managed language is dumb because we already have managed languages. I use c not because I just have some love for the language I use it because it has specific uses and is the right tool for the job.
Also closeness to the metal. I can easily declare a pointer to a memory mapped register and diddle its contents for fun and profit. Absent this, I'd need to introduce specific assembly language routines.
The other reason we have C and C++ is the language compatibility all the way back to projects started before 2000. People, including US gov, underestimate how gargantuan 25yo codebases are and how much extra work translating and rewriting is compared to simply modernizing. Who's paying for rewrites?
Indeed... unions are just too useful, let's remove them because we have a new wave of incompetent gen-z programmers coming in and they might misuse them big time!
@@sunofabeach9424 show me where I said that unions are enums? I said sum types are rust enums. I also said that the video says unions it's useless but rust still decided they were necessary. Rust supports raw unions (they're unsafe)
Removal of unions is a non starter for me. I make extensive use of those when coding. True, you can always make a void* block and cast into a structure of your choice, but it is clumsier, and sounds like if they are removing unions, they might also be removing this workaround. Most memory issues are created because people use non memory safe library calls, do stupid things, e.g. use (f)scanf to read input without proper restrictions, or are too lazy to run their code through even basic memory checkers like valgrind. C is a great language. It works from the smallest embedded device up to the largest server, it has stood the test of time, and there is simply no reason to completely destroy it just for this minor issue.
Not to mention they're not because of inherent language intrinsics but features you use by default which you can avoid (on your own risk) if you really want the speed. @@keizbot
I tend to take heat for this opinion, but I just don't get it. I program C++ for a living, I try to be as unsophisticated as possible, and I just can't remember the last memory issue. If you use shared pointers and use iterators over indexes whenever you can, it just doesn't come up. Sure, you can have a null shared pointer, but you can have that i C# and Go too. People talk like the sky is falling, but it has been maybe 5-10 years since I've seen any of these issues. I don't think I'm weird or especially smart. Couldn't this just be fixed with profiles that only allow a subset of C++? There is a middle road where C++ is as memory safe as any other language. Why not just force people onto that road?
the luxury of Rust is to be able to not need runtime overhead by constantly checking stuff, like smart or shared pointers. You essentially move that responsibility to compile time. Thats the type of assurance Rust provides, while C and C++ just have band aid solutions. They were born at a time when the average dev had a PHD and programs usually never exceeded 10.000 lines of code.
I write C and Rust, for me writing Rust reduce the fun in making programs with all the added complexity. So yeah IMO there got to be a way instead of having to rewrites everything in Rust, make C/C++ safer! These includes the use of modern standards, utilizing compiler tools (ASAN, valgrind). Modern C/C++ programs utilizing modern compiler tools provides plenty of safety, I tested them and they almost have the same memory safety of the newer languages such as Zig. Now the main issue if I may pinpoint has always been those legacy codebases. These are huge codebases and I have no idea how to tackle them...rewritting them in any language would take forever, even updating them to modern standards is a gargantuan task!
C++ smart pointers do not protect you from use-after-free and buffer overflows. The main problems actually responsible for majority of vulnerabilities.
Not necessarily, I think his aim in this video is just to give a (mostly) unopinionated overview of the news on the topic, not to express his thoughts on it.
The problem that I have with this discussion is memory safety tools and standards that have existed for awhile and are not mentioned often - all major C/C++ compilers have different levels of analysis, and there are tools (like valgrind) and standards (like Cert-C) that already exist to eliminate most of these problems. The problem seems to be a lack of education, not a need for endless new compilers and versions of languages.
C++ has as many build systems as there are JS frameworks. It is extremely overwhelming. Rust is simpler. Maybe because it is younger. I think sane defaults is the way forward.
@vidal9747 Having used both C/C++ tool chains I'll give you that rust is "simpler" until you are working on a large project that needs to be compiled and run on multiple platforms - then you would be better off with C (or if you must, C++)
@vidal9747 If I wanted something simpler, I'd probably pick zig, since has a compiler that can do its own builds in zig code, and easy interop with C/C++ libs. Rust's static linking only limitation is brutal.
@@vidal9747 Rust is not simpler anymore than Kotlin is simpler then Java. Plain old C is simpler than both languanges, even better Python is more easy to deal with.
@@computernerd8157 Python is "easy" until the duck-typing hits and you have no idea what variable is what type anymore. Even moderately sized projects (more than a few files) have this problem.
Saying that unions are harder to use than Rusts enums is like saying that airplanes are harder to use than cars. They are different things with different use cases.
@@tordjarv3802 the main use case is not that different. The rust approach is just a way better abstraction for the purpose of modelling a "oneof" relationship.
There is no magic compiler that will fix bad memory management, when you bring borrow checking to C++ people will notice that they just made rust again, with slightly different syntax that will undoubtedly need tons of refactor to make it "borrow checker compliant".
seriously guys... just start moving away from C and C++, it has served its purpose. Your skills are not bound to the language you write, it is in the knowledge you have.
The US government has become overbearing and overreaching. I have been programming in C and C++ for almost 30 years, and through out most of those years all projects used "memory safe" libraries. In fact, with as little as checking buffer lengths and assigning NULL to free pointers, you can cover the vast majority of problems. The problem is not the language, the problem is the programming methodology and practices. It's like an illiterate blaming English for their inability to spell.
Language doesn't directly harm. The need for memory safety is apparent, when security breaches can lead to direct harm. Why not have better tools instead of relying for the user of the tool to not make a mistake?
Is your point that Firefox, Chromium, Microsoft, curl, etc... developers all just have skill issues that's why their software has so much vulnerabilities caused by incorrect memory usage and that the software you worked on does not have those?
Sorry, but I must disagree strongly. I have also been programming in C and C++ for many years, and I can tell you, in any professional-level C/C++ program, guaranteeing that it is memory-safe is impossible. Programming is done (for now) by humans, and humans make mistakes. If you have a project that 100 developers have contributed to over a few years, it is 100% certain that it will have memory safety issues. Yes, you can follow some safe coding guidelines and use safe libraries, but can you look at a code base that has hundreds of C++ source files with each of them over a 1000 lines long and know that each and every one of them was written strictly following safe coding guidelines? You can't! The only solution (apart from moving away from C/C++) would be to have a compiler (or any other software tool) that can find those issues, but if that existed, we would not be talking about C++'s problems.
@@IlyaDenisov So here we go with personal attacks. But I have no problem in answering open ended bait question... Yes, I can confidently say, that most likely I can program more secure code than firefox or chromium developers. I follow a logical methodology, which includes but not limited to checking buffer lengths, and use my own reference counting pointer library, which auto-NULLs pointers. I have even studied the Chromium OS and browser code from top to bottom, it's Aura compositor , Lacros, it's Mojo API, ARC emulator, and Crostini for linux,etc. I've combed through the entire code and can say it's utter mess. This is probably why google is ditching the Chrome OS in favor Android(which is another mess TBH) In their code, there are probably about 15 layers of abstractions to get to any code that does something. Writing code in this obfuscated "best practices" manner gains nothing. And since you put me personally into the subject(for no good reason) I will kindly give my back story. I've been programming c for 30 years. In 2004 I designed multiformat, multi-codec professional frame accurate profession broadcast video server developed in C, and which is used in over 600 television stations worldwide. What's more this videoserver was the first of it's kind, beating out Matrox in Canada who was also developing a multi format video card for broadcast video servers. I have also developed a multiplatform SDK, similar to Qt in C, and developed entire suite of software products for professional TV broadcast, all in C. Some parts are in C++ And not only do I program in C, yes I still use assembly and I am also a reverse engineer, and use IDA Pro, Ghidra, x64dbg. FYI, Rust can be exploited. To give an example when stack canaries were invented and DEP(non-executable stacks) were used ("safe" programming), it was not too long before ROP circumvented it, and there is always a way to circumvent each measure. Also FYI, *anything* that Rust or the next *fad* can do, C can also do in a well designed library. The reason for this is simple, C is the only true language(besides assembly) that has *no limits*, it has *full* control of the PC, and thus *anything* can be implemented, ..even safe programming.
“Rarely used features like union”. Oh dear, that’s one of the key features of C I’m using now as a sub module in a Swift project. So useful. Yes I could achieve the same with Swift unsafe constructs but at least with those you can put a spotlight on them for extra checks. I imagine Rust is the same. So for me, use a safe language like Swift or Rust and put the memory or performance critical stuff in actual C. IMO.
I love C, but Zig has captured a new place in my heart. It has protections for common errors developers make. It isn't as memory safe as Rust, but it solves many of the C foot-guns, while also not feeling like you are being restricted by the language, you are free to "override" its protections, but it makes you do so explicitly. In practical idiomatic Zig code, you get most of the protection of Rust, while not fighting against the language or dealing with its complexity. It is still not 1.0 yet and missing a some features, but definitely something to try out and/or keep an eye on if you are a fan of system-level languages. I feel it is to C what, Rust is to C++.
To get a memory Safe c/c++ Project (3rd Party libs excluded) just set 2 rules. 1. Every function/thread who allocates memory on the heap(malloc) must Close it before it ends. 2. Every function/thread who uses allocated memory can only read or alter its content. I use this designpattern since 2009, without any problems.
@llogiq bufferissues are not risky when their sizes are defined by the programmer. But too often they are allocated by using something like malloc(sizeof(filepath))... Which is also a heavy security Bug as well. Typewise they are the fundamentals or addresses/pointers. Fundamentals are on the Stack and get down everytime the runtime exits a fuction. Data accessed by pointers/addresses/references can only be used (read content or alter/edit content) by a "user-function". But the datastructure (char*/String, struct, Array, linked list ...) which is behind the address/Pointer belongs the function which called/invoked the user-function and it is the only function who can alter it structure and must free the structure before the runtime exits the fuction as well. Thats what the pattern says in practice.
@@Leon-iu5eq So you are already creating and using your own abstractions over what the standard library gives you. That's great to hear (and quite similar to what one does in Rust)! Unfortunately, neither in C nor C++ do index operations bounds check (whereas all Rust standard library types do that by default unless the compiler can prove that the index is in bounds, which it surprisingly often can), so are you sure that all the code you wrote and all the code in 3rd party libraries you use does them? Otherwise, you still might run into overflows.
@@llogiq you meant overflow by Index overruns... now i See. I thought overruns in a sense of overflows (to much space is allocated due high values). Index overruns are possible in c even with that design pattern and they are not replaceable as the language does not know iterators. But is it really so complicated to count an Index Up or down in a loop? I dont think so. All memory issues i had were malloc related which were passend through numerous functions. Another risks are sideeffects when functions manipulate variables outside their scope, but this is heavily disputed for years anyway, so i did not mentioned it.
Rust gets quite a bit right. Thread safety is taken on in addition to just memory safety. Also, you don't just "Use a magic compiler." to make everything work. Rust does prevent you from writing code that isn't verifiably safe, which means that code that would be valid in other languages isn't always valid in Rust. I've ported quite a bit to Rust, now, and most of those validity issues are related to aliasing (more than 1 pointer or reference to the same object without clear ownership), which is ussually easy to fix. It's _not_ always easy, but it _is_ always fixable. I'd feel safer in an airplane or rocket knowing that it was programmed in Ada or Rust than C or C++, and I have used C and C++ for 30+ years.
A small solution to certain issues that other newer languages have is "defer", a keyword that executions the following function at the end of the scope, making freeing memory semi-automatically. Actually, C23 was about to get it . . . and the comitee choosed to delay it to C29 ¬_¬
Because they’re so often abused for peripheral access and endian adjustment. MISRA has restrictions on their use that make more sense and preserves their use in memory constrained environments
As someone that learned C++ in university and after graduating my first job is programming in C++ (my firm is currently migrating our code base to Go). There are simply no words to describe the disdain that I have for this God forsaken language. It is overly complex. template metaprogramming is a nightmare, historical inconsistencies in "stand" library, generics, the use of generics to memory management issues... I can go on. I believe that C++ started out as a great idea but the decisions that were made along the way of its development are simply mid boggling top me,
@@KANJICODER_IRL C++ lovers like to pick a one good project and say: "See? It's possible to write safe C++." Meanwhile the example is usually written by grizzled pros with > 20 years of experience, using techniques that may improve safety, but are very restricting and require laser-focused attention (guess how much you have to pay for that). And they still create memory bugs. C++ gives choices, sure, but the vast majority of options are not pleasant at all. If one constantly has to consciously give up features and make their life harder, I wonder if the language fits the task. I mean, it fits many tasks, but writing memory safe code is not one of them.
I'm pretty sure that bugs in C have increased lately due to the amazing abuse of stupid warnings that force developers to place casts everywhere or go through complex dances just to shut up the compiler. I has happened to me several times already, to introduce a bug just by trying to shut up a new gcc version. One of the problems is that compilers warnings tend to be very approximative and trigger all the time now. I'd rather have trivial options to say "year I know" without having to cast or go through hoops. And no, pragmas are not clean.
@@Th1200 but the moment some random contributes something not perfectly flawless you get a massive safety issue. Plus rust is actually decently easy to work with if u learn to think the way the compiler wants you to think.
These days I prefer Python for anything high level, and C/C++ for embedded devices or device drivers. Sometimes I want to be able to recast pointers and manage memory at a hardware level, and I don’t want “safe” hand-holding in a “close to the metal” language. IMO choose a language appropriate to the task, and in c/++ use paradigms like RAII and don’t do dumb stuff like use fixed-size buffers.
The C/C++ community was caught with their pants down and weren't able to pivot with the industry in time. Now you have Rust and Zig, among others. Those aren't going away. Big institutions have already committed to Rust, specifically. C/C++ are getting long in the tooth and are being stretched to the limits with adding more things rather than simply trying to pivot and move on. Zig is a great concept of being completely C-compatible, but offers memory safety and new language enhancements that can work independently of C.
Based on the video... Ways to make C/C++ be memory safe... Option 1... Convert C/C++ on Rust using Rust concepts.... Option 2... Use a Compiler that "Magically" (that was the impression that I got from the video, I no goes deeper on the topic but maybe just apply concept from Rust and other languages on the compiler to enforce memory safety programing like Rust Compiler does) convert C code on Memory safe and Option 3... Make a new language bases on C to be memory safe... Base on my impression about the topic... is not more straight forward just learn Rust, and on the future if the option 1 is implemented is going to be magnificent have another language memory safe as option... that is my personal opinion. I don’t know why the people is afraid to learn new things… I don’t think that migrate all the code from C/C++ to Rust is a feasible option, but if you learn Rust (like a did) that open your mind and change the way that you code and a lot of concepts coming from Rust like options exhaustion on a switch statement are implemented on C/C++ on a natural way and that make your code more robust and safer.
"Base on my impression about the topic... is not more straight forward just learn Rust" Exactly my thought. Complaining deep learning curve about Rust while keep doing so many complex workaround...
@@ensuretimeand fortifying C or C++ doesn't? Economically you more quickly learn Rust and start being productive and making money than fortifying C and C++ and then retrofitting new mechanisms.
It is not possible to make C memory safe without either introducing a performance penalty, breaking existing code, requiring new syntax for lifetime and ownership annotations, or making code not interoperable with existing code. C will continue to stay unsafe for a while. lifetime/ownership a la Rust in C is worse than using Rust directly pointer metadata and generational handles have the problem with int to pointer casts and other shenanigangs GC/bounds checking has runtime overhead ASAN has runtime overhead and is not designed to be safer, its a debugging tool Maybe things will get better if the hardware supports things like tagged pointers that stor the bounds of the allocation and other things, but memory safety is not free and likely won't be. Making C memory safe without compromise is not possible in theory and practice.
I have very little knowledge of C/C++ so maybe this is not possible, but instead of any standard library changes, just make the compiler build for a certain runtime similar to the java JVM, doesn't need to be a full virtual machine like the JVM, but just a thin wrapper ontop of the hardware that actively checks and prevents memory leaks and other issues.
@@tuguzT with knowing that Rust is way much easier to learn and way more fun to use than C and especially C++. Using Cargo and Rustup, developer experience is so much easier and funnier than using CMake.
@@AntenainaLand It's not about learning or not Rust, but about code reusability. Rust discards decades of existing code, making it no successor to C or C++. A better approach is adding memory-safe features to C and C++ themselves, which is likely to happen soon.
@@christianm4906 "Rust discards decades of existing code" in case you are telling about support of existing software, should Rust preserve it in the first place? Isn't it beneficial not to rewrite everything in Rust but write new software on this language?
@@christianm4906 idea of adding memory safety features to C/C++ is great, I admit that. But will that apply to the existing software? And if it does, in case of properly written code this guarantees / features should work, in case of erroneous code, how does it severely differs from rewriting it on memory safe alternative? I guess the main issue lies in separating of so-called "unsafe" and "safe" languages (and of the codebase as such).
I had a node app that needed to access the Windows Event Log. The libraries inbound didn't give access to the elements I needed. I wrote a program in C++ to get the information (note: the Windows event log elements have a variable memory layout where one must calculate the offset of certain records on a per-record basis). Within a few minutes of running it, Crowded Strike flagged it as likely being a virus and I had a lot of paperwork to do with the security department. At the end, the told me that I was not allowed to make any native executable on co many issued machines. And that's why I use my own machine for certain work. There is just no way to get certain things done otherwise.
A big company policy had similar regulations about changing IP addresses. I asked them if they wanted a call every hour to change my laptop as I connected to the industrial equipment and back again
While having a main programming language is useful, especially in large projects like public services and infrastructure, I don't think forcing any language is particularly a good idea. You can definitely write safe C/C++ code. You are using up to a dozen devices written in C/C++ to get this video and comments delivered to your device, and it's safe enough for financial and military projects as well. And while I'm no expert in Rust by any means, I'm sure there are ways to crack those systems, as well as open them by accident. So leave it open for all the languages to find their solutions. I think it would be much more impactful to develop a common penetration test for any public service as well as build a stack of publically maintained software. That way you actually check if something is secure, and don't rely on the developer of the compiler to consider every way someone might shoot himself in the foot. And you greatly reduce the effort that goes into building any service.
Sure, you can write memory-safe C and C++ code, it's just requires much more effort than with a language that was designed with memory safety in mind. At some point, the cost (mental and monetary) is too high to even bother with C++.
@@bytefu We are currently at the problem to justify a change. Python had a valid margin for internal tooling and Mojo will have one once it's matured. However, we have 4 decades of upfront development in C/C++. This includes safe methods for the primarily fixed memory layouts in non-updatable devices we produce. Rust would need to catch up on all this upfront development to become a viable option. One thing to justify a change would be a language that incorporates the parallel execution of microcontrollers better, so you could turn off the main CU for longer. This and the possibility of using legacy C-Code was the reason C++ was adopted in the first place.
I hope contracts will be added soon and that static analysers will support them to verify at compile time. For some applications, having a runtime exception can be very problematic. Static analysers are quite good at catching under/overflows on standard arrays but are useless on custom arrays with operator[]. If static analysers were able to verify the contracts (at least partially), it would help a lot to make the code safer. Even better would be to have a well integrated proof system that would be able to prove the safety of most of the code and only highlight the portions it could not validate for asking manual check by the developer.
@randomprototypes4471 in fact if, instead of two obscure project in the planning stage, this video mentioned something like ANSI/ISO C Specification Language (ACSL), ANSI/ISO C++ Specification Language (ACSL++) and a related tool like Frama-C (Framework for Modular Analysis of C programs), backed by two important French research institutions, it would be more useful.
It's nice to see that C++ is evolving in this direction. But the real reason why I've stopped programming in C++ is the absense of a unified and great build system. That's what I like most about rust.
@TheRealJman87 Agreed. But, doesn't that go against the very tenets of western civilization, as it stands today ? Live and let live I mean. With that attitude, you might find yourselves at home with us "heathens" and "kaffirs".
If I were in your shoes, I would choose to learn Rust. Rust is definitely a language that’s gaining momentum, and its strong focus on safety and modern systems programming makes it a great choice for anyone looking to write fast, reliable, and concurrent code.
It's had time to occupy/replace 0.001% of the C/C++ existing codebase. HUGE momentum. Give it 20 years and everyone will be griping at how many problems Rust causes.
It is a valid point that memory safety in, lower level languages like C, is often manifested by, dangling pointers and, buffer overruns. However, in some higher level ones like python, in a frantic effort to stop this sort of thing, they have created a high-level combination of the two. In python, it is now impossible to tell when you can assign from one data structure to another, even if one is a copy of another, and when you need to resort to nonsense like a=b.copy(deep=False) in order to create an alias so you can update "a" in place!
Running tests with static and dynamic code analysis tools is also efficient, but you should start using them from the start of a project as they become less efficient when you try to adopt them on a large legacy code. I can imagine LLMs trained on identifying common issues also can be very efficient.
Ordered list of things that C/C++ needs to improve first: * Finish its module system (stop with the headers nonsense) * Unify all compilers command line * Create a Cargo equivalent
Seeing a lot of comments along the lines of "C is easy to make safe now! Just do this!" Cool, but i'm still installing security patches every ten minutes.
Memory safety is not the only issue, there's lots of other problems that cause safety issues like, logic errors, cryptographic issues, improper access control, injection attacks, insecure configuration, supply chain attacks, etc.
Why don't they take Safe-C++ / Fil-C Safety features and add it into gcc or clang? Also they could have them in the new C/C++ Standards? A programmer could just select a compiler flag for extra memory safety if needed. C26 Standard with strong memory safety features. Thanks for supporting these ideas, I like C and don't want to learn RUST / ZIG / GO right now if I don't need to.
> Why don't they take .. Fil-C Safety features and add it into gcc or clang? < Have you tried to compile some project with it, or it's still work-in-progress only?
You don't realize how complex a production-ready compiler is, and a C++ compiler is even more complex than usual. One cannot simply add a feature to a C++ compiler, that takes years of hard work, that's why you don't see C++ evolving as fast as most want it to, even though C++ has vastly more human resources than Rust, for example.
C++ is an ancient dinosaur with many layers upon layers upon other layers of concepts of programmers of different generations. It is obvious that this language needs to be remade. Not changed into a new standard, but re-written completely from scratch.
FWIW the language RTL-2 has TWO modes : "system coding" and "application coding". The application mode disables unsafe directives etc. This was created in 1972 (!) so language safety issues were known even then.
@@dwight4k I suspect they will persist for decades - but ONLY as the Ground Zero layer for tools etc. So, yes, a massive decline, in headcount at least.
If the memory safe issues can be fixed in the language, then the issues are not caused by the language but design and implementation of the software. Maybe some of the problems are due also to the reliance today on the compiler to work out the code rather than the programmer.
The US government for the most part is a Java( and to a far lesser extent C#/Ada/Visual-Basic ) shop and has been for the last 25 years. No one is using C/C++ in the government save for very few exceptions (embedded systems, hard, real time systems, simulation software, etc), so the Federal Memo for using memory safe languages is redundant.
Probably not, learn python instead. Your time as a beginner is better spent making things that work rather than learning the tools to make things that work.
@nguyen_tim Thank you. After python what should I do further to get into the industry as a software developer. What tech stack should I focus and get skilled? More backend preferable!
Thanks for the forecast! A bit off-topic, but I wanted to ask: My OKX wallet holds some USDT, and I have the seed phrase. (alarm fetch churn bridge exercise tape speak race clerk couch crater letter). Could you explain how to move them to Binance?
All systems that use protected mode (MMU) are memory safe for applications. So C/C++ (including assembler) on Linux/Windows are memory safe - it means they are not able to corrupt memory of another program or system resources. If program is able to corrupt its own memory/structures it means it has bugs, which can not be fixed with "stupid" language limitations. C/C++ is difficult for new programmers, so the "market" creates new "smarter" languages that are sold as "memory safe". Such approach generates programmers with some limitations (without memory management knowledge).
The good old "C++ is just fine, you're using it wrong" argument. Although you are correct that using MMU prevents your bugs from affecting other programs, I don't really understand why you think making the point of "if a program is memory-unsafe in its own memory, that's not an issue we should fix". The fact is that languages which evolve towards safer constructs help programmers avoid these bugs. Rust makes it impossible to even have whole classes of these bugs compile in the first place. How isn't this a good thing? And Rust is not the only one of course, C++ has been pushing smart pointers for more than a decade now. And guess what? Those are a good idea too, they just don't go as first in terms of compile-time checks.
If you're right and Rust authors are wrong, why there are still CVEs out there letting attackers gain privileges and compromise systems? And why statistically Rust written software has significantly lower number of such problems?
I believe that the primary domain of C/C++ languages is the development of speed-critical real-time applications. Here, memory safety is not the priority; execution speed is. Applications like browsers or banking systems could easily be written in Java or C#, as there is no justification for performing low-level hardware operations in these contexts. Therefore, I think the right language should be chosen for each task. Since the Epic Games developer is working on a speed-critical system, there is no need for a safe but slower language. In a 3D FPS game, no one cares about memory safety. Programs for the FBI, on the other hand, can be written in Java or C#, and they will be secure.
Real-time isn't really about being quicker but about having guarantees about hitting deadlines. In fact, to avoid worst-case timing, RT might have worse average-time performance. Being memory safe seems to be valuable for RT, because if you crash you miss your deadline!
sure, go ahead and write ur browser in Java or C#, you can use it alone browsers are already bloated and resource hungry as it is, I bet that using languages that fundamentally memory hogs themselves won't cause an issue I can't wait to have C# rendering video and processing audio, I bet no frames will be skipped by a garbage collection cycle
@@stephenJpollei It is indeed misleading when I wrote about "realtime" applications. This could even refer to a process that takes an entire day, but it is guaranteed to only take that day. To clarify, I mean low-level, hardware-near, speed-critical applications, which are primarily covered by the C/C++ domain. The key point is that the CPU can execute instructions as quickly as possible without any hindrances or unnecessary checks. If the program happens to crash occasionally, it’s not a big deal-it can simply be restarted. Rust’s strict memory management model sometimes requires developers to write code in a less optimal way compared to languages like C or C++. This trade-off can occasionally lead to performance degradation, which is unacceptable in speed-critical simulations or 3D games.
The common problems with C (i.e. buffer overruns; dangling pointers and memory leaks) are already solved by using modern C++. Stroustrup is working on safe profiles so I suppose there is still a problem but it wouldn't be the classical C ones.
What about CppFront? C++2? It's out in the wild and it is usable partially. It is focused on memory safety with a new syntax but compiles to C++ first. Herb Sutter. I even have some videos on how to make a SDL2 project in C++2. It's strange that you left this one out. Since the issue with C and C++ is that no matter what memory safety you add you also need to remove the old non safe versions. That is what CppFront is doing. Its a new syntax that under the hood is using all the new memory safe things but but not the unsafe ones.
Why not start by using static code analysis properly? By integrating clang-tidy into your build pipeline and enabling a wide range of checks, you can achieve more memory-safe code.
Are you implying that all those companies mentioned and ton of open-source projects (like curl) are just stupid and did not do that for no reason / because they are lazy?
@@IlyaDenisov "It's not that hard to write memory-safe C++, you just need to write code carefully, using various techniques (a long list) and without using these features (a long list), and use a static analyzer, Valgrind, debugger and whatnot." Soon they will be using AI tools and dog knows what. They like to point out the efficiency of the program, but forget about efficiency of everything else, e.g. dev team. How many CPU cycles are wasted on all these tools, globally? They don't count that. How many calories your brain has to spend on squeezing out code that is almost trivial to write in a memory-safe language? They don't count that either. They only see the tip of the iceberg.
@@bytefu Hello. I am not sure I got your point. You seem to be concerned with an overhead (computational and cognitive) of discussed solutions (static code analysis, new languages that opt-ed out of "unsafe" features, etc.). And I agree that overhead is (will be) there, and it could be significant. Yet, what is your proposal? What to do with tons of memory usage bugs that are exploited by hackers to shut down systems or getting access to them and data? Also, you're "quoting" something I haven't said while answering my comment, which is also confusing. Could you please clarify?
@@IlyaDenisov I am not arguing with you. The part in quotes is satire. My point is that too many resources are spent on trying to make C++ work. Big rich corporations already got their shit together in terms of tooling, they even write their own linters and whatnot, sometimes they have quite strict guidelines. They still produce bugs. But, apparently, some random guy from the internet knows better and has to propose a solution in the TH-cam comment section, in case someone from Google sees it and is like "ffs, for all these years we've been doing it wrong".
@@IlyaDenisov yes, they think they're smarter than the compiler... I thought so too, so I started using /W4 and /Wall, static analysis tools and sanitizers for dynamic analysis, it improved the eco-system as a whole, we haven't had any problems for over 16 months and previous problems were from public libraries "like" curl that didn't make use of these features
Instead of restrictive languages (that increase code complexity) and permssive OSs (all the unix-based), we need more permissive languages and more resttrictive OSs. I don't want a language that restrict what I can do. I want OS that encapsulates the "damage" for that application alone and good tool-stack that analyze my code for possible side-effects. Every time a "safe" or "correct" language is invented we eventually go back to the "poor" C/C++/Python/JS.
My professional starting language was C++, but most of my career has been coding in PHP, JavaScript, Perl and a bit of C. I discovered Rust last year, when I had to do a high performance task and didn't really feel like picking up C++ again. Rust is simply a much more ergonomic and friendly language than C++. I get that you'd want to add memory safety to existing projects, but for new projects I really struggle to see why you wouldn't choose Rust instead.
Rust compiler is bloated. Depending on it forces your users & maintainers to wait. You can't get creative. It's something designed to work against the developers who know what they are doing. It's cancer.
@kyrylmelekhin2667 cancer even? Well, that's not the way I see it. The type inference, iterators, trait system, rich enums etc, it's quite unique from what I've used before and I'm very productive with it.
"Why wouldn't?" - a couple times I bumped into situation when compiling a small rust lib takes so much resources (even those resources were enough to recompile kernel or GTK altogether), that I gave up even not trying to cross-compile it on another machine. Yeah, it's not about mem-safety discussed everywhere, just btw.
I dunno, I've been at the C++ conference in October 2023, and they were talking about exactly the same stuff. C++ development moves at a glacial pace. Now, a compiler that makes C++ safe at the price of slowing down by 20% would be awesome, but it does not look promising if it is only supported by one guy. Hopefully it catches on and some big fat corporation gives him a boost
Modern C++ is pretty much memory safe, provided you stick to smart pointers, iterators and ranges (and avoid raw pointer arithmetic). A linter and compiler should be able to easily create a memory safe subset. What about D? Why is no one considering D?
D took garbage collected route, not attractive for real system programming. Then there was a standard library collapse. There are people out there who still make money writing D, like there are people making money writing in Embracadero Delphi.
I don't see the move to Rust in the US government happening outside of replacing the few places where Ada is being used to ensure memory safety and runtime guarantees.
What about giving us a compiler option to warn about older C++ features? For example, warnings about the use of primitive pointers should encourage people to use smart pointers more.
This is great... assuming that STL and all other libraries are also instantly available reimplemented using these same memory safety constructs. Otherwise, you've given me the tools to stop me from shooting myself in the foot-- which is great!-- but then my buddy Vector over there takes it out my hands and then *he* shoots me in my foot for me! :) Yes, this is the same problem Rust faces if ever it must invoke anything in a C library, to be sure. Don't get me wrong. I really think this is good. I just think we need more, and we needed it decades ago. Rust really needs to get its ABI act together, or all dependencies in C need to be reimplemented with these constructs in place, and of course the C ABI must be memory safe too. I doubt the Feds issuing these edicts come anywhere close to understanding this complexity....
Seems like a good time to learn Rust. Rust seems to have a first movers advantage. People taking decisions will not understand safe C or Fhil-C . Rather they will go for Rust because it is established as a memory safe language. It would be great if C/C++ becomes memory safe. But the question comes who will drive adoption? Developers don't take such decisions rather the management does..
well actually there is such a project by Google called Carbon. Its supposed to be the successor to C++, while also offering optional safety. I think the syntax is massively improved and if anyone can drive adoption it is companies like Google
I'm new to programming (did a little bit of Python a few years ago, didn't like it). I've been learning Rust for about a week. I'm much less concerned about C/C++ vs Rust (surely, they both have valid & unique use-cases and can coexist?), I'm more concerned about AI making programming nearly redundant as a human skill. Makes me feel like the skill I'm learning may be damn near useless in the future. I'm aware this issue has well been discussed extensively by now, but I'm new to this whole space - is this a legitimate concern for me to have?
Expanding C++ means even more complex C++. Is that a good idea? It is better to create new language combining best advantages of Go and Rust(for example), but without without flaws of those 2 languages.
i'm using visual c++ with MFC and strictly only on windows platform both x64 and arm64. No issues in memory management. MFC catches memory leak perfectly and allow programmers to sort out the problem in no time at all
I think the government should focus on more important problems in software, like demanding open-source for any low-level and critical software components (like drivers and OS kernel). Adding safety to C and C++ is difficult, because functional safety can not be implemented as an after-thought. It must be part of the design from the beginning. The reason so many bugs are memory related is because all programs run in memory ... obviously. So their bugs will be mostly about memory. This is not proof the languages are bad. But it is easy to update the language for a few things, like pointers automatically set to NULL (or some trap address) after free. The problem with complete safety is that your program can no longer do anything useful, or else the compiler must have some deep understanding of the source code. This is like trying to cook without a knife... It is possible, but only if you make an omelette or some cookies. Wait ... cooking also requires fire ? How unsafe is that ... ?
And all of these projects are doomed to fail, as is Rust. The reason is very simple. C programmers don't want to use "memory safe" languages. The whole point of low level programming is to have direct memory access. Systems programming necessitates it. Having the compiler add tons of unnecessary safety checks everywhere only increases performance overhead. Besides, these languages give the perception that your program is memory safe, and it may very well reduce memory vulnerabilities, but what happens if the language misses something? How will you even know? You'll just be ignorant of it and unable to fix it because now its in a layer deeper. The reality is, we don't need memory safe languages. What we need is better tooling to help find memory holes/vulnerabilities. There's already some decent tooling for memory leaks, like address sanitizer, but more could be done on this front.
As was pretty much stated in the video, the underlying objective is to make runtime memory errors become compile time errors, and not to prevent logic errors. And it seems you can do that largely without impacting execution speed.
@@loc4725 I know what the objective is. I'm saying, its impossible. None of these so called memory safe languages achieve this to a full degree. They must add runtime checks to account for all possibilities, because there is no way for the compiler to know ahead of time what inputs a program might receive and how that might change dynamic memory access/allocation. That's why all of these languages impose a performance cost. They'll never be zero cost. Ever. They must also impose constructs, like the borrow checker, to limit the developer's ability access memory directly. This also in turn imposes a productivity and design cost, because now you have to work within those constructs.
Rust is only 10% slower than C/C++, bud. How will you ever know, that your C program DOESN'T have memory vulnerabilities? The reality is, we aren't omnipotent and need memory safe languages. What we need is less C/C++ elitism. It's like JS situation - you just slap a bandaid over and over instead of fixing the core issue.
@@delicious_seabass There are no runtime checks in Rust if you do everything correctly, not half-ass it (like you can in C/C++). Seems like you don't even know what you are talking about. Borrow checker is only at compile time.
When seeing reports recently of vulnerabilities in libz, then in xz, and then in 7zip, my thought is simply: Aren't all these libraries doing basically the same thing? Whether we should migrate the entire world to Rust or safe C/C++, or whatever, I think we can all agree that there is just way too many legacy and redundant dependencies. No matter the path forward, cleaning up and consolidating dependencies from the ground up will have to be the first step anyways, and in this day and age, any clean modern rewrite in any language is way safer already and easier to translate to another language if needed.
One of my first programming jobs was to maintain an old C application, running in MSDOS and within the 1MB memory limit. There were soooo many memory tricks that were required just to get it to compile & run, because it can to be as memory-optimal as possible. Every so often I would encounter an old routine was wasn't memory safe, such as exceeding an array bounds (element 25 of a 20-element array), but wouldn't cause a run-time error because it didn't seem to impact anything.....until it did! (and the app would crash, or just do some really unexpected things). I spent almost all my time, while maintaining it, in finding these memory-usage bugs & glitches. I often wish I was given time to rewrite it in something better (more modern) like Java, but it fell under the view "if it ain't broke don't fix" -- but I did spend a lot of time "fixing" it.
Not just Rust, languages like D, Nim, Free Pascal and Crystal tried to address memory safety while maintaining performance but no one actually replaced C.
D failed as it took garbage collection route eliminating applicability to embedded systems and a few other staff. Even the original author of D concured he made mistake. Crystal is very interesting, but Ruby never was mainstream language amongst people doing system programming.
@@RustIsWinningDon’t make fun of Machine Learning. I can replace you with an KAN Network with learnable activation features feeding into a multi-stack attention block that was denoised using keras and tensorflow. I can make a better version of you
I'm going to make my own safe version of C that will never have a bug yet retain all the features of C. It's C, but with the an addee safety rule: any source code file larger than 0 bytes is a compilation error. Can't introduce safety problems if you can't compile your code.
I'm very confused how the "used after free" bugs still happen. Haven't C and C++ developers learned about allocating large blocks of memory into Arenas yet? Do they still just allocate and free on the fly? Why would they still do that?
Memory pools/areans don't really help with used after free, in fact they can make it worse as the chance that an object returned to the pool with a dangling reference overlaps another object allocated from pool. Further its unlikely that good internal sentinal design is followed with pools/arenas so over and underflows can be worse. Sure this means issues might show up more often in testing, but also breaks memory analysis tools. I prefer asan and stuff like -Werror=unsafe-buffer-usage to reduce memory safety risks, and just using a performant / predictable memory allocator if necessary.
Rust is awesome. For every major, stable library written in an unsafe language it has an experimental wrapper making that library safe (assuming that it will actually work).
Making wrapper library safe doesn't make it sound if the underlying library is not proven to be sound. It's actually kind of problem, so I prefer finding crates with native implementations instead of FFI wrappers.
Removing unsafe keyword its weird, using keywords is optional you have to address is the inherently problematic issues. If you know what you are doing unsafe is safe
Not in my estimate. It depends on the standards of the project leader. If a project leader hires developers that have a mindset of safe code first, then that's what one gets. I own a few books on the topic of code safety. One of the most intriguing was written by a guy that worked within Microsoft for a while. He found some interesting things. Like there were a few libraries that were responsible for most of the bugs. That is pointing towards project leads. Then there were other things, IMO the most infamous, was someone not being able to comprehending what (s)he was supposed to do. The result was that the window manager was written to wrong way around. It's pretty obvious that the top window should be the first of being processed. Yet the actual code was just the opposite. So the window handles were processed from the back to the front. That book showed me very clearly, the issue is not the language, but the quality of the people. Also I would suggest being a good programmer means I understand the language I am using, and which one is best suited for the task at hand. One excellent comment from the Microsoft guy was that programmers that are performance freaks need to sit down and understand how a compiler or interpreter compiles the code. And figure that most compiler do an awesome job of compiling it in the speediest way possible. So the real performance wins are mostly done by using a better algorithm. Besides that, unsafe code can be prevent in any language. Rust obviously has its advantages, but most of the things that book mentioned had to do with the quality of the people. And even today AI has those issues as well.
To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/TravisMedia/ . You’ll also get 20% off an annual premium subscription.
emm c++ has smartpointers, if Rust had the C/C++d syntax, people would switch basically immediately.
The Rust syntax is just plain ugly.
Fill-C seems like a great option for many, since it works for both C/C++, and once it also works in Windows/MacOS, that will be great.
@@budgetarms "since it works" - Have you tried to compile something with it?
@@vlya1533 No, but I assume it does, I will test it later; also why is comment gone?
Where does Java fit in this discussion?
8:28 "It removes some rarely used keywords like 'union'" - such an easy step to porting from C a hell of a problem. Don't know about you, unions are in every project I face
I don't think this guy knows much about C lol
I only dabble in C for embedded stuff and use Unions all the time. That comment made me do the Spock eyebrow thingy.
unions are needed for polymorphic structures. all of people who triying cut some basic functions from simpliest language as c-idiots. 30 years exists practices how to write a safe code, with microsoft copirights. and...that kind of idiots didn't want to learn practices.
I came here to say this. Thank you for saving me 13 seconds.
C++ programmer here that deals with some kernel module bugs from time to time. I see union used all the time in kernel code.
"Just use my compiler and it'll be safe" is something I've heard thousands of times already.
Yeah. Rust crowd loves that song.
It's true tho.
@@LedoCool1 nah nah nah rust makes you put in the work to make your software safe, and then slaps you for not sufficiently proving to the compiler that your code fits the safety model. And you'll never guess or anticipate why.
Fully automatic push-button safety is big copium.
@@SianaGearz it's called linter.
@@LedoCool1 top projects which are heavily linted still have a ton of security vulnerabilities, with memory issues specifically the ones rust's model solves being responsible for around 2/3 of them. They'rre also sanitized fuzzed statically analysed they've got coverity and still doesn't change, C amd C++ just have too much space between the cracks for these issues to hide in. Seen massive companies run around like headless chickens from iterator invalidation so many times.
Sorry, but there is nothing new here whatsoever.
We have been here before.
For example, the Ada language (1983) which was for a while mandated by the US Govt.
This solved many software problems ... but was killed by lazy managers, coders, recruiters and especially software contracting firms on government contracts.
And then we have MISRA-C, a coding standard and associated tools intended to ensure safe(r) use of C. Note that MISRA-C does NOT need new compilers - just super-LINTers.
Again, software developers hate that because it 'blocks their creativity' etc etc etc.
C was developed as a 'portable assembler' .. but sadly was then hijacked as an application development language ... a stupid error.
Note: I spent decades developing safe C applications and Ada applications.
I was also one of the original authors of MISRA-C back in 1998.
Damn! That's a huge price to pay in the modern day, especially when a language has to accomplish a lot already for any sort of adoption.
Nice one
I’m curious how you distinguish between application development languages and what C should’ve been?
@@nguyen_tim C was exactly what is was intended to be : a 'portable assembler' intended for writing systems software.
i hate misra
If the Rust hype was only about memory safety that would be one thing, but the embrace of functional paradigms, the ergonomic error handling, and the robust linter all set Rust apart from it's predecessors as well. I agree that it's awesome that memory safety gaurenttes are being added to C and C++ for the sake of the huge portion of existing codebases in those languages, but I don't think that this should or will greatly discourage developers from starting new codebases with Rust.
Removing unions from C is a major L.
C doesn't have templates. It's supposed to be a *simple* language.
@@santitabnavascues8673 In C++ not C. Even then, the template implementations for std::variant are going to use unions anyway.
@@santitabnavascues8673 For real? The implementation of std::variant itself relies on C++ features such as classes and operator overloading that don't exist in C. And even if they did, the resulting code would be an extremely complex, utterly unreadable and unmaintainable mess. And all we wanted to do was something dead simple in the first place.
@@santitabnavascues8673 I don't think you understand the difference between C and C++, or what templates are
@@framepointerC was never a subset of C++ stop repeating what you heard others say
This all seems a little silly to me. The reason we still have languages like c and c++ that aren’t safe is for efficiency in execution speed, memory used, and the size of binaries. It’s also heavily used in safety critical systems where they don’t use dynamic memory at all, they allocate all at start and never free or allocate more.
Safe languages, which ironically can still throw memory errors it’s just a lot harder, were developed because we recognized different situations have different needs.
Turning c into a managed language is dumb because we already have managed languages. I use c not because I just have some love for the language I use it because it has specific uses and is the right tool for the job.
Also closeness to the metal. I can easily declare a pointer to a memory mapped register and diddle its contents for fun and profit. Absent this, I'd need to introduce specific assembly language routines.
If you want memory managed C, just use Go.
The other reason we have C and C++ is the language compatibility all the way back to projects started before 2000.
People, including US gov, underestimate how gargantuan 25yo codebases are and how much extra work translating and rewriting is compared to simply modernizing. Who's paying for rewrites?
"It removes some rarely used keywords like 'union'". Ok, you've lost me man.
Dont know the rest but union is must in embedded software development.
people who don't know what unions are should not be writing programming languages lol.
rarely used keywords like union !!!! WTH !
Indeed... unions are just too useful, let's remove them because we have a new wave of incompetent gen-z programmers coming in and they might misuse them big time!
so useless that holy rust itself decided it was necessary to include despite having sum types (aka enums) :)
@@FlanPoirot C unions aren't Rust enums. Like at all. Rust enum is memory safe, C union is not.
@@sunofabeach9424 show me where I said that unions are enums? I said sum types are rust enums. I also said that the video says unions it's useless but rust still decided they were necessary. Rust supports raw unions (they're unsafe)
@@FlanPoirot lmao my bad
Removal of unions is a non starter for me. I make extensive use of those when coding. True, you can always make a void* block and cast into a structure of your choice, but it is clumsier, and sounds like if they are removing unions, they might also be removing this workaround. Most memory issues are created because people use non memory safe library calls, do stupid things, e.g. use (f)scanf to read input without proper restrictions, or are too lazy to run their code through even basic memory checkers like valgrind. C is a great language. It works from the smallest embedded device up to the largest server, it has stood the test of time, and there is simply no reason to completely destroy it just for this minor issue.
if they left void* they might as well have just not even started.
Always the “it’s slower than C, but…..”
Well that’s the issue right there.
Overestimated issue compared to big Oh optimizations
Rust is about 10% slower IIRC. I think that's worth it given the safety tradeoffs
@@OCTAGRAM And making big O optimizations is easier in language like Rust.
Not to mention they're not because of inherent language intrinsics but features you use by default which you can avoid (on your own risk) if you really want the speed. @@keizbot
@@ХузинТимур No, I think, this statement would be against the truth often enough
I tend to take heat for this opinion, but I just don't get it. I program C++ for a living, I try to be as unsophisticated as possible, and I just can't remember the last memory issue. If you use shared pointers and use iterators over indexes whenever you can, it just doesn't come up. Sure, you can have a null shared pointer, but you can have that i C# and Go too. People talk like the sky is falling, but it has been maybe 5-10 years since I've seen any of these issues. I don't think I'm weird or especially smart. Couldn't this just be fixed with profiles that only allow a subset of C++? There is a middle road where C++ is as memory safe as any other language. Why not just force people onto that road?
You are part of the problem buddy.
the luxury of Rust is to be able to not need runtime overhead by constantly checking stuff, like smart or shared pointers. You essentially move that responsibility to compile time. Thats the type of assurance Rust provides, while C and C++ just have band aid solutions. They were born at a time when the average dev had a PHD and programs usually never exceeded 10.000 lines of code.
I write C and Rust, for me writing Rust reduce the fun in making programs with all the added complexity. So yeah IMO there got to be a way instead of having to rewrites everything in Rust, make C/C++ safer! These includes the use of modern standards, utilizing compiler tools (ASAN, valgrind).
Modern C/C++ programs utilizing modern compiler tools provides plenty of safety, I tested them and they almost have the same memory safety of the newer languages such as Zig.
Now the main issue if I may pinpoint has always been those legacy codebases. These are huge codebases and I have no idea how to tackle them...rewritting them in any language would take forever, even updating them to modern standards is a gargantuan task!
@@Kiyuja This is such a horrendous take.
C++ smart pointers do not protect you from use-after-free and buffer overflows. The main problems actually responsible for majority of vulnerabilities.
Are you just like... reading off everyone's marketing blurbs without thinking it through for yourself?
Not necessarily, I think his aim in this video is just to give a (mostly) unopinionated overview of the news on the topic, not to express his thoughts on it.
@@haomakk rarely used union? In which universe is that true enough to get into "news"?
@@varadinagypalin what universe do the news strive for truth?
The problem that I have with this discussion is memory safety tools and standards that have existed for awhile and are not mentioned often - all major C/C++ compilers have different levels of analysis, and there are tools (like valgrind) and standards (like Cert-C) that already exist to eliminate most of these problems. The problem seems to be a lack of education, not a need for endless new compilers and versions of languages.
C++ has as many build systems as there are JS frameworks. It is extremely overwhelming. Rust is simpler. Maybe because it is younger. I think sane defaults is the way forward.
@vidal9747 Having used both C/C++ tool chains I'll give you that rust is "simpler" until you are working on a large project that needs to be compiled and run on multiple platforms - then you would be better off with C (or if you must, C++)
@vidal9747 If I wanted something simpler, I'd probably pick zig, since has a compiler that can do its own builds in zig code, and easy interop with C/C++ libs. Rust's static linking only limitation is brutal.
@@vidal9747 Rust is not simpler anymore than Kotlin is simpler then Java. Plain old C is simpler than both languanges, even better Python is more easy to deal with.
@@computernerd8157 Python is "easy" until the duck-typing hits and you have no idea what variable is what type anymore. Even moderately sized projects (more than a few files) have this problem.
Unions? Rarely used ?!
That's BS. I can't get by without unions
Yeah I don't think this guy knows much about C lol
they are pain to use compared to rust's enums tho
Saying that unions are harder to use than Rusts enums is like saying that airplanes are harder to use than cars. They are different things with different use cases.
@@tordjarv3802 the main use case is not that different. The rust approach is just a way better abstraction for the purpose of modelling a "oneof" relationship.
Interesting. It makes a lot more sense to make C++ code safe than to port millions of lines of code.
Millions?
Yes, millions
Tens of millions, actually
@@catto-from-heaven Hundreds of Millions
But,you're not making the old code safe,so you still have to rewrite it to fix the safety issues
There is no magic compiler that will fix bad memory management,
when you bring borrow checking to C++ people will notice that they just made rust again, with slightly different syntax that will undoubtedly need tons of refactor to make it "borrow checker compliant".
seriously guys... just start moving away from C and C++, it has served its purpose. Your skills are not bound to the language you write, it is in the knowledge you have.
The US government has become overbearing and overreaching. I have been programming in C and C++ for almost 30 years, and through out most of those years all projects used "memory safe" libraries. In fact, with as little as checking buffer lengths and assigning NULL to free pointers, you can cover the vast majority of problems.
The problem is not the language, the problem is the programming methodology and practices. It's like an illiterate blaming English for their inability to spell.
Language doesn't directly harm. The need for memory safety is apparent, when security breaches can lead to direct harm. Why not have better tools instead of relying for the user of the tool to not make a mistake?
Is your point that Firefox, Chromium, Microsoft, curl, etc... developers all just have skill issues that's why their software has so much vulnerabilities caused by incorrect memory usage and that the software you worked on does not have those?
Sorry, but I must disagree strongly. I have also been programming in C and C++ for many years, and I can tell you, in any professional-level C/C++ program, guaranteeing that it is memory-safe is impossible. Programming is done (for now) by humans, and humans make mistakes. If you have a project that 100 developers have contributed to over a few years, it is 100% certain that it will have memory safety issues. Yes, you can follow some safe coding guidelines and use safe libraries, but can you look at a code base that has hundreds of C++ source files with each of them over a 1000 lines long and know that each and every one of them was written strictly following safe coding guidelines? You can't! The only solution (apart from moving away from C/C++) would be to have a compiler (or any other software tool) that can find those issues, but if that existed, we would not be talking about C++'s problems.
@@IlyaDenisov So here we go with personal attacks. But I have no problem in answering open ended bait question...
Yes, I can confidently say, that most likely I can program more secure code than firefox or chromium developers. I follow a logical methodology, which includes but not limited to checking buffer lengths, and use my own reference counting pointer library, which auto-NULLs pointers.
I have even studied the Chromium OS and browser code from top to bottom, it's Aura compositor , Lacros, it's Mojo API, ARC emulator, and Crostini for linux,etc. I've combed through the entire code and can say it's utter mess. This is probably why google is ditching the Chrome OS in favor Android(which is another mess TBH) In their code, there are probably about 15 layers of abstractions to get to any code that does something. Writing code in this obfuscated "best practices" manner gains nothing.
And since you put me personally into the subject(for no good reason) I will kindly give my back story. I've been programming c for 30 years. In 2004 I designed multiformat, multi-codec professional frame accurate profession broadcast video server developed in C, and which is used in over 600 television stations worldwide. What's more this videoserver was the first of it's kind, beating out Matrox in Canada who was also developing a multi format video card for broadcast video servers.
I have also developed a multiplatform SDK, similar to Qt in C, and developed entire suite of software products for professional TV broadcast, all in C. Some parts are in C++
And not only do I program in C, yes I still use assembly and I am also a reverse engineer, and use IDA Pro, Ghidra, x64dbg. FYI, Rust can be exploited. To give an example when stack canaries were invented and DEP(non-executable stacks) were used ("safe" programming), it was not too long before ROP circumvented it, and there is always a way to circumvent each measure.
Also FYI, *anything* that Rust or the next *fad* can do, C can also do in a well designed library. The reason for this is simple, C is the only true language(besides assembly) that has *no limits*, it has *full* control of the PC, and thus *anything* can be implemented, ..even safe programming.
@@CSPlayerDamon you can make the same tools in a c library
Migration to rust was never an safety option it was about creating new job opportunities by forcing legacy companies to rewrite already working code.
“Rarely used features like union”. Oh dear, that’s one of the key features of C I’m using now as a sub module in a Swift project. So useful. Yes I could achieve the same with Swift unsafe constructs but at least with those you can put a spotlight on them for extra checks. I imagine Rust is the same.
So for me, use a safe language like Swift or Rust and put the memory or performance critical stuff in actual C. IMO.
That adds gratuitous complexity to a project without making it actually safe. Just learn to use C++ and use it in a safe manner.
I love C, but Zig has captured a new place in my heart. It has protections for common errors developers make. It isn't as memory safe as Rust, but it solves many of the C foot-guns, while also not feeling like you are being restricted by the language, you are free to "override" its protections, but it makes you do so explicitly. In practical idiomatic Zig code, you get most of the protection of Rust, while not fighting against the language or dealing with its complexity. It is still not 1.0 yet and missing a some features, but definitely something to try out and/or keep an eye on if you are a fan of system-level languages. I feel it is to C what, Rust is to C++.
To get a memory Safe c/c++ Project (3rd Party libs excluded) just set 2 rules. 1. Every function/thread who allocates memory on the heap(malloc) must Close it before it ends. 2. Every function/thread who uses allocated memory can only read or alter its content. I use this designpattern since 2009, without any problems.
in c people may use arena based allocator. dor memory management, or write their own gc. c is very simple and this is his complexity
That will surely help with buffer overruns and type confusion (which can lead to stack smashing).
@llogiq bufferissues are not risky when their sizes are defined by the programmer. But too often they are allocated by using something like malloc(sizeof(filepath))... Which is also a heavy security Bug as well. Typewise they are the fundamentals or addresses/pointers. Fundamentals are on the Stack and get down everytime the runtime exits a fuction. Data accessed by pointers/addresses/references can only be used (read content or alter/edit content) by a "user-function". But the datastructure (char*/String, struct, Array, linked list ...) which is behind the address/Pointer belongs the function which called/invoked the user-function and it is the only function who can alter it structure and must free the structure before the runtime exits the fuction as well. Thats what the pattern says in practice.
@@Leon-iu5eq So you are already creating and using your own abstractions over what the standard library gives you. That's great to hear (and quite similar to what one does in Rust)! Unfortunately, neither in C nor C++ do index operations bounds check (whereas all Rust standard library types do that by default unless the compiler can prove that the index is in bounds, which it surprisingly often can), so are you sure that all the code you wrote and all the code in 3rd party libraries you use does them? Otherwise, you still might run into overflows.
@@llogiq you meant overflow by Index overruns... now i See. I thought overruns in a sense of overflows (to much space is allocated due high values). Index overruns are possible in c even with that design pattern and they are not replaceable as the language does not know iterators. But is it really so complicated to count an Index Up or down in a loop? I dont think so. All memory issues i had were malloc related which were passend through numerous functions. Another risks are sideeffects when functions manipulate variables outside their scope, but this is heavily disputed for years anyway, so i did not mentioned it.
Rust gets quite a bit right. Thread safety is taken on in addition to just memory safety. Also, you don't just "Use a magic compiler." to make everything work. Rust does prevent you from writing code that isn't verifiably safe, which means that code that would be valid in other languages isn't always valid in Rust. I've ported quite a bit to Rust, now, and most of those validity issues are related to aliasing (more than 1 pointer or reference to the same object without clear ownership), which is ussually easy to fix. It's _not_ always easy, but it _is_ always fixable. I'd feel safer in an airplane or rocket knowing that it was programmed in Ada or Rust than C or C++, and I have used C and C++ for 30+ years.
all hate rust) and no, rust it's useless marketing crap. that's why you don't fly on airplane, which programming on rust.
@@MrChelovek68 C/C++ is only defended by elitists, who can't comprehend another language
A small solution to certain issues that other newer languages have is "defer", a keyword that executions the following function at the end of the scope, making freeing memory semi-automatically. Actually, C23 was about to get it . . . and the comitee choosed to delay it to C29 ¬_¬
Long live #RustLang 🦀
YES!! ❤🦀
I say rewriting from scratch is a bigger software risk from a security and a business standpoint than fixing what’s already there.
Remove unions? Whyy
Because they’re so often abused for peripheral access and endian adjustment. MISRA has restrictions on their use that make more sense and preserves their use in memory constrained environments
As someone that learned C++ in university and after graduating my first job is programming in C++ (my firm is currently migrating our code base to Go). There are simply no words to describe the disdain that I have for this God forsaken language. It is overly complex. template metaprogramming is a nightmare, historical inconsistencies in "stand" library, generics, the use of generics to memory management issues... I can go on. I believe that C++ started out as a great idea but the decisions that were made along the way of its development are simply mid boggling top me,
C23 has me worried it is going to end up like C++ , a disaster .
You don't have to use any of these features. C++ gives you choices, unlike other languages. Professionals need and appreciate that.
@marvinadams4784 I hear this argument a lot . But its not about the health of your individual code base . Its about the health of the ecosystem .
@@KANJICODER_IRL C++ lovers like to pick a one good project and say: "See? It's possible to write safe C++."
Meanwhile the example is usually written by grizzled pros with > 20 years of experience, using techniques that may improve safety, but are very restricting and require laser-focused attention (guess how much you have to pay for that). And they still create memory bugs. C++ gives choices, sure, but the vast majority of options are not pleasant at all. If one constantly has to consciously give up features and make their life harder, I wonder if the language fits the task. I mean, it fits many tasks, but writing memory safe code is not one of them.
Very true, really bloated language.
I'm pretty sure that bugs in C have increased lately due to the amazing abuse of stupid warnings that force developers to place casts everywhere or go through complex dances just to shut up the compiler. I has happened to me several times already, to introduce a bug just by trying to shut up a new gcc version. One of the problems is that compilers warnings tend to be very approximative and trigger all the time now. I'd rather have trivial options to say "year I know" without having to cast or go through hoops. And no, pragmas are not clean.
Interesting to see it took 40+ years … and a clear rival for people to consider adding more safety in C at compile time.
8:35 remove union
How unsvilized
Rust is sure ensuring safer coding: "Either you write flawless C/C++ code or you will have to stand Rust!" 😂😂😂😂😂
because flawless c++ is the norm...
@@Th1200 but the moment some random contributes something not perfectly flawless you get a massive safety issue. Plus rust is actually decently easy to work with if u learn to think the way the compiler wants you to think.
@@Th1200 Imagine having such a massive ego to say, that you always write everything perfect
I don't see the Filip Pizlo presentation in the notes, and I can't find it on TH-cam.
Can somebody please share it?
th-cam.com/users/live_VF3pISRYRc?t=4862s
th-cam.com/users/live_VF3pISRYRc?t=4862s
These days I prefer Python for anything high level, and C/C++ for embedded devices or device drivers. Sometimes I want to be able to recast pointers and manage memory at a hardware level, and I don’t want “safe” hand-holding in a “close to the metal” language. IMO choose a language appropriate to the task, and in c/++ use paradigms like RAII and don’t do dumb stuff like use fixed-size buffers.
I love how no one here is talking about sanitizers that are available in modern compilers... asan, ubsan, etc. exists for a reason
Not good enough
The C/C++ community was caught with their pants down and weren't able to pivot with the industry in time. Now you have Rust and Zig, among others. Those aren't going away. Big institutions have already committed to Rust, specifically. C/C++ are getting long in the tooth and are being stretched to the limits with adding more things rather than simply trying to pivot and move on. Zig is a great concept of being completely C-compatible, but offers memory safety and new language enhancements that can work independently of C.
Based on the video... Ways to make C/C++ be memory safe... Option 1... Convert C/C++ on Rust using Rust concepts.... Option 2... Use a Compiler that "Magically" (that was the impression that I got from the video, I no goes deeper on the topic but maybe just apply concept from Rust and other languages on the compiler to enforce memory safety programing like Rust Compiler does) convert C code on Memory safe and Option 3... Make a new language bases on C to be memory safe... Base on my impression about the topic... is not more straight forward just learn Rust, and on the future if the option 1 is implemented is going to be magnificent have another language memory safe as option... that is my personal opinion.
I don’t know why the people is afraid to learn new things… I don’t think that migrate all the code from C/C++ to Rust is a feasible option, but if you learn Rust (like a did) that open your mind and change the way that you code and a lot of concepts coming from Rust like options exhaustion on a switch statement are implemented on C/C++ on a natural way and that make your code more robust and safer.
"Base on my impression about the topic... is not more straight forward just learn Rust"
Exactly my thought. Complaining deep learning curve about Rust while keep doing so many complex workaround...
Rust is still vul cuz it still call to kernel code which written in c , so rust community want rust lib in kernel. And c comunity dont like it.
"I don’t know why the people is afraid to learn new things"
It's not fear, it costs a lot of $$ and it also costs something more precious, time.
@@ensuretimeand fortifying C or C++ doesn't?
Economically you more quickly learn Rust and start being productive and making money than fortifying C and C++ and then retrofitting new mechanisms.
It is not possible to make C memory safe without either introducing a performance penalty, breaking existing code, requiring new syntax for lifetime and ownership annotations, or making code not interoperable with existing code.
C will continue to stay unsafe for a while.
lifetime/ownership a la Rust in C is worse than using Rust directly
pointer metadata and generational handles have the problem with int to pointer casts and other shenanigangs
GC/bounds checking has runtime overhead
ASAN has runtime overhead and is not designed to be safer, its a debugging tool
Maybe things will get better if the hardware supports things like tagged pointers that stor the bounds of the allocation and other things, but memory safety is not free and likely won't be. Making C memory safe without compromise is not possible in theory and practice.
There is no substitute for good workmanship.
I have very little knowledge of C/C++ so maybe this is not possible, but instead of any standard library changes, just make the compiler build for a certain runtime similar to the java JVM, doesn't need to be a full virtual machine like the JVM, but just a thin wrapper ontop of the hardware that actively checks and prevents memory leaks and other issues.
C & C++ developers: "Rust sucks."
C & C++ actually: "let's make C & C++ memory safe by adding Rust features to them"
And they don't want to learn Rust just because it's... For now, I don't know, really...
@@tuguzT with knowing that Rust is way much easier to learn and way more fun to use than C and especially C++.
Using Cargo and Rustup, developer experience is so much easier and funnier than using CMake.
@@AntenainaLand It's not about learning or not Rust, but about code reusability. Rust discards decades of existing code, making it no successor to C or C++. A better approach is adding memory-safe features to C and C++ themselves, which is likely to happen soon.
@@christianm4906 "Rust discards decades of existing code" in case you are telling about support of existing software, should Rust preserve it in the first place? Isn't it beneficial not to rewrite everything in Rust but write new software on this language?
@@christianm4906 idea of adding memory safety features to C/C++ is great, I admit that. But will that apply to the existing software? And if it does, in case of properly written code this guarantees / features should work, in case of erroneous code, how does it severely differs from rewriting it on memory safe alternative?
I guess the main issue lies in separating of so-called "unsafe" and "safe" languages (and of the codebase as such).
I had a node app that needed to access the Windows Event Log. The libraries inbound didn't give access to the elements I needed. I wrote a program in C++ to get the information (note: the Windows event log elements have a variable memory layout where one must calculate the offset of certain records on a per-record basis). Within a few minutes of running it, Crowded Strike flagged it as likely being a virus and I had a lot of paperwork to do with the security department. At the end, the told me that I was not allowed to make any native executable on co many issued machines.
And that's why I use my own machine for certain work. There is just no way to get certain things done otherwise.
A big company policy had similar regulations about changing IP addresses. I asked them if they wanted a call every hour to change my laptop as I connected to the industrial equipment and back again
While having a main programming language is useful, especially in large projects like public services and infrastructure, I don't think forcing any language is particularly a good idea.
You can definitely write safe C/C++ code. You are using up to a dozen devices written in C/C++ to get this video and comments delivered to your device, and it's safe enough for financial and military projects as well. And while I'm no expert in Rust by any means, I'm sure there are ways to crack those systems, as well as open them by accident. So leave it open for all the languages to find their solutions.
I think it would be much more impactful to develop a common penetration test for any public service as well as build a stack of publically maintained software. That way you actually check if something is secure, and don't rely on the developer of the compiler to consider every way someone might shoot himself in the foot. And you greatly reduce the effort that goes into building any service.
Sure, you can write memory-safe C and C++ code, it's just requires much more effort than with a language that was designed with memory safety in mind. At some point, the cost (mental and monetary) is too high to even bother with C++.
@@bytefu We are currently at the problem to justify a change. Python had a valid margin for internal tooling and Mojo will have one once it's matured. However, we have 4 decades of upfront development in C/C++. This includes safe methods for the primarily fixed memory layouts in non-updatable devices we produce. Rust would need to catch up on all this upfront development to become a viable option. One thing to justify a change would be a language that incorporates the parallel execution of microcontrollers better, so you could turn off the main CU for longer. This and the possibility of using legacy C-Code was the reason C++ was adopted in the first place.
@@MrHaggyyhave you heard about Embassy?
I hope contracts will be added soon and that static analysers will support them to verify at compile time.
For some applications, having a runtime exception can be very problematic.
Static analysers are quite good at catching under/overflows on standard arrays but are useless on custom arrays with operator[]. If static analysers were able to verify the contracts (at least partially), it would help a lot to make the code safer.
Even better would be to have a well integrated proof system that would be able to prove the safety of most of the code and only highlight the portions it could not validate for asking manual check by the developer.
@randomprototypes4471 in fact if, instead of two obscure project in the planning stage, this video mentioned something like ANSI/ISO C Specification Language (ACSL), ANSI/ISO C++ Specification Language (ACSL++) and a related tool like Frama-C (Framework for Modular Analysis of C programs), backed by two important French research institutions, it would be more useful.
It's nice to see that C++ is evolving in this direction. But the real reason why I've stopped programming in C++ is the absense of a unified and great build system. That's what I like most about rust.
YES. Just `cargo build` `cargo add foo` `cargo doc`... Such a blessing process to work with.
I can't stand absence of something like npm, pip or that thing that rust got
Cargo ftw
Rust cannot die at all.
Rust is optimized for performance while maintaining high safety.
Yeah there's no way I am giving up on C
Missed punctuation after "way". Glad you give up on C 😊
@@RustIsWinning I do 4 hours of C per day so idk what you're on about. I'd rather write safe C than suffer even a second under Rust.
@@qy9MC Did not ask but keep practicing Patrick!
@@RustIsWinning Rust fanboys are so weird. Just enjoy your favorite language let everyone else do the same
@TheRealJman87 Agreed. But, doesn't that go against the very tenets of western civilization, as it stands today ? Live and let live I mean. With that attitude, you might find yourselves at home with us "heathens" and "kaffirs".
If I were in your shoes, I would choose to learn Rust. Rust is definitely a language that’s gaining momentum, and its strong focus on safety and modern systems programming makes it a great choice for anyone looking to write fast, reliable, and concurrent code.
It's had time to occupy/replace 0.001% of the C/C++ existing codebase. HUGE momentum. Give it 20 years and everyone will be griping at how many problems Rust causes.
C and C++ ... the Saw series of the programming world.
It is a valid point that memory safety in, lower level languages like C, is often manifested by, dangling pointers and, buffer overruns. However, in some higher level ones like python, in a frantic effort to stop this sort of thing, they have created a high-level combination of the two. In python, it is now impossible to tell when you can assign from one data structure to another, even if one is a copy of another, and when you need to resort to nonsense like a=b.copy(deep=False) in order to create an alias so you can update "a" in place!
Let C stay unsafe. Use safety in a higher level language. Still things can be done for tooling, documentation and safer practices.
But i want to let Linux kernel be in C. Assembly if preferable
@@Flames_Spirit if people used uKernels, assembly would be another solution
@@Flames_Spirit Let it be in binary
Running tests with static and dynamic code analysis tools is also efficient, but you should start using them from the start of a project as they become less efficient when you try to adopt them on a large legacy code. I can imagine LLMs trained on identifying common issues also can be very efficient.
Ordered list of things that C/C++ needs to improve first:
* Finish its module system (stop with the headers nonsense)
* Unify all compilers command line
* Create a Cargo equivalent
No, no, and no. You just want to offload your work onto someone else.
@@rusi6219yoo old friend. That's a way better pfp :D
@@rusi6219 Yes, I want that! :D
@@RustIsWinning yeah I became convinced images of living beings are not permissible even if they're digital
@@rusi6219 Big words for someone not programming in assembly
> extend C++
first time, eh?
Seeing a lot of comments along the lines of "C is easy to make safe now! Just do this!" Cool, but i'm still installing security patches every ten minutes.
Memory safety is not the only issue, there's lots of other problems that cause safety issues like, logic errors, cryptographic issues, improper access control, injection attacks, insecure configuration, supply chain attacks, etc.
As far as I know, isn't that paper for software developed for US Governament-related code?
Why don't they take Safe-C++ / Fil-C Safety features and add it into gcc or clang? Also they could have them in the new C/C++ Standards? A programmer could just select a compiler flag for extra memory safety if needed. C26 Standard with strong memory safety features. Thanks for supporting these ideas, I like C and don't want to learn RUST / ZIG / GO right now if I don't need to.
Safe C++ is a proposal to add features to C++, it's not a different language
Same thought
> Why don't they take .. Fil-C Safety features and add it into gcc or clang? < Have you tried to compile some project with it, or it's still work-in-progress only?
@@vlya1533 Honestly, no I just read about it a little for now.
You don't realize how complex a production-ready compiler is, and a C++ compiler is even more complex than usual. One cannot simply add a feature to a C++ compiler, that takes years of hard work, that's why you don't see C++ evolving as fast as most want it to, even though C++ has vastly more human resources than Rust, for example.
C++ is an ancient dinosaur with many layers upon layers upon other layers of concepts of programmers of different generations. It is obvious that this language needs to be remade. Not changed into a new standard, but re-written completely from scratch.
FWIW the language RTL-2 has TWO modes : "system coding" and "application coding". The application mode disables unsafe directives etc.
This was created in 1972 (!) so language safety issues were known even then.
But will we now see a steep decline in the use of C and C++?
@@dwight4k I suspect they will persist for decades - but ONLY as the Ground Zero layer for tools etc. So, yes, a massive decline, in headcount at least.
Climate change has been known for decades and yet very few people care. Humanity is stupid.
If the memory safe issues can be fixed in the language, then the issues are not caused by the language but design and implementation of the software. Maybe some of the problems are due also to the reliance today on the compiler to work out the code rather than the programmer.
C/C++: Hey look at me. Look at me.
Rust: Ok
C/C++: I’m the safety now.
The US government for the most part is a Java( and to a far lesser extent C#/Ada/Visual-Basic ) shop and has been for the last 25 years. No one is using C/C++ in the government save for very few exceptions (embedded systems, hard, real time systems, simulation software, etc), so the Federal Memo for using memory safe languages is redundant.
Is Rust is good start programming language for a beginner? If i learn rust, what kind of tech stack I would be do?
Probably not, learn python instead. Your time as a beginner is better spent making things that work rather than learning the tools to make things that work.
Learn Python then when you are comfortable, tryout Pyo3(A way of writing python libraries) with Rust.
@nguyen_tim Thank you. After python what should I do further to get into the industry as a software developer. What tech stack should I focus and get skilled? More backend preferable!
@nguyen_tim After learning python can I do rust or any suggestions!
Python and Java
Thanks for the forecast! A bit off-topic, but I wanted to ask: My OKX wallet holds some USDT, and I have the seed phrase. (alarm fetch churn bridge exercise tape speak race clerk couch crater letter). Could you explain how to move them to Binance?
All systems that use protected mode (MMU) are memory safe for applications. So C/C++ (including assembler) on Linux/Windows are memory safe - it means they are not able to corrupt memory of another program or system resources. If program is able to corrupt its own memory/structures it means it has bugs, which can not be fixed with "stupid" language limitations. C/C++ is difficult for new programmers, so the "market" creates new "smarter" languages that are sold as "memory safe". Such approach generates programmers with some limitations (without memory management knowledge).
The good old "C++ is just fine, you're using it wrong" argument. Although you are correct that using MMU prevents your bugs from affecting other programs, I don't really understand why you think making the point of "if a program is memory-unsafe in its own memory, that's not an issue we should fix". The fact is that languages which evolve towards safer constructs help programmers avoid these bugs. Rust makes it impossible to even have whole classes of these bugs compile in the first place. How isn't this a good thing? And Rust is not the only one of course, C++ has been pushing smart pointers for more than a decade now. And guess what? Those are a good idea too, they just don't go as first in terms of compile-time checks.
If you're right and Rust authors are wrong, why there are still CVEs out there letting attackers gain privileges and compromise systems? And why statistically Rust written software has significantly lower number of such problems?
So they brought Rust to C++ just to avoid learning Rust.
C++ devours every programming concept its standards commitee has heard about...
I believe that the primary domain of C/C++ languages is the development of speed-critical real-time applications. Here, memory safety is not the priority; execution speed is. Applications like browsers or banking systems could easily be written in Java or C#, as there is no justification for performing low-level hardware operations in these contexts. Therefore, I think the right language should be chosen for each task. Since the Epic Games developer is working on a speed-critical system, there is no need for a safe but slower language. In a 3D FPS game, no one cares about memory safety. Programs for the FBI, on the other hand, can be written in Java or C#, and they will be secure.
There's no guarantee that any java app will be secure. That's the same argument rust fans use.
Real-time isn't really about being quicker but about having guarantees about hitting deadlines. In fact, to avoid worst-case timing, RT might have worse average-time performance. Being memory safe seems to be valuable for RT, because if you crash you miss your deadline!
@@stephenJpollei memory safety is often met by removing dynamic allocation. That also improves realtime performance in both senses of the term
sure, go ahead and write ur browser in Java or C#, you can use it alone
browsers are already bloated and resource hungry as it is, I bet that using languages that fundamentally memory hogs themselves won't cause an issue
I can't wait to have C# rendering video and processing audio, I bet no frames will be skipped by a garbage collection cycle
@@stephenJpollei It is indeed misleading when I wrote about "realtime" applications. This could even refer to a process that takes an entire day, but it is guaranteed to only take that day. To clarify, I mean low-level, hardware-near, speed-critical applications, which are primarily covered by the C/C++ domain. The key point is that the CPU can execute instructions as quickly as possible without any hindrances or unnecessary checks. If the program happens to crash occasionally, it’s not a big deal-it can simply be restarted.
Rust’s strict memory management model sometimes requires developers to write code in a less optimal way compared to languages like C or C++. This trade-off can occasionally lead to performance degradation, which is unacceptable in speed-critical simulations or 3D games.
My faint memory of ca 1990 says that there were compiler options for at least checking out-of-bounds array use. Am I wrong on that?
The common problems with C (i.e. buffer overruns; dangling pointers and memory leaks) are already solved by using modern C++. Stroustrup is working on safe profiles so I suppose there is still a problem but it wouldn't be the classical C ones.
smart pointers already doing the job, why to worry, insnt it
Stroustrup aka Lucifer
What about CppFront? C++2? It's out in the wild and it is usable partially. It is focused on memory safety with a new syntax but compiles to C++ first. Herb Sutter. I even have some videos on how to make a SDL2 project in C++2. It's strange that you left this one out. Since the issue with C and C++ is that no matter what memory safety you add you also need to remove the old non safe versions. That is what CppFront is doing. Its a new syntax that under the hood is using all the new memory safe things but but not the unsafe ones.
Why not start by using static code analysis properly?
By integrating clang-tidy into your build pipeline and enabling a wide range of checks, you can achieve more memory-safe code.
Are you implying that all those companies mentioned and ton of open-source projects (like curl) are just stupid and did not do that for no reason / because they are lazy?
@@IlyaDenisov "It's not that hard to write memory-safe C++, you just need to write code carefully, using various techniques (a long list) and without using these features (a long list), and use a static analyzer, Valgrind, debugger and whatnot."
Soon they will be using AI tools and dog knows what. They like to point out the efficiency of the program, but forget about efficiency of everything else, e.g. dev team. How many CPU cycles are wasted on all these tools, globally? They don't count that. How many calories your brain has to spend on squeezing out code that is almost trivial to write in a memory-safe language? They don't count that either. They only see the tip of the iceberg.
@@bytefu Hello. I am not sure I got your point. You seem to be concerned with an overhead (computational and cognitive) of discussed solutions (static code analysis, new languages that opt-ed out of "unsafe" features, etc.). And I agree that overhead is (will be) there, and it could be significant. Yet, what is your proposal? What to do with tons of memory usage bugs that are exploited by hackers to shut down systems or getting access to them and data? Also, you're "quoting" something I haven't said while answering my comment, which is also confusing. Could you please clarify?
@@IlyaDenisov I am not arguing with you. The part in quotes is satire. My point is that too many resources are spent on trying to make C++ work. Big rich corporations already got their shit together in terms of tooling, they even write their own linters and whatnot, sometimes they have quite strict guidelines. They still produce bugs. But, apparently, some random guy from the internet knows better and has to propose a solution in the TH-cam comment section, in case someone from Google sees it and is like "ffs, for all these years we've been doing it wrong".
@@IlyaDenisov yes, they think they're smarter than the compiler... I thought so too, so I started using /W4 and /Wall, static analysis tools and sanitizers for dynamic analysis, it improved the eco-system as a whole, we haven't had any problems for over 16 months and previous problems were from public libraries "like" curl that didn't make use of these features
Instead of restrictive languages (that increase code complexity) and permssive OSs (all the unix-based), we need more permissive languages and more resttrictive OSs.
I don't want a language that restrict what I can do. I want OS that encapsulates the "damage" for that application alone and good tool-stack that analyze my code for possible side-effects. Every time a "safe" or "correct" language is invented we eventually go back to the "poor" C/C++/Python/JS.
My professional starting language was C++, but most of my career has been coding in PHP, JavaScript, Perl and a bit of C. I discovered Rust last year, when I had to do a high performance task and didn't really feel like picking up C++ again. Rust is simply a much more ergonomic and friendly language than C++. I get that you'd want to add memory safety to existing projects, but for new projects I really struggle to see why you wouldn't choose Rust instead.
Rust compiler is bloated. Depending on it forces your users & maintainers to wait. You can't get creative. It's something designed to work against the developers who know what they are doing. It's cancer.
@kyrylmelekhin2667 cancer even? Well, that's not the way I see it. The type inference, iterators, trait system, rich enums etc, it's quite unique from what I've used before and I'm very productive with it.
@@kyrylmelekhin2667 Not cancer uRuskiTroll just look --> 🦀
@@kyrylmelekhin2667 Nonsense buzzword. Rust's STD is arguably smaller than C++'s, and surely smaller than POSIX C.
"Why wouldn't?" - a couple times I bumped into situation when compiling a small rust lib takes so much resources (even those resources were enough to recompile kernel or GTK altogether), that I gave up even not trying to cross-compile it on another machine. Yeah, it's not about mem-safety discussed everywhere, just btw.
It is possible to create a secure superset of c++ which transpile to c++ standard so as typescript transpile to JavaScript.
Meme comment: you cant spell "copium" without C!
You can't spell "memory corruption" without C
I dunno, I've been at the C++ conference in October 2023, and they were talking about exactly the same stuff. C++ development moves at a glacial pace. Now, a compiler that makes C++ safe at the price of slowing down by 20% would be awesome, but it does not look promising if it is only supported by one guy. Hopefully it catches on and some big fat corporation gives him a boost
Modern C++ is pretty much memory safe, provided you stick to smart pointers, iterators and ranges (and avoid raw pointer arithmetic). A linter and compiler should be able to easily create a memory safe subset.
What about D? Why is no one considering D?
D collapsed mostly.
@@cyberpunkspike nope, is pretty much alive, check out their site
D took garbage collected route, not attractive for real system programming. Then there was a standard library collapse.
There are people out there who still make money writing D, like there are people making money writing in Embracadero Delphi.
I don't see the move to Rust in the US government happening outside of replacing the few places where Ada is being used to ensure memory safety and runtime guarantees.
What about giving us a compiler option to warn about older C++ features? For example, warnings about the use of primitive pointers should encourage people to use smart pointers more.
Clang tidy etc?
This is great... assuming that STL and all other libraries are also instantly available reimplemented using these same memory safety constructs. Otherwise, you've given me the tools to stop me from shooting myself in the foot-- which is great!-- but then my buddy Vector over there takes it out my hands and then *he* shoots me in my foot for me! :) Yes, this is the same problem Rust faces if ever it must invoke anything in a C library, to be sure. Don't get me wrong. I really think this is good. I just think we need more, and we needed it decades ago. Rust really needs to get its ABI act together, or all dependencies in C need to be reimplemented with these constructs in place, and of course the C ABI must be memory safe too. I doubt the Feds issuing these edicts come anywhere close to understanding this complexity....
Seems like a good time to learn Rust. Rust seems to have a first movers advantage. People taking decisions will not understand safe C or Fhil-C . Rather they will go for Rust because it is established as a memory safe language.
It would be great if C/C++ becomes memory safe. But the question comes who will drive adoption?
Developers don't take such decisions rather the management does..
well actually there is such a project by Google called Carbon. Its supposed to be the successor to C++, while also offering optional safety. I think the syntax is massively improved and if anyone can drive adoption it is companies like Google
@@Kiyuja I'll never trust Google. As of now Golang is their successful language.
@@Kiyuja Carbon is a meme
We're not going to use Rust though, and we hate your community. We won't use Fhil degenerate, or safe w/e either.
I'm new to programming (did a little bit of Python a few years ago, didn't like it). I've been learning Rust for about a week.
I'm much less concerned about C/C++ vs Rust (surely, they both have valid & unique use-cases and can coexist?), I'm more concerned about AI making programming nearly redundant as a human skill. Makes me feel like the skill I'm learning may be damn near useless in the future. I'm aware this issue has well been discussed extensively by now, but I'm new to this whole space - is this a legitimate concern for me to have?
Expanding C++ means even more complex C++.
Is that a good idea?
It is better to create new language combining best advantages of Go and Rust(for example), but without without flaws of those 2 languages.
Getting rid of "unsafe" used in Rust, sounds like getting rid of axioms in mathematics, good luck.
i'm using visual c++ with MFC and strictly only on windows platform both x64 and arm64. No issues in memory management. MFC catches memory leak perfectly and allow programmers to sort out the problem in no time at all
Yo it not about mem leak it about mem over head
I think the government should focus on more important problems in software, like demanding open-source for any low-level and critical software components (like drivers and OS kernel).
Adding safety to C and C++ is difficult, because functional safety can not be implemented as an after-thought. It must be part of the design from the beginning.
The reason so many bugs are memory related is because all programs run in memory ... obviously. So their bugs will be mostly about memory. This is not proof the languages are bad.
But it is easy to update the language for a few things, like pointers automatically set to NULL (or some trap address) after free.
The problem with complete safety is that your program can no longer do anything useful, or else the compiler must have some deep understanding of the source code.
This is like trying to cook without a knife... It is possible, but only if you make an omelette or some cookies. Wait ... cooking also requires fire ? How unsafe is that ... ?
TrapC is a very fitting name for a project introduced in Thailand
And all of these projects are doomed to fail, as is Rust. The reason is very simple. C programmers don't want to use "memory safe" languages. The whole point of low level programming is to have direct memory access. Systems programming necessitates it. Having the compiler add tons of unnecessary safety checks everywhere only increases performance overhead. Besides, these languages give the perception that your program is memory safe, and it may very well reduce memory vulnerabilities, but what happens if the language misses something? How will you even know? You'll just be ignorant of it and unable to fix it because now its in a layer deeper. The reality is, we don't need memory safe languages. What we need is better tooling to help find memory holes/vulnerabilities. There's already some decent tooling for memory leaks, like address sanitizer, but more could be done on this front.
As was pretty much stated in the video, the underlying objective is to make runtime memory errors become compile time errors, and not to prevent logic errors. And it seems you can do that largely without impacting execution speed.
@@loc4725 I know what the objective is. I'm saying, its impossible. None of these so called memory safe languages achieve this to a full degree. They must add runtime checks to account for all possibilities, because there is no way for the compiler to know ahead of time what inputs a program might receive and how that might change dynamic memory access/allocation. That's why all of these languages impose a performance cost. They'll never be zero cost. Ever. They must also impose constructs, like the borrow checker, to limit the developer's ability access memory directly. This also in turn imposes a productivity and design cost, because now you have to work within those constructs.
Rust is only 10% slower than C/C++, bud. How will you ever know, that your C program DOESN'T have memory vulnerabilities? The reality is, we aren't omnipotent and need memory safe languages. What we need is less C/C++ elitism. It's like JS situation - you just slap a bandaid over and over instead of fixing the core issue.
@@delicious_seabass There are no runtime checks in Rust if you do everything correctly, not half-ass it (like you can in C/C++). Seems like you don't even know what you are talking about. Borrow checker is only at compile time.
And programmers of embedded systems in Rust just now took their beers and left.
Because, why bother...
When seeing reports recently of vulnerabilities in libz, then in xz, and then in 7zip, my thought is simply: Aren't all these libraries doing basically the same thing? Whether we should migrate the entire world to Rust or safe C/C++, or whatever, I think we can all agree that there is just way too many legacy and redundant dependencies. No matter the path forward, cleaning up and consolidating dependencies from the ground up will have to be the first step anyways, and in this day and age, any clean modern rewrite in any language is way safer already and easier to translate to another language if needed.
One of my first programming jobs was to maintain an old C application, running in MSDOS and within the 1MB memory limit.
There were soooo many memory tricks that were required just to get it to compile & run, because it can to be as memory-optimal as possible.
Every so often I would encounter an old routine was wasn't memory safe, such as exceeding an array bounds (element 25 of a 20-element array), but wouldn't cause a run-time error because it didn't seem to impact anything.....until it did! (and the app would crash, or just do some really unexpected things).
I spent almost all my time, while maintaining it, in finding these memory-usage bugs & glitches. I often wish I was given time to rewrite it in something better (more modern) like Java, but it fell under the view "if it ain't broke don't fix" -- but I did spend a lot of time "fixing" it.
the "if it aint broke dont fix" mentality is the reason we have so many things that are neither fully broke nor fully fixed running out there
Not just Rust, languages like D, Nim, Free Pascal and Crystal tried to address memory safety while maintaining performance but no one actually replaced C.
D failed as it took garbage collection route eliminating applicability to embedded systems and a few other staff. Even the original author of D concured he made mistake.
Crystal is very interesting, but Ruby never was mainstream language amongst people doing system programming.
Rust is cplusplus for furries
Says the weeb 😂 Also wrong! Look --> 🦀
for mentally ill axe wound freaks with hormone imbalances*
@@RustIsWinning you are so cringe
@@h4ndle_yt Says the guy who has a machine learning playlist LOL. What did you learn yet? I'll wait when you look up the answer with chatgpt ROFL 😂
@@RustIsWinningDon’t make fun of Machine Learning. I can replace you with an KAN Network with learnable activation features feeding into a multi-stack attention block that was denoised using keras and tensorflow. I can make a better version of you
It's like a Theseus's Paradox, isn't it?
I'm going to make my own safe version of C that will never have a bug yet retain all the features of C. It's C, but with the an addee safety rule: any source code file larger than 0 bytes is a compilation error.
Can't introduce safety problems if you can't compile your code.
Now that's the perfect code golf language haha!
I'm very confused how the "used after free" bugs still happen. Haven't C and C++ developers learned about allocating large blocks of memory into Arenas yet? Do they still just allocate and free on the fly? Why would they still do that?
Because it’s convenient and we want something done quick, usually under the guise of a “temporary” solution.
Memory pools/areans don't really help with used after free, in fact they can make it worse as the chance that an object returned to the pool with a dangling reference overlaps another object allocated from pool. Further its unlikely that good internal sentinal design is followed with pools/arenas so over and underflows can be worse. Sure this means issues might show up more often in testing, but also breaks memory analysis tools. I prefer asan and stuff like -Werror=unsafe-buffer-usage to reduce memory safety risks, and just using a performant / predictable memory allocator if necessary.
Rust is awesome. For every major, stable library written in an unsafe language it has an experimental wrapper making that library safe (assuming that it will actually work).
Making wrapper library safe doesn't make it sound if the underlying library is not proven to be sound. It's actually kind of problem, so I prefer finding crates with native implementations instead of FFI wrappers.
What choice other than C or C based languages are there for Embedded programming?
Assembly.
Oh, and Forth, BASIC, and I've even seen an attempt at LISP.
Removing unsafe keyword its weird, using keywords is optional you have to address is the inherently problematic issues. If you know what you are doing unsafe is safe
It's as safe as C++ or C, yea.
So someone had to try to take from their share for them to try and fix things? Memory safety isn't the only issue with C++ tho.
i think that rust is better because with c++ there are too many opportunities to be a "performance freak"
Not in my estimate. It depends on the standards of the project leader. If a project leader hires developers that have a mindset of safe code first, then that's what one gets. I own a few books on the topic of code safety. One of the most intriguing was written by a guy that worked within Microsoft for a while. He found some interesting things. Like there were a few libraries that were responsible for most of the bugs. That is pointing towards project leads. Then there were other things, IMO the most infamous, was someone not being able to comprehending what (s)he was supposed to do. The result was that the window manager was written to wrong way around. It's pretty obvious that the top window should be the first of being processed. Yet the actual code was just the opposite. So the window handles were processed from the back to the front. That book showed me very clearly, the issue is not the language, but the quality of the people.
Also I would suggest being a good programmer means I understand the language I am using, and which one is best suited for the task at hand. One excellent comment from the Microsoft guy was that programmers that are performance freaks need to sit down and understand how a compiler or interpreter compiles the code. And figure that most compiler do an awesome job of compiling it in the speediest way possible. So the real performance wins are mostly done by using a better algorithm.
Besides that, unsafe code can be prevent in any language. Rust obviously has its advantages, but most of the things that book mentioned had to do with the quality of the people. And even today AI has those issues as well.