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.
@@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.
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.
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.
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!
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 ¬_¬
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.
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 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.
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.
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!
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.
@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".
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.
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
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,
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...
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?
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.
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.
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.
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.
All solutions for memory safety that you looked at are software-based. There are some interesting architecture and hardware-based solutions worth mentioning. ARM have their Memory Tagging Extension (MTE) which restricts which regions of memory pointers can access. There are also other architecture-based memory safety options, like the CHERI project (a fork of the RISC-V instruction set) from the University of Cambridge which stops memory issues at access-time. If the pointer was trying to do something it wasn't supposed to (buffer overflow for example) an exception is thrown that can be handled accordingly.
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
I guess this is why NASA has such strict rules for programming such as no recursion or heaps, finite loops, limited variable scope, single pointer de-referencing only, no function pointers etc.
Just not using heaps (mostly) and passing refs solves 99.9% of all problems. Arrogance of pursuing 'Language-side assured' makes most of side effects...
Its a shame that C++ is going with the disastet that is profiles instead of somethung that might actually work like cribbing features from Circle. The C ABI will never die, but with corporate interests backing memory safe languages C++ might become the next COBOL. Which is fine by me, COBOL programmers make 💵💵💵 so as a C++ developer I am OK with that.
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.
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?
There's still something I don't understand. Even if you wrote perfect C/C++ code, kept track of all the pointers, thread shit and stuff and you make sure you didn't fuck up, the program can still be unsafe?
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. 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.
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.
Getting rid of the problem doesn't make it "solved". Buffer overruns, dangling pointers, leaks are all due to bad development practices. Many essential practices don't appear to be properly taught to new people/students entering the field. Now pick up any book or video on software development and many essential practices are still not properly discussed.
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?
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.
That's what Java is providing since 1995! C is powerful and any memory safe subset of C must be 100% compatible with C and match the performance, otherwise it doesn't make sense to switch. Rust is a great language but without large community and libraries won't be able to do what C/CPP does.
I wouldn't exactly call "union" a "rarely used" keyword. Not to mention, unions can be useful, and when you need them, you need them. There are usually alternatives to using unions, like using a "void *" instead, but that's not exactly being more 'safe'. I can only hope there was some practical thought given first, and that it has other alternatives in the language. Perhaps I will take a look myself at some point and see. Though at the moment, I'm perfectly content with the 'unsafe' nature of C as is, and just taking responsibility for my own code. Although, constructors/destructors might be nice.
By the way, there are animated controversies going on in the Linux kernel about Rust. One should remember how Java was designed in the first place, to make it easier to learn. Teachers listed the hardest topics for their students and noted most of them stumbled upon pointers and memory management, so they removed pointers from the languages and used a Garbage Collector. But this comes at a cost, how software is written and runtime impacts too. While there are countless pieces of software that can be written without understanding pointers, IMHO, who would want a programmer who cannot wield pointers effectively to work on the Linux kernel? Seriously..
Methinks we have heard drivel like this before. 'C' is a language which has a close correlation with a particular type of computer architecture. It is flexible enough to build software structures to utilize more complex architectures. At the machine code level, all current languages are not memory safe. But then again the language level is at least two levels removed from the machine. There have been attempts to implement 'Ada' machines and 'Lisp' machines as hardware but results have not survived long. Languages are descriptive. They are never the implementation. All suffer from 'many a slip, twixt cup and lip'.
I wonder what their definition of memory safe is? You can create a memory leak in python by creating objects and adding them to a list and forgetting you did that. In some ways there are no safe languages.
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.
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 ... ?
yeah, that union thing is on the level that gets me block channels. Also, unions at least guarantee proper overlap and allocation, whereas casts just tell the compiler to shut up... wtf, anyway.
Since the appearance of Rust, I doubt a new programming language is needed to mitigate memory safety issues. Rust compiles memory safe codes but also not to provide many memory manipulation behaviors, since this is necessary in system programming. To make memory safe binaries, why not work on compiler?
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.
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?
The FIl-C approach isn't new. I've been using the SINIX compiler about 30 years ago and it didn't care about null-pointer dereferencing. It also didn't care if you type & instead of * or vice versa. It was amazing what bad and wrong code it was able to turn into a working program. But the result was also very slow. Regarding TrapC: I use unions, they are quite useful, especially for modeling messages that are sent over a network. And I find C looks a lot more beautiful than Rust.
After learning how fast is c++, its weird to hear this language has memory problems. But Im not going to use any other compilers than gcc. Performance doesnt matter, also im on linux so downloading another compiler would be dumb either.
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?
@@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 think C can be made memory safe creating a software that goes over the source code just like a super great 10x programmer does, leaving no room for issues as mentioned in the video, since things are deterministic in nature this can be done. Also IDE's can show hints where it suspect bugs could arise from, also visually show how data are moved in memory just like you could do a debug step trough in code. We also are seeing lots of LLMs kind of tools, so I am sure there are people researching this approach. Lots options to explore. Rust I think is the easy cop out solution, which is like making a deal with the devil, your wish comes with a hidden cost which ultimately defeat its original purpose. Imagine if all of PC was run on Rust built software, how are you going to explain to a gamer why his games are running slower, uses more energy etc. If memory safety is of that important for gov and big IT then why are they hiring programmers that has skill issues with C or C++ ? I don't want to see this an equivalent to 'Idiocracy' leak into programming. Rusted minds, no thanks.
Running faster actually and as if energy was a problem LOL. You going to measure the energy consumption of every program? Cluless deluxe but at least you tried!
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.
Surely there are libraries for C that obviate 90% of the memory problems that exist? Note that COBOL is still around today because of how much time and money it would take for banks and the like to recode all that software in something else. C will survive, partially because it costs to much to change.
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!
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....
So why didn't the developers of Rust just bring memory safety to C++? I think it's stupid that people go on creating new computer languages for problems that can be solved by fixing an existing language.
I hate Rust not because it is bad, i hate it because of the false promise of making bad programmers be good. Memory is a problem because it does exist, ignoring its existence by using something that "guarantees" to handle it correctly for you is a BET, a bet you may loose. With C, if you write it good, it stays good forever.
Why can't we just agree that YES, C may not be perfect and that's why experts are needed to write the code. We are experts and others can become experts too if they put in the hours needed. But we like it that way. Not everything needs to be a "push-button" solution. Script kiddies who need training wheels on their bikes can use Rust and Kotlin and other redundant languages.
these two sentences: 1. "rust, aside from a memory safety, doesn't offer a major advantage", are you sure? I guess this is also related to the second one: "they don't want to learn new language" -- I was thinking, let's maybe try to use the progress we've achieved in last 60 years in CS and stop using redundant languages? they are old, outdated and weak. They are simple, yes, but it doesn't mean it is easy to write software with them -- in fact, I see the opposite dynamic. Haskell is 35 years old, not talking about other ML languages, lisps are even older. It doesn't make sense that abstraction building power they providing makes them far more superior tools for writing complex software -- which is almost any software in a modern world.
There is an entire class of programs, that will be severely harmed by such a rule, like video games. Sure, make e.g. the payments super safe. Maybe this is yet another reason to force users to get new hardware?
Isn't everything software related, memory related? Software lives in memory and stores things--you guessed it--in memory. The cache on the CPU is also: memory.
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 not hard to make memory safe C or C++, if you are willing to compromise a little bit on performance. Just make your own memory model, and tightly control access to and use of Malloy and free- only use it from within the memory model. Write string libraries that are bound to this model. Keep indexes rather than pointers, and resolve the indexes only within specific code that performs bounds checking. Set a firm policy of never incrementing or adding to pointer addresses, outside of the very tightly controlled code.
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).
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.
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
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 That's not going to work. C is a partial subset of C++. You can't just "take the code from the template". Do you even know C?
@@santitabnavascues8673 I don't think you understand the difference between C and C++, or what templates are
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.
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.
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.
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!
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 ¬_¬
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
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"?
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.
"It removes some rarely used keywords like 'union'". Ok, you've lost me man.
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
“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.
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...
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.
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!
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.
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".
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
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
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.
pretty sure it started out as a kind of joke.
@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 .
Remove unions? Whyy
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.
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.
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?
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.
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.
Let C stay unsafe. Use safety in a higher level language. Still things can be done for tooling, documentation and safer practices.
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.
All solutions for memory safety that you looked at are software-based. There are some interesting architecture and hardware-based solutions worth mentioning. ARM have their Memory Tagging Extension (MTE) which restricts which regions of memory pointers can access. There are also other architecture-based memory safety options, like the CHERI project (a fork of the RISC-V instruction set) from the University of Cambridge which stops memory issues at access-time. If the pointer was trying to do something it wasn't supposed to (buffer overflow for example) an exception is thrown that can be handled accordingly.
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
I guess this is why NASA has such strict rules for programming such as no recursion or heaps, finite loops, limited variable scope, single pointer de-referencing only, no function pointers etc.
Just not using heaps (mostly) and passing refs solves 99.9% of all problems.
Arrogance of pursuing 'Language-side assured' makes most of side effects...
8:35 remove union
How unsvilized
Its a shame that C++ is going with the disastet that is profiles instead of somethung that might actually work like cribbing features from Circle. The C ABI will never die, but with corporate interests backing memory safe languages C++ might become the next COBOL. Which is fine by me, COBOL programmers make 💵💵💵 so as a C++ developer I am OK with that.
No one is talking about Ada. It solved most of these issues back in the 80s and 90s. It's still being used and is a very powerful language.
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.
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?
As far as I know, isn't that paper for software developed for US Governament-related code?
There's still something I don't understand. Even if you wrote perfect C/C++ code, kept track of all the pointers, thread shit and stuff and you make sure you didn't fuck up, the program can still be unsafe?
I don't see the Filip Pizlo presentation in the notes, and I can't find it on UA-cam.
Can somebody please share it?
ua-cam.com/users/live_VF3pISRYRc?t=4862s
ua-cam.com/users/live_VF3pISRYRc?t=4862s
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. 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.
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
Getting rid of the problem doesn't make it "solved".
Buffer overruns, dangling pointers, leaks are all due to bad development practices. Many essential practices don't appear to be properly taught to new people/students entering the field. Now pick up any book or video on software development and many essential practices are still not properly discussed.
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.
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.
Long live #RustLang 🦀
That's what Java is providing since 1995! C is powerful and any memory safe subset of C must be 100% compatible with C and match the performance, otherwise it doesn't make sense to switch. Rust is a great language but without large community and libraries won't be able to do what C/CPP does.
I wouldn't exactly call "union" a "rarely used" keyword. Not to mention, unions can be useful, and when you need them, you need them. There are usually alternatives to using unions, like using a "void *" instead, but that's not exactly being more 'safe'. I can only hope there was some practical thought given first, and that it has other alternatives in the language. Perhaps I will take a look myself at some point and see. Though at the moment, I'm perfectly content with the 'unsafe' nature of C as is, and just taking responsibility for my own code. Although, constructors/destructors might be nice.
3:00 I kind of find it pathetic to not want to learn new stuff.
Unions are in every codebase I have worked on...
What about embedded? What about situations where the chip developers havent released support for other languages?
By the way, there are animated controversies going on in the Linux kernel about Rust.
One should remember how Java was designed in the first place, to make it easier to learn.
Teachers listed the hardest topics for their students and noted most of them stumbled upon pointers and memory management, so they removed pointers from the languages and used a Garbage Collector.
But this comes at a cost, how software is written and runtime impacts too.
While there are countless pieces of software that can be written without understanding pointers, IMHO, who would want a programmer who cannot wield pointers effectively to work on the Linux kernel?
Seriously..
Methinks we have heard drivel like this before. 'C' is a language which has a close correlation with a particular type of computer architecture. It is flexible enough to build software structures to utilize more complex architectures. At the machine code level, all current languages are not memory safe. But then again the language level is at least two levels removed from the machine. There have been attempts to implement 'Ada' machines and 'Lisp' machines as hardware but results have not survived long. Languages are descriptive. They are never the implementation. All suffer from 'many a slip, twixt cup and lip'.
I wonder what their definition of memory safe is? You can create a memory leak in python by creating objects and adding them to a list and forgetting you did that. In some ways there are no safe languages.
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.
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 ... ?
Removing "union", claiming that they're rarely used is wild.
Go on, remove union, your IP address will now be stored as char[16]
yeah, that union thing is on the level that gets me block channels. Also, unions at least guarantee proper overlap and allocation, whereas casts just tell the compiler to shut up... wtf, anyway.
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?
Since the appearance of Rust, I doubt a new programming language is needed to mitigate memory safety issues. Rust compiles memory safe codes but also not to provide many memory manipulation behaviors, since this is necessary in system programming.
To make memory safe binaries, why not work on compiler?
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.
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
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?
The FIl-C approach isn't new. I've been using the SINIX compiler about 30 years ago and it didn't care about null-pointer dereferencing. It also didn't care if you type & instead of * or vice versa. It was amazing what bad and wrong code it was able to turn into a working program. But the result was also very slow.
Regarding TrapC: I use unions, they are quite useful, especially for modeling messages that are sent over a network.
And I find C looks a lot more beautiful than Rust.
A good start is betterC which has been around for a while now
and c3, but betterC is a great start.
After learning how fast is c++, its weird to hear this language has memory problems. But Im not going to use any other compilers than gcc. Performance doesnt matter, also im on linux so downloading another compiler would be dumb either.
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?
C and C++ ... the Saw series of the programming world.
To do what I need, I have to write unsafe rust.
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
I think C can be made memory safe creating a software that goes over the source code just like a super great 10x programmer does, leaving no room for issues as mentioned in the video, since things are deterministic in nature this can be done. Also IDE's can show hints where it suspect bugs could arise from, also visually show how data are moved in memory just like you could do a debug step trough in code. We also are seeing lots of LLMs kind of tools, so I am sure there are people researching this approach. Lots options to explore. Rust I think is the easy cop out solution, which is like making a deal with the devil, your wish comes with a hidden cost which ultimately defeat its original purpose. Imagine if all of PC was run on Rust built software, how are you going to explain to a gamer why his games are running slower, uses more energy etc.
If memory safety is of that important for gov and big IT then why are they hiring programmers that has skill issues with C or C++ ?
I don't want to see this an equivalent to 'Idiocracy' leak into programming. Rusted minds, no thanks.
You're describing a linter and there's hundreds of thousands of them lying around the web
Running faster actually and as if energy was a problem LOL. You going to measure the energy consumption of every program? Cluless deluxe but at least you tried!
@@RustIsWinning Higher energy usage generates more heat which may lead to thermal throttling, and subsequently, worse performance.
C/C++: Hey look at me. Look at me.
Rust: Ok
C/C++: I’m the safety now.
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
Surely there are libraries for C that obviate 90% of the memory problems that exist? Note that COBOL is still around today because of how much time and money it would take for banks and the like to recode all that software in something else. C will survive, partially because it costs to much to change.
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
removing 'union'! That's like the coolest thing ever in OG C.
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....
Why not integrating a tool like NASA's ikos in your CI? You can continue writing plain C and have this tool analysing your code before releasing it.
There is no substitute for good workmanship.
So why didn't the developers of Rust just bring memory safety to C++? I think it's stupid that people go on creating new computer languages for problems that can be solved by fixing an existing language.
I hate Rust not because it is bad, i hate it because of the false promise of making bad programmers be good.
Memory is a problem because it does exist, ignoring its existence by using something that "guarantees" to handle it correctly for you is a BET, a bet you may loose.
With C, if you write it good, it stays good forever.
What choice other than C or C based languages are there for Embedded programming?
Why can't we just agree that YES, C may not be perfect and that's why experts are needed to write the code. We are experts and others can become experts too if they put in the hours needed. But we like it that way. Not everything needs to be a "push-button" solution. Script kiddies who need training wheels on their bikes can use Rust and Kotlin and other redundant languages.
these two sentences: 1. "rust, aside from a memory safety, doesn't offer a major advantage", are you sure? I guess this is also related to the second one: "they don't want to learn new language" -- I was thinking, let's maybe try to use the progress we've achieved in last 60 years in CS and stop using redundant languages? they are old, outdated and weak. They are simple, yes, but it doesn't mean it is easy to write software with them -- in fact, I see the opposite dynamic. Haskell is 35 years old, not talking about other ML languages, lisps are even older. It doesn't make sense that abstraction building power they providing makes them far more superior tools for writing complex software -- which is almost any software in a modern world.
I hope it will someday work on microcontrollers
Getting rid of "unsafe" used in Rust, sounds like getting rid of axioms in mathematics, good luck.
Did that FilC screenshot say "garbage collector"? because Go already exists
This is more interesting than Tyson vs. Paul fight.
There is an entire class of programs, that will be severely harmed by such a rule, like video games. Sure, make e.g. the payments super safe. Maybe this is yet another reason to force users to get new hardware?
We need a memory safe C and C++! Yes, do not forget C! There is a reason C was popular for so long and still is. C is concise!
Isn't everything software related, memory related? Software lives in memory and stores things--you guessed it--in memory. The cache on the CPU is also: memory.
Yeah, how did Ada work out? And we've been able to get rid of COBOL, why can't we get rid of C/C++? /s
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.
It’s not hard to make memory safe C or C++, if you are willing to compromise a little bit on performance. Just make your own memory model, and tightly control access to and use of Malloy and free- only use it from within the memory model. Write string libraries that are bound to this model. Keep indexes rather than pointers, and resolve the indexes only within specific code that performs bounds checking. Set a firm policy of never incrementing or adding to pointer addresses, outside of the very tightly controlled code.
5 seconds in I hear C...++
me: aight, imma head out
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).
I hate memory safety, give me all the weapons, unlocked!