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.
@@VoyivodaFTW1 Most of the current programmers don't know what unions do (even when I learned C I didn't get it at all bc unions are only useful in embedded with limited memory resources)
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?
this: "efficiency in execution speed, memory used, and the size of binaries" ...is all post-hoc rationalization, as you can realize if you consider when c was created and why.
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)
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
This happens every 10 years or so. IT consultancy firms and independent consultants need a new mission to find work and make money (and secondary industries such as publications). And tech firms always need scapegoats so they don't have to take responsibility for anything. And it will be all for nought. In the 80s we had structured programming, analysis and design, 90s we had OOP, 2000s agile/scrum, 2010s functional programming, now memory safety.
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.
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".
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.
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.
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.
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++.
I'm torn between Zig, Odin, and Jai (if I ever get my hands on it). I have an extensive set of libraries I've written in C, and Zig looks like it will be able to use them with no hassel.
@@RockTo11 I have seen Jai, and it does look interesting, though without trying it, there isn't much that I am too excited about. I definitly plan on learning it when it does get released. Between Zig and Odin, they are both good. I personally prefer Zig for most applications, but Odin is enjoyable to use, there is just a few design patterns that keep it from being "great" to me. I always recommend it to Go devs who are interested in game-development, it is fills the niche perfectly. All that said, don't be torn between any of them, learn them all. I understand you have to somewhat commit to one or another for a certain amount of time to become competent with it, but as someone who used to also feel like I had to choose, I can say that it a self-imposed restriction.
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.
@@CommanderRiker0 I'm working in C++14 codebase due to requirement to work under some 2008 gov OS. We have NO Asan/Bsan and other stuff for safety at all. We can't use Rust either lol. BTW i worked at Yandex before and they targeted 24 LTS Ubuntu with C++23 and Asan/Bsan and other sanitizers which simply solved all memory issues which could possibly happen. Also there is a lot more C++ programmers than Rust programmers, and you really can have team of 200 developers without draining full country of them
“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 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.
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.
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.
This is one area where I will gladly tell the government to get coited. I'm not going to listen to a single word of advice from an organization who's average member is almost as old as the transistor itself. They can't get a single solitary thing done when it comes to law, what gall do they have to think they can suggest anything when it comes to technology?
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 recently read a treatise on pointers in C++ stating that we actually still don't know fully what a pointer is according to the standard, and there is open research to properly define it. Nice to see Fil-C defining a model for pointers that does incorporate some of these findings (like internal bounds).
Місяць тому+4
Not really sure why you need to defend C++. C++ is honestly doing just fine in the real world, that world outside of the constantly context switching, profiting on hype, youtubers.
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.
There is a lot of dudes that heard that C/C++ is unsafe, and throw words like "UNSAFFFEE" while most of the security breaches happen due to lack of user input validation in Log4j for example lol
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
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".
Of course migrating to Rust is a safety option. Look at how companies are doing that in practice: E.g. Google's Android team writes all new low-level code in Rust and migrates only the most safety-critical components. Old battle-tested code can stay in C, because the bugs have already been shaken out. Minimal effort, maximal security benefits.
@DJenriqez have you actually looked into what happened? Some Linux maintainers apparently oppose even documenting lifetime requirements in their code, let alone fixing them to be consistent.
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.
@@isadora-6th Rust and Tokio aren’t slow, Go’s runtime handles concurrency for you, making it easy and fast for simple use cases, but that comes with overhead. Tokio gives you control and performance determinism, which requires effort but scales better for complex tasks. Also, Rust’s debug builds are slow-benchmark in release mode before making claims. If Go works for you, great, but don’t confuse simplicity with raw performance.
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.
Same , I'm on my 3rd c++ job and my life is addressing code review comments from snarky co workers about the most ridiculous foot guns. The language is an arbitrary mess and i yearn to be free from it.
C and C++ programmer here. I wouldn't consider them *great* languages. C is good for its express purpose. C++ is ... adequate, but actually a technical mess, that was not really understood at the time it was originally designed. Rust is as of yet, more like a fanboy hype. It promises a great deal of sound technology, except the messy ownership rules of allocated memory. It will be fine in the future, but lacking an ABI for dynamical binding is *_not_* mature. For the rest I wish a sound memory allocation model for C and C++, but that won't make them great. That would make them a little bit more sufferable.
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.
First they came for the unions, and they did not speak out. Then they came for the pointers, and again they did not speak out. Finally they came for the heap, and by then it was too late.
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.
@@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.
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.
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.
The only solution I could think of was the path the Fil-C followed. But I didn't have the knowledge and time to sit down and write a modern compiler. I was glad to hear someone wrote one. I hope they will also think of extending Fil-C with generics. Because I don't want to be stuck with C++. I would like to give a message to the Rust community as well. Make some additions that will not make Rust dependent on C and including C libraries into the projects (maybe enhancing the ecosystem with Fil-C compiler). Because their intention is to kill Rust by adding Rust's solutions to C/C++. So include Rust into the same ecosystem and lead them. 😄(After a talk given by Stroustroup I wrote, "He plans to turn C++ into Rust") Yes, Rust's secret was to make the compiler safe, the rules we learn as the rules of the Rust language are actually the rules of the Rust compiler. Every language is as reliable as the freedom given by the compiler, if you don't allow obvious errors to be compiled, that language becomes reliable. So creating Fil-C to save C is the right decision.
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
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.
C++ is like one of those cities with major traffic congestion that evolved with time and they had to make a lot of patches to adapt it to the new environment, while Rust is one of those cities designed from the ground up that just works efficiently.
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.
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.
@@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 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.
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 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.
> runtime exception Dude, it's performance feature not a problem lol. And if happens, there usually no point in keeping "performance". > Static analysers are quite good at catching under/overflows on standard arrays You are using C97 in context of C++20 (23 years apart), There is NO ONE who uses them seriously lol
@isadora-6th in context like self driving, you cannot suddenly stop because you got a runtime exception. Quick restart is not a perfect solution either because the next frame could cause the same problem if similar. Even if the code doesn't cause any exception during 100000h of test sequence and pass all the unit tests, you have no guarantee that it will not happen unless you can prove that it cannot happen. Manual review is not infallible and current formal proof systems are nearly unusable on real code unless you want to prove a very small portion. Compile-time checked contracts could be a first step into proof system usable on real code. Commercial static analysers work really well on std containers and are used in most safety critical softwares as one of the safety checks (among many others).
@@randomprototypes4471 You say: Exception happens. I say, exception happens due to a reason, and usually, exception reasons change workflow significantly enough to skip a frame. Like, "file not found", "Can't write to IO", "malloc alloc failed (no mem provided)", user exceptions in some cases where you can't continue. There is no point in performance ANYWAY. There usually no point in continuing work like algorithm that calculates something founds error in inputs at late stage. If you use exceptions as return channel, it's quite punchy. Not WORLD STOP like java, but a hit. And most of exception overhead happens due to (?)))) malloc for x bytes to place exception on heap, which could take time for system call in rare cases, but thats unlucky :D. I say, exception overhead happens due to malloc inside, not because exceptions is bad. If your system uses system malloc, and you see there no problem there, not using exceptions is at least strange and usually happens due to lack of understanding Also WG21 got a lot of funny proposals during 2021-2022 season where "value exceptions" where presented as solution for "overhead" and some other stuff. Multithreaded performance (in gcc only, always worked fine on clang/cl) hit was resolved in 2021, and after that it's actually malloc + missed branch that creates most of overhead. Not using exceptions is taking performance hit every time (checking optional/expected, errno, and other ways to emulate exceptions), and usually leads to ignoring problems occurring deeply inside codebase instead of resolving them at places where they can be resolved. > Commercial static analysers work really well on std containers Yep, and after C++11-14 noone actually uses C-style arrays anyway and std::vector is industry standard for any array. Vanilla array usually means skill-issue not that it's used for something usefull
@@isadora-6th I was talking about runtime exceptions on boundary errors like memory-safe language (rust,java,...), not unpredictable external errors such as file not found, network error,... For example, a complicated computer vision algorithm (SLAM,...) that must run safely given a set of preconditions. The image data would probably be stored in an image container of a computer vision library (OpenCV,...), which is not an std container and is currently ignored by the static analyzer. If contracts were supported and at least partially compile-time checked by static analyzers, the library could just add a contract on its containers and be supported by the static analyzer.
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?
On one hand. Memory safety. On the other hand. A tidal wave of gamers and hardcore programmers frothing at their gums for optimization and peak performance with next to no latency in button input.
RAII pointers in C++ get you 90% of the way to memory safety. Buffer overruns have been mitigable through static analysis for ages. In a lot of cases, Rust is a solution in search of a problem.
Why won’t C/C++ with memory safety spell the end of Rust? Because the issue isn’t with the language (C/C++) itself-it’s with the programmers. A small, disciplined team with strong leadership might stick to the 'new' rules and write consistent code, but it takes constant mental effort to stay on track. And it only takes a few slips for those 'new' rules to break down and bugs to creep in. With Rust, that burden is shifted to the compiler, leaving little to no room for the programmer to go off course. Since we’re creatures who learn well with a few 'slaps on the wrist,' it’s no surprise we quickly fall in line with Rust’s rules.
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
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.
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.
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?
@@MichaFita Dude, there is entire IT sector of IoT devices made on NodeJs that is completely memory safe while almost each of them provide unrestricted shell access to your device (and network). It's not language it's skill issue
@@isadora-6thwe're not talking about self-inflicted harm done by selection of wrong tools for the job while being unconscious about fundamental cyberssecurity. We're talking about mistakes made during development that aren't spotted at first sight. You can leave shell access open in Rust application as well, but that's result of pure negligence.
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.
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.
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.
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 UA-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
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.
@ Every time I look at Rust code I'm turned off by its failed attempt at being cool. Its hipsteristics results in unreadable code with insanely long compile times and huge binaries.
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 ... ?
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....
No, we need a better language than C++. Its syntax is awful by modern standards. As a C++ developer, I can tell you that only about 20% of the code actually does anything useful-the rest is just bloat. This becomes even more obvious when you work with static code analysis. Header files? They’re relics from a bygone era. Sure, they’ve introduced modules, and they’re okay, but they still fall short compared to other languages. And don’t even get me started on the terrible tooling in the C++ ecosystem. The ideal solution would be a new language that can integrate seamlessly with legacy C++ code, like Google’s Carbon project.
@@leezhieng They are not, they increase the compile time drastically. Headers were introduced when computers where on low ressources. This argument is often taken pro headers which is simply wrong.
@KANJICODER_IRL there are many reasons, but mainly because of each time a header file is included in a source file, its contents are processed by the preprocessor and the compiler. If multiple source files include the same header file, its contents will be processed repeatedly for each source file. There are already many optimizations, but especially with macros, templates etc. it increases compile time. For example, i increased my compile time with modules by 55%
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.
He killed C++ killer feature with backwards compatibility with this move. You can't compile for windows anything without including some non-standard strange file which compiles on some cross rules between C++11 and C97 with 12 warnings. And all that to have 1% of C++ developers on market to understand your language. What's the point? objective-C already exists
@isadora-6th I love C. C++ Is another thing. It's not great. It's not better. It's much worse. Because of the backwards compatibility, it has every issue that C has and 5 fixes that become their own problems. C++ is just a huge mess. I think they should make a new version that removes everything but the latest correct way. No backwards compatibility at all. That would go along way to fixing C++. But it's still not good enough, I think.
@@ProgrammingRainbow We already have incompatible 'rust is new C++'. New standards of C++ is kinda cool, and actually every project uses it's 'subset' of C++ and on modern projects with C++20 support everything looks really good and problem-less. Worked with team using C++23 and it was really cool. Don't need to remove old features, bc all new code is simply written using modern features and looks better. On the other hand, everyone who could update compiler already did it and others keep in their mess of older C++14 strange stuff. Nowadays im supporting some old large system on C++14 written in 2009 and yeah... everything is not so cool.
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
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!
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
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
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
"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.
@@VoyivodaFTW1 Most of the current programmers don't know what unions do (even when I learned C I didn't get it at all bc unions are only useful in embedded with limited memory resources)
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?
this: "efficiency in execution speed, memory used, and the size of binaries" ...is all post-hoc rationalization, as you can realize if you consider when c was created and why.
@@cgazzz or just don't worry about it and let the hostiles with nation-state backing continue attacking while hoping things work out.
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
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
This happens every 10 years or so. IT consultancy firms and independent consultants need a new mission to find work and make money (and secondary industries such as publications). And tech firms always need scapegoats so they don't have to take responsibility for anything. And it will be all for nought.
In the 80s we had structured programming, analysis and design, 90s we had OOP, 2000s agile/scrum, 2010s functional programming, now memory safety.
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?
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".
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
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.
I love tinkering around with rust, but I'd gladly give it up to see its terrible fanbase cry online
100% hehehehe 😁
Wow what a fraud!
@@RustIsWinning Hahahaha exhibit A
I say rewriting from scratch is a bigger software risk from a security and a business standpoint than fixing what’s already there.
Shhh, let them try it 😂🍻
Interesting to see it took 40+ years … and a clear rival for people to consider adding more safety in C at compile time.
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
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++.
I'm torn between Zig, Odin, and Jai (if I ever get my hands on it). I have an extensive set of libraries I've written in C, and Zig looks like it will be able to use them with no hassel.
@@RockTo11 I have seen Jai, and it does look interesting, though without trying it, there isn't much that I am too excited about. I definitly plan on learning it when it does get released. Between Zig and Odin, they are both good. I personally prefer Zig for most applications, but Odin is enjoyable to use, there is just a few design patterns that keep it from being "great" to me. I always recommend it to Go devs who are interested in game-development, it is fills the niche perfectly.
All that said, don't be torn between any of them, learn them all. I understand you have to somewhat commit to one or another for a certain amount of time to become competent with it, but as someone who used to also feel like I had to choose, I can say that it a self-imposed restriction.
Zigfault NAUR 😂
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.
Why would anyone use Rust if you have a memory safe C++/C? Serious question....
@@CommanderRiker0 I'm working in C++14 codebase due to requirement to work under some 2008 gov OS. We have NO Asan/Bsan and other stuff for safety at all.
We can't use Rust either lol.
BTW i worked at Yandex before and they targeted 24 LTS Ubuntu with C++23 and Asan/Bsan and other sanitizers which simply solved all memory issues which could possibly happen. Also there is a lot more C++ programmers than Rust programmers, and you really can have team of 200 developers without draining full country of them
@@CommanderRiker0 Only garbage woke programmers would use it anyway. They need their safe spaces.
i hate c and c++. so obviously i will learn rust
@@dselvajagan8666 Rust syntax is way worse than c or c++, so that doesn't really make any sense.....
“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 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.
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.
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
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
This is one area where I will gladly tell the government to get coited. I'm not going to listen to a single word of advice from an organization who's average member is almost as old as the transistor itself. They can't get a single solitary thing done when it comes to law, what gall do they have to think they can suggest anything when it comes to technology?
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 recently read a treatise on pointers in C++ stating that we actually still don't know fully what a pointer is according to the standard, and there is open research to properly define it. Nice to see Fil-C defining a model for pointers that does incorporate some of these findings (like internal bounds).
Not really sure why you need to defend C++. C++ is honestly doing just fine in the real world, that world outside of the constantly context switching, profiting on hype, youtubers.
Amen.
There are 2 types of languages:
1) Languages that people complain about
2) Languages that nobody uses
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.
There is a lot of dudes that heard that C/C++ is unsafe, and throw words like "UNSAFFFEE" while most of the security breaches happen due to lack of user input validation in Log4j for example lol
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
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
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".
Step 1. Use memory-safe language.
Step 2. Use unsafe block.
Step 3. Use unsafe block?!!
tbh I don't think it's possible to have a usable system lang that can't do anything memory unsafe at all
> Use memory-safe language.
Use JS lol?
Learn what abstraction means
There is no substitute for good workmanship.
Migration to rust was never an safety option it was about creating new job opportunities by forcing legacy companies to rewrite already working code.
Of course migrating to Rust is a safety option. Look at how companies are doing that in practice: E.g. Google's Android team writes all new low-level code in Rust and migrates only the most safety-critical components. Old battle-tested code can stay in C, because the bugs have already been shaken out. Minimal effort, maximal security benefits.
@@llogiq linux rust drama is saying something totally different about minimal effort....
@DJenriqez have you actually looked into what happened? Some Linux maintainers apparently oppose even documenting lifetime requirements in their code, let alone fixing them to be consistent.
@@DJenriqez There is no drama. Linux C people are helping out 😊
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.
I hate memory safety, give me all the weapons, unlocked!
legs be prepared
Rust cannot die at all.
Rust is optimized for performance while maintaining high safety.
If Rust is so optimized, why Tokio is so slow? :D. It's like 5 times faster to run Go VM and use it than your native and performative approach)
@@isadora-6th Rust and Tokio aren’t slow, Go’s runtime handles concurrency for you, making it easy and fast for simple use cases, but that comes with overhead. Tokio gives you control and performance determinism, which requires effort but scales better for complex tasks. Also, Rust’s debug builds are slow-benchmark in release mode before making claims. If Go works for you, great, but don’t confuse simplicity with raw performance.
C++ committee now laughing evilly at the perverse thought of bloating the spec even further
So they brought Rust to C++ just to avoid learning Rust.
C++ devours every programming concept its standards commitee has heard about...
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,
You don't have to use any of these features. C++ gives you choices, unlike other languages. Professionals need and appreciate that.
@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.
Same , I'm on my 3rd c++ job and my life is addressing code review comments from snarky co workers about the most ridiculous foot guns. The language is an arbitrary mess and i yearn to be free from it.
8:35 remove union
How unsvilized
C and C++ programmer here. I wouldn't consider them *great* languages. C is good for its express purpose. C++ is ... adequate, but actually a technical mess, that was not really understood at the time it was originally designed. Rust is as of yet, more like a fanboy hype. It promises a great deal of sound technology, except the messy ownership rules of allocated memory. It will be fine in the future, but lacking an ABI for dynamical binding is *_not_* mature. For the rest I wish a sound memory allocation model for C and C++, but that won't make them great. That would make them a little bit more sufferable.
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.
First they came for the unions, and they did not speak out.
Then they came for the pointers, and again they did not speak out.
Finally they came for the heap, and by then it was too late.
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.
@@hiankun Why Tokio is slow compared to Go VM? Isn't there supposed to be no overhead?
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
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
Meme comment: you cant spell "copium" without C!
You can't spell "memory corruption" without C
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.
after u mention union, i know you have no idea you are talking about. Union is fundamental part of any project.
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.
The only solution I could think of was the path the Fil-C followed. But I didn't have the knowledge and time to sit down and write a modern compiler. I was glad to hear someone wrote one. I hope they will also think of extending Fil-C with generics. Because I don't want to be stuck with C++.
I would like to give a message to the Rust community as well. Make some additions that will not make Rust dependent on C and including C libraries into the projects (maybe enhancing the ecosystem with Fil-C compiler). Because their intention is to kill Rust by adding Rust's solutions to C/C++. So include Rust into the same ecosystem and lead them. 😄(After a talk given by Stroustroup I wrote, "He plans to turn C++ into Rust")
Yes, Rust's secret was to make the compiler safe, the rules we learn as the rules of the Rust language are actually the rules of the Rust compiler. Every language is as reliable as the freedom given by the compiler, if you don't allow obvious errors to be compiled, that language becomes reliable. So creating Fil-C to save C is the right decision.
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
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.
> extend C++
first time, eh?
"No we don't was to add proposal for WG21 and get shit on by skillfull granddads, we want to make world better place!"
C++ is like one of those cities with major traffic congestion that evolved with time and they had to make a lot of patches to adapt it to the new environment, while Rust is one of those cities designed from the ground up that just works efficiently.
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
6:12 - Before Fil-C was created 7:21 - After Fil-C was created
C and C++ ... the Saw series of the programming world.
C/C++ still won't have legit pattern matching. As a compiler writer, I want pattern matching.
EDIT: lol, my bad, they are actually doing it
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.
oh, we forgot to validate user input on our NodeJS IoT device, we are sowry that it was basically rootkit, will do it same later :D.
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
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.
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.
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.
> runtime exception
Dude, it's performance feature not a problem lol. And if happens, there usually no point in keeping "performance".
> Static analysers are quite good at catching under/overflows on standard arrays
You are using C97 in context of C++20 (23 years apart), There is NO ONE who uses them seriously lol
@isadora-6th in context like self driving, you cannot suddenly stop because you got a runtime exception. Quick restart is not a perfect solution either because the next frame could cause the same problem if similar. Even if the code doesn't cause any exception during 100000h of test sequence and pass all the unit tests, you have no guarantee that it will not happen unless you can prove that it cannot happen. Manual review is not infallible and current formal proof systems are nearly unusable on real code unless you want to prove a very small portion. Compile-time checked contracts could be a first step into proof system usable on real code.
Commercial static analysers work really well on std containers and are used in most safety critical softwares as one of the safety checks (among many others).
@@randomprototypes4471 You say: Exception happens.
I say, exception happens due to a reason, and usually, exception reasons change workflow significantly enough to skip a frame.
Like, "file not found", "Can't write to IO", "malloc alloc failed (no mem provided)", user exceptions in some cases where you can't continue. There is no point in performance ANYWAY. There usually no point in continuing work like algorithm that calculates something founds error in inputs at late stage.
If you use exceptions as return channel, it's quite punchy. Not WORLD STOP like java, but a hit. And most of exception overhead happens due to (?)))) malloc for x bytes to place exception on heap, which could take time for system call in rare cases, but thats unlucky :D.
I say, exception overhead happens due to malloc inside, not because exceptions is bad.
If your system uses system malloc, and you see there no problem there, not using exceptions is at least strange and usually happens due to lack of understanding
Also WG21 got a lot of funny proposals during 2021-2022 season where "value exceptions" where presented as solution for "overhead" and some other stuff. Multithreaded performance (in gcc only, always worked fine on clang/cl) hit was resolved in 2021, and after that it's actually malloc + missed branch that creates most of overhead.
Not using exceptions is taking performance hit every time (checking optional/expected, errno, and other ways to emulate exceptions), and usually leads to ignoring problems occurring deeply inside codebase instead of resolving them at places where they can be resolved.
> Commercial static analysers work really well on std containers
Yep, and after C++11-14 noone actually uses C-style arrays anyway and std::vector is industry standard for any array. Vanilla array usually means skill-issue not that it's used for something usefull
@@isadora-6th I was talking about runtime exceptions on boundary errors like memory-safe language (rust,java,...), not unpredictable external errors such as file not found, network error,...
For example, a complicated computer vision algorithm (SLAM,...) that must run safely given a set of preconditions.
The image data would probably be stored in an image container of a computer vision library (OpenCV,...), which is not an std container and is currently ignored by the static analyzer. If contracts were supported and at least partially compile-time checked by static analyzers, the library could just add a contract on its containers and be supported by the static analyzer.
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?
On one hand. Memory safety.
On the other hand. A tidal wave of gamers and hardcore programmers frothing at their gums for optimization and peak performance with next to no latency in button input.
RAII pointers in C++ get you 90% of the way to memory safety. Buffer overruns have been mitigable through static analysis for ages. In a lot of cases, Rust is a solution in search of a problem.
Why won’t C/C++ with memory safety spell the end of Rust? Because the issue isn’t with the language (C/C++) itself-it’s with the programmers. A small, disciplined team with strong leadership might stick to the 'new' rules and write consistent code, but it takes constant mental effort to stay on track. And it only takes a few slips for those 'new' rules to break down and bugs to creep in. With Rust, that burden is shifted to the compiler, leaving little to no room for the programmer to go off course. Since we’re creatures who learn well with a few 'slaps on the wrist,' it’s no surprise we quickly fall in line with Rust’s rules.
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
1:10 grab the pichforks!
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 re-wrote a personal c++ project in Rust. The codebase reduced by 90%. C++ is obsolete.
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 much prefer the clean beauty of C over rust and snakes. Just use an add-on library if you really need to.
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?
@@MichaFita Dude, there is entire IT sector of IoT devices made on NodeJs that is completely memory safe while almost each of them provide unrestricted shell access to your device (and network).
It's not language it's skill issue
@@isadora-6thwe're not talking about self-inflicted harm done by selection of wrong tools for the job while being unconscious about fundamental cyberssecurity. We're talking about mistakes made during development that aren't spotted at first sight. You can leave shell access open in Rust application as well, but that's result of pure negligence.
YourMama made MMU on my lap LMAO
Why we don’t learn from Apple they did it for objective-c. They made it memory safe before killing it within Swift. 😂
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.
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.
C/C++: Hey look at me. Look at me.
Rust: Ok
C/C++: I’m the safety now.
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.
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 UA-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
Thank G-d. C++ until they put me into the ground.
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.
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.
Every time I look at Ada code it looks oooooold without cool language features.
@ Every time I look at Rust code I'm turned off by its failed attempt at being cool. Its hipsteristics results in unreadable code with insanely long compile times and huge binaries.
@@bobweiram6321 Now that you mention it it's interesting that both langs use ' in a hipsteristic way lol
Getting rid of "unsafe" used in Rust, sounds like getting rid of axioms in mathematics, good luck.
Memory safe C/C++ is 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 ... ?
The irony of giving a talk called "Trap C" in a place like thailand.....
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
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....
No, we need a better language than C++. Its syntax is awful by modern standards. As a C++ developer, I can tell you that only about 20% of the code actually does anything useful-the rest is just bloat. This becomes even more obvious when you work with static code analysis. Header files? They’re relics from a bygone era. Sure, they’ve introduced modules, and they’re okay, but they still fall short compared to other languages. And don’t even get me started on the terrible tooling in the C++ ecosystem. The ideal solution would be a new language that can integrate seamlessly with legacy C++ code, like Google’s Carbon project.
I agree, thats why I am personally really excited for Carbon. It could be a legit game changer for the C++ ecosystem
Headers are good for huge projects.
@@leezhieng They are not, they increase the compile time drastically. Headers were introduced when computers where on low ressources. This argument is often taken pro headers which is simply wrong.
The problem I see with carbon is Google 😵💫
@KANJICODER_IRL there are many reasons, but mainly because of each time a header file is included in a source file, its contents are processed by the preprocessor and the compiler. If multiple source files include the same header file, its contents will be processed repeatedly for each source file. There are already many optimizations, but especially with macros, templates etc. it increases compile time. For example, i increased my compile time with modules by 55%
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.
He killed C++ killer feature with backwards compatibility with this move.
You can't compile for windows anything without including some non-standard strange file which compiles on some cross rules between C++11 and C97 with 12 warnings.
And all that to have 1% of C++ developers on market to understand your language. What's the point? objective-C already exists
@isadora-6th I love C. C++ Is another thing. It's not great. It's not better. It's much worse. Because of the backwards compatibility, it has every issue that C has and 5 fixes that become their own problems. C++ is just a huge mess. I think they should make a new version that removes everything but the latest correct way. No backwards compatibility at all. That would go along way to fixing C++. But it's still not good enough, I think.
@@ProgrammingRainbow We already have incompatible 'rust is new C++'.
New standards of C++ is kinda cool, and actually every project uses it's 'subset' of C++ and on modern projects with C++20 support everything looks really good and problem-less. Worked with team using C++23 and it was really cool. Don't need to remove old features, bc all new code is simply written using modern features and looks better.
On the other hand, everyone who could update compiler already did it and others keep in their mess of older C++14 strange stuff. Nowadays im supporting some old large system on C++14 written in 2009 and yeah... everything is not so cool.
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.
Do you see that someone making a contribution on C++ standard got banned because he ised the word "Question" ?
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