A New Era for C and C++? Goodbye, Rust?

แชร์
ฝัง
  • เผยแพร่เมื่อ 24 ธ.ค. 2024

ความคิดเห็น •

  • @TravisMedia
    @TravisMedia  หลายเดือนก่อน +9

    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.

    • @budgetarms
      @budgetarms หลายเดือนก่อน

      emm c++ has smartpointers, if Rust had the C/C++d syntax, people would switch basically immediately.
      The Rust syntax is just plain ugly.

    • @budgetarms
      @budgetarms หลายเดือนก่อน

      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.

    • @vlya1533
      @vlya1533 26 วันที่ผ่านมา +2

      ​@@budgetarms "since it works" - Have you tried to compile something with it?

    • @budgetarms
      @budgetarms 26 วันที่ผ่านมา

      @@vlya1533 No, but I assume it does, I will test it later; also why is comment gone?

    • @z28141
      @z28141 24 วันที่ผ่านมา +1

      Where does Java fit in this discussion?

  • @nskeip
    @nskeip หลายเดือนก่อน +449

    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

    • @TheRealJman87
      @TheRealJman87 หลายเดือนก่อน +102

      I don't think this guy knows much about C lol

    • @Kevin-yz7ji
      @Kevin-yz7ji 29 วันที่ผ่านมา +66

      I only dabble in C for embedded stuff and use Unions all the time. That comment made me do the Spock eyebrow thingy.

    • @MrChelovek68
      @MrChelovek68 29 วันที่ผ่านมา

      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.

    • @nochan99
      @nochan99 29 วันที่ผ่านมา +21

      I came here to say this. Thank you for saving me 13 seconds.

    • @yazeldafan
      @yazeldafan 29 วันที่ผ่านมา +24

      C++ programmer here that deals with some kernel module bugs from time to time. I see union used all the time in kernel code.

  • @dealloc
    @dealloc หลายเดือนก่อน +537

    "Just use my compiler and it'll be safe" is something I've heard thousands of times already.

    • @LedoCool1
      @LedoCool1 หลายเดือนก่อน +46

      Yeah. Rust crowd loves that song.

    • @RenderingUser
      @RenderingUser หลายเดือนก่อน +10

      It's true tho.

    • @SianaGearz
      @SianaGearz หลายเดือนก่อน +59

      @@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
      @LedoCool1 หลายเดือนก่อน +12

      @@SianaGearz it's called linter.

    • @SianaGearz
      @SianaGearz หลายเดือนก่อน +26

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

  • @coldlyanalytical1351
    @coldlyanalytical1351 หลายเดือนก่อน +449

    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.

    • @ashketchum6139
      @ashketchum6139 หลายเดือนก่อน +9

      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.

    • @okaforchukwunonsojoseph3862
      @okaforchukwunonsojoseph3862 หลายเดือนก่อน +1

      Nice one

    • @nguyen_tim
      @nguyen_tim หลายเดือนก่อน +8

      I’m curious how you distinguish between application development languages and what C should’ve been?

    • @coldlyanalytical1351
      @coldlyanalytical1351 หลายเดือนก่อน +25

      @@nguyen_tim C was exactly what is was intended to be : a 'portable assembler' intended for writing systems software.

    • @rezah336
      @rezah336 หลายเดือนก่อน +1

      i hate misra

  • @nerd-nq5ic
    @nerd-nq5ic 19 วันที่ผ่านมา +21

    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.

  • @oserodal2702
    @oserodal2702 หลายเดือนก่อน +348

    Removing unions from C is a major L.

    • @cod3r1337
      @cod3r1337 หลายเดือนก่อน +38

      C doesn't have templates. It's supposed to be a *simple* language.

    • @baileyharrison1030
      @baileyharrison1030 หลายเดือนก่อน

      @@santitabnavascues8673 In C++ not C. Even then, the template implementations for std::variant are going to use unions anyway.

    • @cod3r1337
      @cod3r1337 หลายเดือนก่อน +11

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

    • @TheRealJman87
      @TheRealJman87 หลายเดือนก่อน

      @@santitabnavascues8673 I don't think you understand the difference between C and C++, or what templates are

    • @rusi6219
      @rusi6219 หลายเดือนก่อน +14

      ​@@framepointerC was never a subset of C++ stop repeating what you heard others say

  • @ryandodrill6904
    @ryandodrill6904 28 วันที่ผ่านมา +98

    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.

    • @christopheroliver148
      @christopheroliver148 27 วันที่ผ่านมา +8

      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.

    • @TJackson736
      @TJackson736 24 วันที่ผ่านมา

      If you want memory managed C, just use Go.

    • @cgazzz
      @cgazzz 22 วันที่ผ่านมา +7

      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?

  • @tonig2757
    @tonig2757 29 วันที่ผ่านมา +75

    "It removes some rarely used keywords like 'union'". Ok, you've lost me man.

    • @Sravdar
      @Sravdar 18 วันที่ผ่านมา +3

      Dont know the rest but union is must in embedded software development.

    • @VoyivodaFTW1
      @VoyivodaFTW1 3 วันที่ผ่านมา +1

      people who don't know what unions are should not be writing programming languages lol.

  • @alaaalhallaq108
    @alaaalhallaq108 หลายเดือนก่อน +111

    rarely used keywords like union !!!! WTH !

    • @paleopteryx
      @paleopteryx 29 วันที่ผ่านมา

      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!

    • @FlanPoirot
      @FlanPoirot 22 วันที่ผ่านมา +2

      so useless that holy rust itself decided it was necessary to include despite having sum types (aka enums) :)

    • @sunofabeach9424
      @sunofabeach9424 11 วันที่ผ่านมา

      @@FlanPoirot C unions aren't Rust enums. Like at all. Rust enum is memory safe, C union is not.

    • @FlanPoirot
      @FlanPoirot 11 วันที่ผ่านมา

      @@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)

    • @sunofabeach9424
      @sunofabeach9424 11 วันที่ผ่านมา +1

      @@FlanPoirot lmao my bad

  • @BangkokBubonaglia
    @BangkokBubonaglia หลายเดือนก่อน +13

    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.

    • @captainwasabi
      @captainwasabi 28 วันที่ผ่านมา +2

      if they left void* they might as well have just not even started.

  • @eightsprites
    @eightsprites 29 วันที่ผ่านมา +71

    Always the “it’s slower than C, but…..”
    Well that’s the issue right there.

    • @OCTAGRAM
      @OCTAGRAM 28 วันที่ผ่านมา +5

      Overestimated issue compared to big Oh optimizations

    • @keizbot
      @keizbot 28 วันที่ผ่านมา +9

      Rust is about 10% slower IIRC. I think that's worth it given the safety tradeoffs

    • @ХузинТимур
      @ХузинТимур 26 วันที่ผ่านมา +3

      @@OCTAGRAM And making big O optimizations is easier in language like Rust.

    • @comradepeter87
      @comradepeter87 26 วันที่ผ่านมา +1

      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

    • @OCTAGRAM
      @OCTAGRAM 26 วันที่ผ่านมา +2

      @@ХузинТимур No, I think, this statement would be against the truth often enough

  • @HollywoodCameraWork
    @HollywoodCameraWork หลายเดือนก่อน +53

    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?

    • @oserodal2702
      @oserodal2702 หลายเดือนก่อน +8

      You are part of the problem buddy.

    • @Kiyuja
      @Kiyuja หลายเดือนก่อน +17

      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.

    • @pietraderdetective8953
      @pietraderdetective8953 หลายเดือนก่อน +5

      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!

    • @kamilmensik6521
      @kamilmensik6521 หลายเดือนก่อน +4

      ​@@Kiyuja This is such a horrendous take.

    • @mk72v2oq
      @mk72v2oq หลายเดือนก่อน +10

      C++ smart pointers do not protect you from use-after-free and buffer overflows. The main problems actually responsible for majority of vulnerabilities.

  • @SianaGearz
    @SianaGearz หลายเดือนก่อน +75

    Are you just like... reading off everyone's marketing blurbs without thinking it through for yourself?

    • @haomakk
      @haomakk หลายเดือนก่อน +9

      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.

    • @varadinagypal
      @varadinagypal 26 วันที่ผ่านมา +13

      @@haomakk rarely used union? In which universe is that true enough to get into "news"?

    • @crackwitz
      @crackwitz 14 วันที่ผ่านมา

      ​@@varadinagypalin what universe do the news strive for truth?

  • @etherweb6796
    @etherweb6796 29 วันที่ผ่านมา +46

    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.

    • @vidal9747
      @vidal9747 28 วันที่ผ่านมา +3

      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.

    • @etherweb6796
      @etherweb6796 28 วันที่ผ่านมา +3

      @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++)

    • @etherweb6796
      @etherweb6796 28 วันที่ผ่านมา +2

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

    • @computernerd8157
      @computernerd8157 27 วันที่ผ่านมา +1

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

    • @kissmyoradora83
      @kissmyoradora83 25 วันที่ผ่านมา

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

  • @sebschrader
    @sebschrader หลายเดือนก่อน +162

    Unions? Rarely used ?!

    • @yapdog
      @yapdog หลายเดือนก่อน +17

      That's BS. I can't get by without unions

    • @TheRealJman87
      @TheRealJman87 หลายเดือนก่อน +19

      Yeah I don't think this guy knows much about C lol

    • @Th1200
      @Th1200 หลายเดือนก่อน

      they are pain to use compared to rust's enums tho

    • @tordjarv3802
      @tordjarv3802 29 วันที่ผ่านมา +11

      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.

    • @Th1200
      @Th1200 29 วันที่ผ่านมา +2

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

  • @JohannY3
    @JohannY3 หลายเดือนก่อน +111

    Interesting. It makes a lot more sense to make C++ code safe than to port millions of lines of code.

    • @dj_jiffy_pop
      @dj_jiffy_pop หลายเดือนก่อน

      Millions?

    • @flarebear5346
      @flarebear5346 หลายเดือนก่อน +26

      Yes, millions

    • @catto-from-heaven
      @catto-from-heaven หลายเดือนก่อน +20

      Tens of millions, actually

    • @romangeneral23
      @romangeneral23 หลายเดือนก่อน +20

      ​@@catto-from-heaven Hundreds of Millions

    • @raykirushiroyshi2752
      @raykirushiroyshi2752 หลายเดือนก่อน +14

      But,you're not making the old code safe,so you still have to rewrite it to fix the safety issues

  • @OllegN
    @OllegN 20 วันที่ผ่านมา +2

    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".

  • @conman7644
    @conman7644 22 วันที่ผ่านมา +5

    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.

  • @deckard5pegasus673
    @deckard5pegasus673 หลายเดือนก่อน +114

    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.

    • @CSPlayerDamon
      @CSPlayerDamon หลายเดือนก่อน +17

      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?

    • @IlyaDenisov
      @IlyaDenisov หลายเดือนก่อน +12

      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?

    • @ajanicij
      @ajanicij 29 วันที่ผ่านมา

      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.

    • @deckard5pegasus673
      @deckard5pegasus673 29 วันที่ผ่านมา +7

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

    • @deckard5pegasus673
      @deckard5pegasus673 29 วันที่ผ่านมา +15

      @@CSPlayerDamon you can make the same tools in a c library

  • @DJenriqez
    @DJenriqez 18 วันที่ผ่านมา +3

    Migration to rust was never an safety option it was about creating new job opportunities by forcing legacy companies to rewrite already working code.

  • @soapyfrog
    @soapyfrog หลายเดือนก่อน +25

    “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.

    • @davidlocontes3564
      @davidlocontes3564 10 วันที่ผ่านมา

      That adds gratuitous complexity to a project without making it actually safe. Just learn to use C++ and use it in a safe manner.

  • @ForeverZer0
    @ForeverZer0 20 วันที่ผ่านมา +3

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

  • @Leon-iu5eq
    @Leon-iu5eq 29 วันที่ผ่านมา +28

    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.

    • @MrChelovek68
      @MrChelovek68 29 วันที่ผ่านมา +4

      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

    • @llogiq
      @llogiq 21 วันที่ผ่านมา

      That will surely help with buffer overruns and type confusion (which can lead to stack smashing).

    • @Leon-iu5eq
      @Leon-iu5eq 21 วันที่ผ่านมา

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

    • @llogiq
      @llogiq 21 วันที่ผ่านมา +1

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

    • @Leon-iu5eq
      @Leon-iu5eq 21 วันที่ผ่านมา +2

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

  • @jaysistar2711
    @jaysistar2711 29 วันที่ผ่านมา +24

    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.

    • @MrChelovek68
      @MrChelovek68 29 วันที่ผ่านมา

      all hate rust) and no, rust it's useless marketing crap. that's why you don't fly on airplane, which programming on rust.

    • @RomanAvdeevX
      @RomanAvdeevX 23 วันที่ผ่านมา

      @@MrChelovek68 C/C++ is only defended by elitists, who can't comprehend another language

  • @heavymetalmixer91
    @heavymetalmixer91 หลายเดือนก่อน +25

    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 ¬_¬

  • @DanielSantanaBjj
    @DanielSantanaBjj 28 วันที่ผ่านมา +7

    Long live #RustLang 🦀

    • @RustIsWinning
      @RustIsWinning 26 วันที่ผ่านมา +1

      YES!! ❤🦀

  • @sharkysharkerson
    @sharkysharkerson 18 วันที่ผ่านมา +3

    I say rewriting from scratch is a bigger software risk from a security and a business standpoint than fixing what’s already there.

  • @raimo7911
    @raimo7911 หลายเดือนก่อน +21

    Remove unions? Whyy

    • @robertadsett5273
      @robertadsett5273 25 วันที่ผ่านมา

      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

  • @esra_erimez
    @esra_erimez หลายเดือนก่อน +24

    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
      @KANJICODER_IRL หลายเดือนก่อน +7

      C23 has me worried it is going to end up like C++ , a disaster .

    • @marvinadams4784
      @marvinadams4784 29 วันที่ผ่านมา +5

      You don't have to use any of these features. C++ gives you choices, unlike other languages. Professionals need and appreciate that.

    • @KANJICODER_IRL
      @KANJICODER_IRL 27 วันที่ผ่านมา +4

      @marvinadams4784 I hear this argument a lot . But its not about the health of your individual code base . Its about the health of the ecosystem .

    • @bytefu
      @bytefu 25 วันที่ผ่านมา

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

    • @C2H6Cd
      @C2H6Cd 20 วันที่ผ่านมา +4

      Very true, really bloated language.

  • @levieux1137
    @levieux1137 23 วันที่ผ่านมา +3

    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.

  • @DamaxThomas
    @DamaxThomas 21 วันที่ผ่านมา +1

    Interesting to see it took 40+ years … and a clear rival for people to consider adding more safety in C at compile time.

  • @11_22_XX
    @11_22_XX หลายเดือนก่อน +7

    8:35 remove union
    How unsvilized

  • @RodrigoOliveira-cc3kc
    @RodrigoOliveira-cc3kc หลายเดือนก่อน +42

    Rust is sure ensuring safer coding: "Either you write flawless C/C++ code or you will have to stand Rust!" 😂😂😂😂😂

    • @Th1200
      @Th1200 หลายเดือนก่อน +3

      because flawless c++ is the norm...

    • @HyperCodec
      @HyperCodec 24 วันที่ผ่านมา +1

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

    • @RomanAvdeevX
      @RomanAvdeevX 23 วันที่ผ่านมา +5

      @@Th1200 Imagine having such a massive ego to say, that you always write everything perfect

  • @dwight4k
    @dwight4k หลายเดือนก่อน +5

    I don't see the Filip Pizlo presentation in the notes, and I can't find it on TH-cam.
    Can somebody please share it?

    • @chrboesch
      @chrboesch หลายเดือนก่อน

      th-cam.com/users/live_VF3pISRYRc?t=4862s

    • @droid806
      @droid806 หลายเดือนก่อน

      th-cam.com/users/live_VF3pISRYRc?t=4862s

  • @jimmy21584
    @jimmy21584 24 วันที่ผ่านมา +2

    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.

  • @TheoParis
    @TheoParis 27 วันที่ผ่านมา +5

    I love how no one here is talking about sanitizers that are available in modern compilers... asan, ubsan, etc. exists for a reason

    • @RustIsWinning
      @RustIsWinning 26 วันที่ผ่านมา +1

      Not good enough

  • @chbrules
    @chbrules 15 วันที่ผ่านมา +1

    The C/C++ community was caught with their pants down and weren't able to pivot with the industry in time. Now you have Rust and Zig, among others. Those aren't going away. Big institutions have already committed to Rust, specifically. C/C++ are getting long in the tooth and are being stretched to the limits with adding more things rather than simply trying to pivot and move on. Zig is a great concept of being completely C-compatible, but offers memory safety and new language enhancements that can work independently of C.

  • @JulianBolivarGaleno74
    @JulianBolivarGaleno74 29 วันที่ผ่านมา +7

    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.

    • @hiankun
      @hiankun 29 วันที่ผ่านมา +2

      "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...

    • @godslayer7905
      @godslayer7905 27 วันที่ผ่านมา

      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.

    • @ensuretime
      @ensuretime 23 วันที่ผ่านมา

      "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.

    • @MichaFita
      @MichaFita 15 วันที่ผ่านมา

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

  • @theevilcottonball
    @theevilcottonball 24 วันที่ผ่านมา +2

    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.

  • @douglasstrother6584
    @douglasstrother6584 28 วันที่ผ่านมา +3

    There is no substitute for good workmanship.

  • @kwyaza
    @kwyaza 21 วันที่ผ่านมา

    I have very little knowledge of C/C++ so maybe this is not possible, but instead of any standard library changes, just make the compiler build for a certain runtime similar to the java JVM, doesn't need to be a full virtual machine like the JVM, but just a thin wrapper ontop of the hardware that actively checks and prevents memory leaks and other issues.

  • @AntenainaLand
    @AntenainaLand 29 วันที่ผ่านมา +18

    C & C++ developers: "Rust sucks."
    C & C++ actually: "let's make C & C++ memory safe by adding Rust features to them"

    • @tuguzT
      @tuguzT 29 วันที่ผ่านมา +4

      And they don't want to learn Rust just because it's... For now, I don't know, really...

    • @AntenainaLand
      @AntenainaLand 29 วันที่ผ่านมา +7

      @@tuguzT with knowing that Rust is way much easier to learn and way more fun to use than C and especially C++.
      Using Cargo and Rustup, developer experience is so much easier and funnier than using CMake.

    • @christianm4906
      @christianm4906 29 วันที่ผ่านมา +6

      @@AntenainaLand It's not about learning or not Rust, but about code reusability. Rust discards decades of existing code, making it no successor to C or C++. A better approach is adding memory-safe features to C and C++ themselves, which is likely to happen soon.

    • @tuguzT
      @tuguzT 29 วันที่ผ่านมา

      @@christianm4906 "Rust discards decades of existing code" in case you are telling about support of existing software, should Rust preserve it in the first place? Isn't it beneficial not to rewrite everything in Rust but write new software on this language?

    • @tuguzT
      @tuguzT 29 วันที่ผ่านมา

      @@christianm4906 idea of adding memory safety features to C/C++ is great, I admit that. But will that apply to the existing software? And if it does, in case of properly written code this guarantees / features should work, in case of erroneous code, how does it severely differs from rewriting it on memory safe alternative?
      I guess the main issue lies in separating of so-called "unsafe" and "safe" languages (and of the codebase as such).

  • @JoelIvoryJohnson
    @JoelIvoryJohnson 26 วันที่ผ่านมา +2

    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.

    • @robertadsett5273
      @robertadsett5273 25 วันที่ผ่านมา

      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

  • @MrHaggyy
    @MrHaggyy หลายเดือนก่อน +8

    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.

    • @bytefu
      @bytefu 25 วันที่ผ่านมา +1

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

    • @MrHaggyy
      @MrHaggyy 25 วันที่ผ่านมา

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

    • @MichaFita
      @MichaFita 15 วันที่ผ่านมา

      ​@@MrHaggyyhave you heard about Embassy?

  • @randomprototypes4471
    @randomprototypes4471 19 วันที่ผ่านมา +1

    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.

    • @s.b.8704
      @s.b.8704 18 วันที่ผ่านมา

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

  • @emcell2
    @emcell2 29 วันที่ผ่านมา +6

    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.

    • @hiankun
      @hiankun 29 วันที่ผ่านมา +3

      YES. Just `cargo build` `cargo add foo` `cargo doc`... Such a blessing process to work with.

    • @itsmenatika
      @itsmenatika 29 วันที่ผ่านมา +2

      I can't stand absence of something like npm, pip or that thing that rust got

    • @TheGodfather101
      @TheGodfather101 29 วันที่ผ่านมา +2

      Cargo ftw

  • @zainahmed4172
    @zainahmed4172 22 วันที่ผ่านมา +2

    Rust cannot die at all.
    Rust is optimized for performance while maintaining high safety.

  • @qy9MC
    @qy9MC หลายเดือนก่อน +112

    Yeah there's no way I am giving up on C

    • @RustIsWinning
      @RustIsWinning หลายเดือนก่อน +6

      Missed punctuation after "way". Glad you give up on C 😊

    • @qy9MC
      @qy9MC หลายเดือนก่อน +29

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

    • @RustIsWinning
      @RustIsWinning หลายเดือนก่อน +4

      @@qy9MC Did not ask but keep practicing Patrick!

    • @TheRealJman87
      @TheRealJman87 หลายเดือนก่อน +40

      @@RustIsWinning Rust fanboys are so weird. Just enjoy your favorite language let everyone else do the same

    • @venkatramakkineni
      @venkatramakkineni หลายเดือนก่อน

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

  • @lalgonultas
    @lalgonultas 26 วันที่ผ่านมา +2

    If I were in your shoes, I would choose to learn Rust. Rust is definitely a language that’s gaining momentum, and its strong focus on safety and modern systems programming makes it a great choice for anyone looking to write fast, reliable, and concurrent code.

    • @kodiak2fitty
      @kodiak2fitty 13 วันที่ผ่านมา

      It's had time to occupy/replace 0.001% of the C/C++ existing codebase. HUGE momentum. Give it 20 years and everyone will be griping at how many problems Rust causes.

  • @hasensaurus
    @hasensaurus หลายเดือนก่อน +6

    C and C++ ... the Saw series of the programming world.

  • @darrendrapkin4508
    @darrendrapkin4508 6 วันที่ผ่านมา

    It is a valid point that memory safety in, lower level languages like C, is often manifested by, dangling pointers and, buffer overruns. However, in some higher level ones like python, in a frantic effort to stop this sort of thing, they have created a high-level combination of the two. In python, it is now impossible to tell when you can assign from one data structure to another, even if one is a copy of another, and when you need to resort to nonsense like a=b.copy(deep=False) in order to create an alias so you can update "a" in place!

  • @meryplays8952
    @meryplays8952 หลายเดือนก่อน +17

    Let C stay unsafe. Use safety in a higher level language. Still things can be done for tooling, documentation and safer practices.

    • @Flames_Spirit
      @Flames_Spirit 24 วันที่ผ่านมา +2

      But i want to let Linux kernel be in C. Assembly if preferable

    • @meryplays8952
      @meryplays8952 23 วันที่ผ่านมา

      @@Flames_Spirit if people used uKernels, assembly would be another solution

    • @RomanAvdeevX
      @RomanAvdeevX 23 วันที่ผ่านมา +1

      @@Flames_Spirit Let it be in binary

  • @KristoferPettersson
    @KristoferPettersson 24 วันที่ผ่านมา

    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.

  • @OGdoCavaco
    @OGdoCavaco หลายเดือนก่อน +16

    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

    • @rusi6219
      @rusi6219 หลายเดือนก่อน +4

      No, no, and no. You just want to offload your work onto someone else.

    • @RustIsWinning
      @RustIsWinning หลายเดือนก่อน

      ​@@rusi6219yoo old friend. That's a way better pfp :D

    • @OGdoCavaco
      @OGdoCavaco หลายเดือนก่อน

      @@rusi6219 Yes, I want that! :D

    • @rusi6219
      @rusi6219 หลายเดือนก่อน

      @@RustIsWinning yeah I became convinced images of living beings are not permissible even if they're digital

    • @mek101whatif7
      @mek101whatif7 29 วันที่ผ่านมา +2

      @@rusi6219 Big words for someone not programming in assembly

  • @user-tk2jy8xr8b
    @user-tk2jy8xr8b 17 วันที่ผ่านมา +2

    > extend C++
    first time, eh?

  • @muskyoxes
    @muskyoxes 28 วันที่ผ่านมา +3

    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.

    • @OSrBurns
      @OSrBurns 19 วันที่ผ่านมา

      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.

  • @GilbertoAlbino
    @GilbertoAlbino 29 วันที่ผ่านมา +2

    As far as I know, isn't that paper for software developed for US Governament-related code?

  • @cybernit3
    @cybernit3 หลายเดือนก่อน +5

    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.

    • @frydac
      @frydac 29 วันที่ผ่านมา +1

      Safe C++ is a proposal to add features to C++, it's not a different language

    • @spiffjekey-green4034
      @spiffjekey-green4034 27 วันที่ผ่านมา

      Same thought

    • @vlya1533
      @vlya1533 27 วันที่ผ่านมา +1

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

    • @cybernit3
      @cybernit3 26 วันที่ผ่านมา +1

      @@vlya1533 Honestly, no I just read about it a little for now.

    • @bytefu
      @bytefu 25 วันที่ผ่านมา

      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.

  • @gordonshumway888
    @gordonshumway888 19 วันที่ผ่านมา

    C++ is an ancient dinosaur with many layers upon layers upon other layers of concepts of programmers of different generations. It is obvious that this language needs to be remade. Not changed into a new standard, but re-written completely from scratch.

  • @coldlyanalytical1351
    @coldlyanalytical1351 หลายเดือนก่อน +12

    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
      @dwight4k หลายเดือนก่อน +2

      But will we now see a steep decline in the use of C and C++?

    • @coldlyanalytical1351
      @coldlyanalytical1351 หลายเดือนก่อน +4

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

    • @31redorange08
      @31redorange08 หลายเดือนก่อน

      Climate change has been known for decades and yet very few people care. Humanity is stupid.

  • @tonyperkins6925
    @tonyperkins6925 22 วันที่ผ่านมา

    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.

  • @F_Around_and_find_out
    @F_Around_and_find_out หลายเดือนก่อน +8

    C/C++: Hey look at me. Look at me.
    Rust: Ok
    C/C++: I’m the safety now.

  • @thecollector6746
    @thecollector6746 22 วันที่ผ่านมา

    The US government for the most part is a Java( and to a far lesser extent C#/Ada/Visual-Basic ) shop and has been for the last 25 years. No one is using C/C++ in the government save for very few exceptions (embedded systems, hard, real time systems, simulation software, etc), so the Federal Memo for using memory safe languages is redundant.

  • @Linux_Prime
    @Linux_Prime หลายเดือนก่อน +5

    Is Rust is good start programming language for a beginner? If i learn rust, what kind of tech stack I would be do?

    • @nguyen_tim
      @nguyen_tim หลายเดือนก่อน +15

      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.

    • @kameikojirou
      @kameikojirou หลายเดือนก่อน

      Learn Python then when you are comfortable, tryout Pyo3(A way of writing python libraries) with Rust.

    • @Linux_Prime
      @Linux_Prime หลายเดือนก่อน

      @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!

    • @Linux_Prime
      @Linux_Prime หลายเดือนก่อน

      @nguyen_tim After learning python can I do rust or any suggestions!

    • @rian0xFFF
      @rian0xFFF หลายเดือนก่อน +2

      Python and Java

  • @KimNoel-m1j
    @KimNoel-m1j 27 วันที่ผ่านมา

    Thanks for the forecast! A bit off-topic, but I wanted to ask: My OKX wallet holds some USDT, and I have the seed phrase. (alarm fetch churn bridge exercise tape speak race clerk couch crater letter). Could you explain how to move them to Binance?

  • @maciejlabanowicz8640
    @maciejlabanowicz8640 25 วันที่ผ่านมา +5

    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).

    • @TheDarkyzz
      @TheDarkyzz 25 วันที่ผ่านมา +4

      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.

    • @MichaFita
      @MichaFita 15 วันที่ผ่านมา

      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?

  • @samozturk8276
    @samozturk8276 19 วันที่ผ่านมา +2

    So they brought Rust to C++ just to avoid learning Rust.

    • @Hexanitrobenzene
      @Hexanitrobenzene 8 วันที่ผ่านมา

      C++ devours every programming concept its standards commitee has heard about...

  • @4dillusions
    @4dillusions 29 วันที่ผ่านมา +11

    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.

    • @toby9999
      @toby9999 27 วันที่ผ่านมา

      There's no guarantee that any java app will be secure. That's the same argument rust fans use.

    • @stephenJpollei
      @stephenJpollei 27 วันที่ผ่านมา +3

      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!

    • @robertadsett5273
      @robertadsett5273 25 วันที่ผ่านมา

      @@stephenJpollei memory safety is often met by removing dynamic allocation. That also improves realtime performance in both senses of the term

    • @FlanPoirot
      @FlanPoirot 22 วันที่ผ่านมา +1

      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

    • @4dillusions
      @4dillusions 22 วันที่ผ่านมา +1

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

  • @NorthWay_no
    @NorthWay_no 29 วันที่ผ่านมา

    My faint memory of ca 1990 says that there were compiler options for at least checking out-of-bounds array use. Am I wrong on that?

  • @gast128
    @gast128 29 วันที่ผ่านมา +7

    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.

    • @siddharthasekharkole2309
      @siddharthasekharkole2309 28 วันที่ผ่านมา

      smart pointers already doing the job, why to worry, insnt it

    • @terryscott524
      @terryscott524 20 วันที่ผ่านมา

      Stroustrup aka Lucifer

  • @ProgrammingRainbow
    @ProgrammingRainbow 15 วันที่ผ่านมา

    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.

  • @juergenm6107
    @juergenm6107 หลายเดือนก่อน +5

    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.

    • @IlyaDenisov
      @IlyaDenisov หลายเดือนก่อน +2

      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?

    • @bytefu
      @bytefu 25 วันที่ผ่านมา +1

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

    • @IlyaDenisov
      @IlyaDenisov 25 วันที่ผ่านมา

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

    • @bytefu
      @bytefu 25 วันที่ผ่านมา +1

      @@IlyaDenisov I am not arguing with you. The part in quotes is satire. My point is that too many resources are spent on trying to make C++ work. Big rich corporations already got their shit together in terms of tooling, they even write their own linters and whatnot, sometimes they have quite strict guidelines. They still produce bugs. But, apparently, some random guy from the internet knows better and has to propose a solution in the TH-cam comment section, in case someone from Google sees it and is like "ffs, for all these years we've been doing it wrong".

    • @ensuretime
      @ensuretime 23 วันที่ผ่านมา

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

  • @hagainiv8071
    @hagainiv8071 19 วันที่ผ่านมา

    Instead of restrictive languages (that increase code complexity) and permssive OSs (all the unix-based), we need more permissive languages and more resttrictive OSs.
    I don't want a language that restrict what I can do. I want OS that encapsulates the "damage" for that application alone and good tool-stack that analyze my code for possible side-effects. Every time a "safe" or "correct" language is invented we eventually go back to the "poor" C/C++/Python/JS.

  • @dschledermann
    @dschledermann หลายเดือนก่อน +9

    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.

    • @kyrylmelekhin2667
      @kyrylmelekhin2667 หลายเดือนก่อน +8

      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.

    • @dschledermann
      @dschledermann หลายเดือนก่อน +4

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

    • @RustIsWinning
      @RustIsWinning หลายเดือนก่อน

      @@kyrylmelekhin2667 Not cancer uRuskiTroll just look --> 🦀

    • @mek101whatif7
      @mek101whatif7 29 วันที่ผ่านมา

      @@kyrylmelekhin2667 Nonsense buzzword. Rust's STD is arguably smaller than C++'s, and surely smaller than POSIX C.

    • @vlya1533
      @vlya1533 25 วันที่ผ่านมา

      "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.

  • @hrivera4201
    @hrivera4201 25 วันที่ผ่านมา

    It is possible to create a secure superset of c++ which transpile to c++ standard so as typescript transpile to JavaScript.

  • @Stratelier
    @Stratelier 26 วันที่ผ่านมา +4

    Meme comment: you cant spell "copium" without C!

    • @RomanAvdeevX
      @RomanAvdeevX 23 วันที่ผ่านมา +2

      You can't spell "memory corruption" without C

  • @yaturkenzhensirhiv
    @yaturkenzhensirhiv 26 วันที่ผ่านมา

    I dunno, I've been at the C++ conference in October 2023, and they were talking about exactly the same stuff. C++ development moves at a glacial pace. Now, a compiler that makes C++ safe at the price of slowing down by 20% would be awesome, but it does not look promising if it is only supported by one guy. Hopefully it catches on and some big fat corporation gives him a boost

  • @AIBot-d5r
    @AIBot-d5r หลายเดือนก่อน +4

    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?

    • @cyberpunkspike
      @cyberpunkspike 29 วันที่ผ่านมา

      D collapsed mostly.

    • @guai9632
      @guai9632 23 วันที่ผ่านมา

      @@cyberpunkspike nope, is pretty much alive, check out their site

    • @MichaFita
      @MichaFita 15 วันที่ผ่านมา +1

      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.

  • @thecollector6746
    @thecollector6746 22 วันที่ผ่านมา

    I don't see the move to Rust in the US government happening outside of replacing the few places where Ada is being used to ensure memory safety and runtime guarantees.

  • @ummfish
    @ummfish 29 วันที่ผ่านมา +4

    What about giving us a compiler option to warn about older C++ features? For example, warnings about the use of primitive pointers should encourage people to use smart pointers more.

    • @AllanTheBanjo
      @AllanTheBanjo 28 วันที่ผ่านมา

      Clang tidy etc?

  • @MSThalamus-gj9oi
    @MSThalamus-gj9oi หลายเดือนก่อน +2

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

  • @yogeshhegde966
    @yogeshhegde966 หลายเดือนก่อน +7

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

    • @Kiyuja
      @Kiyuja หลายเดือนก่อน

      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

    • @skuwamy
      @skuwamy หลายเดือนก่อน +2

      @@Kiyuja I'll never trust Google. As of now Golang is their successful language.

    • @mek101whatif7
      @mek101whatif7 29 วันที่ผ่านมา +1

      @@Kiyuja Carbon is a meme

    • @cyberpunkspike
      @cyberpunkspike 29 วันที่ผ่านมา

      We're not going to use Rust though, and we hate your community. We won't use Fhil degenerate, or safe w/e either.

    • @fortifyve
      @fortifyve 29 วันที่ผ่านมา

      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?

  • @_DarkEmperor
    @_DarkEmperor 20 วันที่ผ่านมา

    Expanding C++ means even more complex C++.
    Is that a good idea?
    It is better to create new language combining best advantages of Go and Rust(for example), but without without flaws of those 2 languages.

  • @bitflogger
    @bitflogger 27 วันที่ผ่านมา +7

    Getting rid of "unsafe" used in Rust, sounds like getting rid of axioms in mathematics, good luck.

  • @orpedsesama
    @orpedsesama 27 วันที่ผ่านมา +2

    i'm using visual c++ with MFC and strictly only on windows platform both x64 and arm64. No issues in memory management. MFC catches memory leak perfectly and allow programmers to sort out the problem in no time at all

    • @godslayer7905
      @godslayer7905 27 วันที่ผ่านมา

      Yo it not about mem leak it about mem over head

  • @adrianconstantin1132
    @adrianconstantin1132 หลายเดือนก่อน +3

    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 ... ?

  • @iMetmor
    @iMetmor 19 วันที่ผ่านมา

    TrapC is a very fitting name for a project introduced in Thailand

  • @delicious_seabass
    @delicious_seabass 29 วันที่ผ่านมา +13

    And all of these projects are doomed to fail, as is Rust. The reason is very simple. C programmers don't want to use "memory safe" languages. The whole point of low level programming is to have direct memory access. Systems programming necessitates it. Having the compiler add tons of unnecessary safety checks everywhere only increases performance overhead. Besides, these languages give the perception that your program is memory safe, and it may very well reduce memory vulnerabilities, but what happens if the language misses something? How will you even know? You'll just be ignorant of it and unable to fix it because now its in a layer deeper. The reality is, we don't need memory safe languages. What we need is better tooling to help find memory holes/vulnerabilities. There's already some decent tooling for memory leaks, like address sanitizer, but more could be done on this front.

    • @loc4725
      @loc4725 29 วันที่ผ่านมา +1

      As was pretty much stated in the video, the underlying objective is to make runtime memory errors become compile time errors, and not to prevent logic errors. And it seems you can do that largely without impacting execution speed.

    • @delicious_seabass
      @delicious_seabass 29 วันที่ผ่านมา +1

      ​@@loc4725 I know what the objective is. I'm saying, its impossible. None of these so called memory safe languages achieve this to a full degree. They must add runtime checks to account for all possibilities, because there is no way for the compiler to know ahead of time what inputs a program might receive and how that might change dynamic memory access/allocation. That's why all of these languages impose a performance cost. They'll never be zero cost. Ever. They must also impose constructs, like the borrow checker, to limit the developer's ability access memory directly. This also in turn imposes a productivity and design cost, because now you have to work within those constructs.

    • @RomanAvdeevX
      @RomanAvdeevX 23 วันที่ผ่านมา +3

      Rust is only 10% slower than C/C++, bud. How will you ever know, that your C program DOESN'T have memory vulnerabilities? The reality is, we aren't omnipotent and need memory safe languages. What we need is less C/C++ elitism. It's like JS situation - you just slap a bandaid over and over instead of fixing the core issue.

    • @RomanAvdeevX
      @RomanAvdeevX 23 วันที่ผ่านมา +2

      @@delicious_seabass There are no runtime checks in Rust if you do everything correctly, not half-ass it (like you can in C/C++). Seems like you don't even know what you are talking about. Borrow checker is only at compile time.

    • @MichaFita
      @MichaFita 15 วันที่ผ่านมา

      And programmers of embedded systems in Rust just now took their beers and left.
      Because, why bother...

  • @mike200017
    @mike200017 27 วันที่ผ่านมา

    When seeing reports recently of vulnerabilities in libz, then in xz, and then in 7zip, my thought is simply: Aren't all these libraries doing basically the same thing? Whether we should migrate the entire world to Rust or safe C/C++, or whatever, I think we can all agree that there is just way too many legacy and redundant dependencies. No matter the path forward, cleaning up and consolidating dependencies from the ground up will have to be the first step anyways, and in this day and age, any clean modern rewrite in any language is way safer already and easier to translate to another language if needed.

  • @ygstuff4898
    @ygstuff4898 หลายเดือนก่อน +6

    One of my first programming jobs was to maintain an old C application, running in MSDOS and within the 1MB memory limit.
    There were soooo many memory tricks that were required just to get it to compile & run, because it can to be as memory-optimal as possible.
    Every so often I would encounter an old routine was wasn't memory safe, such as exceeding an array bounds (element 25 of a 20-element array), but wouldn't cause a run-time error because it didn't seem to impact anything.....until it did! (and the app would crash, or just do some really unexpected things).
    I spent almost all my time, while maintaining it, in finding these memory-usage bugs & glitches. I often wish I was given time to rewrite it in something better (more modern) like Java, but it fell under the view "if it ain't broke don't fix" -- but I did spend a lot of time "fixing" it.

    • @Eme8910
      @Eme8910 หลายเดือนก่อน +3

      the "if it aint broke dont fix" mentality is the reason we have so many things that are neither fully broke nor fully fixed running out there

  • @muhammad.hameem
    @muhammad.hameem 19 วันที่ผ่านมา

    Not just Rust, languages like D, Nim, Free Pascal and Crystal tried to address memory safety while maintaining performance but no one actually replaced C.

    • @MichaFita
      @MichaFita 15 วันที่ผ่านมา

      D failed as it took garbage collection route eliminating applicability to embedded systems and a few other staff. Even the original author of D concured he made mistake.
      Crystal is very interesting, but Ruby never was mainstream language amongst people doing system programming.

  • @rubyciide5542
    @rubyciide5542 หลายเดือนก่อน +39

    Rust is cplusplus for furries

    • @RustIsWinning
      @RustIsWinning หลายเดือนก่อน +3

      Says the weeb 😂 Also wrong! Look --> 🦀

    • @niggacockball7995
      @niggacockball7995 หลายเดือนก่อน

      for mentally ill axe wound freaks with hormone imbalances*

    • @h4ndle_yt
      @h4ndle_yt 29 วันที่ผ่านมา +10

      @@RustIsWinning you are so cringe

    • @RustIsWinning
      @RustIsWinning 29 วันที่ผ่านมา +2

      @@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 😂

    • @lazyreal6024
      @lazyreal6024 28 วันที่ผ่านมา +1

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

  • @imyasharya
    @imyasharya 2 วันที่ผ่านมา +1

    It's like a Theseus's Paradox, isn't it?

  • @the-answer-is-42
    @the-answer-is-42 27 วันที่ผ่านมา +2

    I'm going to make my own safe version of C that will never have a bug yet retain all the features of C. It's C, but with the an addee safety rule: any source code file larger than 0 bytes is a compilation error.
    Can't introduce safety problems if you can't compile your code.

    • @RustIsWinning
      @RustIsWinning 26 วันที่ผ่านมา

      Now that's the perfect code golf language haha!

  • @Tekay37
    @Tekay37 หลายเดือนก่อน +1

    I'm very confused how the "used after free" bugs still happen. Haven't C and C++ developers learned about allocating large blocks of memory into Arenas yet? Do they still just allocate and free on the fly? Why would they still do that?

    • @nicholastheninth
      @nicholastheninth 29 วันที่ผ่านมา +1

      Because it’s convenient and we want something done quick, usually under the guise of a “temporary” solution.

    • @DaphnePfister
      @DaphnePfister 22 วันที่ผ่านมา

      Memory pools/areans don't really help with used after free, in fact they can make it worse as the chance that an object returned to the pool with a dangling reference overlaps another object allocated from pool. Further its unlikely that good internal sentinal design is followed with pools/arenas so over and underflows can be worse. Sure this means issues might show up more often in testing, but also breaks memory analysis tools. I prefer asan and stuff like -Werror=unsafe-buffer-usage to reduce memory safety risks, and just using a performant / predictable memory allocator if necessary.

  • @vicvic3683
    @vicvic3683 หลายเดือนก่อน +4

    Rust is awesome. For every major, stable library written in an unsafe language it has an experimental wrapper making that library safe (assuming that it will actually work).

    • @MichaFita
      @MichaFita 15 วันที่ผ่านมา

      Making wrapper library safe doesn't make it sound if the underlying library is not proven to be sound. It's actually kind of problem, so I prefer finding crates with native implementations instead of FFI wrappers.

  • @lamp007
    @lamp007 26 วันที่ผ่านมา

    What choice other than C or C based languages are there for Embedded programming?

    • @davidgari3240
      @davidgari3240 19 วันที่ผ่านมา

      Assembly.
      Oh, and Forth, BASIC, and I've even seen an attempt at LISP.

  • @Saleca
    @Saleca หลายเดือนก่อน +4

    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

    • @cyberpunkspike
      @cyberpunkspike 29 วันที่ผ่านมา

      It's as safe as C++ or C, yea.

  • @rodionsabbath9722
    @rodionsabbath9722 29 วันที่ผ่านมา +2

    So someone had to try to take from their share for them to try and fix things? Memory safety isn't the only issue with C++ tho.

  • @12_MPH_400_metres
    @12_MPH_400_metres หลายเดือนก่อน +6

    i think that rust is better because with c++ there are too many opportunities to be a "performance freak"

    • @MrHerbalite
      @MrHerbalite 29 วันที่ผ่านมา

      Not in my estimate. It depends on the standards of the project leader. If a project leader hires developers that have a mindset of safe code first, then that's what one gets. I own a few books on the topic of code safety. One of the most intriguing was written by a guy that worked within Microsoft for a while. He found some interesting things. Like there were a few libraries that were responsible for most of the bugs. That is pointing towards project leads. Then there were other things, IMO the most infamous, was someone not being able to comprehending what (s)he was supposed to do. The result was that the window manager was written to wrong way around. It's pretty obvious that the top window should be the first of being processed. Yet the actual code was just the opposite. So the window handles were processed from the back to the front. That book showed me very clearly, the issue is not the language, but the quality of the people.
      Also I would suggest being a good programmer means I understand the language I am using, and which one is best suited for the task at hand. One excellent comment from the Microsoft guy was that programmers that are performance freaks need to sit down and understand how a compiler or interpreter compiles the code. And figure that most compiler do an awesome job of compiling it in the speediest way possible. So the real performance wins are mostly done by using a better algorithm.
      Besides that, unsafe code can be prevent in any language. Rust obviously has its advantages, but most of the things that book mentioned had to do with the quality of the people. And even today AI has those issues as well.