> or people who haven't worked in security, integer overflow and wraparound may seem like a small thing, but they increase the probability of buffer bleeds, i.e. Zig is just repeating the mistakes of C++ as well as all the mistakes of Go. If your language advertises "simplicity" it just means it can't solve complex problems in straight forward ways. Problems are what can be simple or complex. In fact simplicity means you can't describe hard problems easily without being overly verbose, which means more code and more attack surfaces. > For example, this comes through in little things like Zig's extreme simplicity and explicitness There are perfectly good reasons to like Zig, but it being "safe" is not one of them. Zig has basically all the same problems that C++ has with a few extra bells and whistles. I'm confused when people preach Zig and then safety in the same sentence. Zig is something you can pick up in a week, with state of the art tooling, and fantastic C-ABI interop for libraries. for multithreaded systems, but if you're using io_uring for fast I/O, then multithreading is less of the necessary evil that it used to be a few years ago. Nevertheless, Zig is safer than Rust when it comes to being able to handle memory allocation failure.Īgain, Rust's borrow checker is also valuable for concurrency safety, i.e. So Zig is more memory safe than C, and less memory safe than Rust or JavaScript. Of course, Zig only offers spatial memory safety, and not temporal memory safety like Rust. However, explicit control flow and checked arithmetic do help to close semantic gaps and minimize ambiguity, which is what good security comes down to. able to prevent a memory buffer bleed, because these are logic errors with respect to the protocol. In fact, no language is 100% memory safe, i.e. attacks like OpenSSL's Heartbleed, which are often remotely accessible and easier to pull off than a UAF. For people who haven't worked in security, integer overflow and wraparound may seem like small things, but they increase the probability of exploits such as buffer bleeds, i.e. Having seen first-hand how so many threat vectors these days are now supply chain attacks, having reported CVEs and earned P1 bounties in memory safe languages, and having worked on static analysis systems to detect zero day exploits-I'm also impressed by Zig's overall approach towards safety, as being more than only memory safety.įor example, this comes through in Zig's extreme simplicity and explicitness, and also how Zig enables checked arithmetic by default for safe builds. If I did't know either Rust or C++ in 2022 then I would focus my efforts on learning Rust.īetween C++ and Rust, my bet would be that you decide Rust. C++ is the past and the lion's share of the present but Rust is gaining on the present and is the future. You can see we're shifting from C++ to Rust. Will C++ be around in 20-30 years? Absolutely! But so is Cobol, and would you start a major project today using Cobol? No. But I'm also practical and I recognize its days are numbered. The simplicity makes some things unduly burdensome to implement.ĭon't get me wrong - I've programmed in C++ for decades and I like it, warts and all. That's just history - C++ reflects our best thinking from the 70's and the modern type systems started emerging in the 80's. They were both touted to be better versions of C++ (which was true in the application development space where a GC could be tolerated)įinally, the C++ type system is barely a type system as we understand them today. Just remember, Java and later C# were created to address these issues with C++. Never mind the inheritance patterns leading to lots of confusion. There were very few libraries outside of the standard libraries.Ĭ++ has an object model making it difficult to use and extend objects from different code bases/libraries. It worked well for the time since there were very few external dependencies, almost the entirety of the codebase was hand-built by the entity creating the software. C had incredibly simplistic dependency management. For starters, C++ is 40 years old at this point and embodies software engineering practices from the late 70's to early 80's (for you young folks, structured programming was the new hotness in the 70's!) C++ was also designed to take advantage of C's tooling, or lack thereof. But if I were a young programmer in 2022 and looking at learning either C++ or Rust I'd choose Rust in a heartbeat. I used to be able to cite the Annotated Reference Manual (ARM) by chapter and verse. I remember when Stroustrup's C++ came out in 1986.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |