6 ms·
Between C++ and Rust, my bet would be that you decide Rust. But—also learn Zig in addition to Rust. Having seen first-hand how so many threat vectors these da
by _vvhw 4y ago
Between C++ and Rust, my bet would be that you decide Rust.
But—also learn Zig in addition to Rust.
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.
For example, this comes through in Zig's extreme simplicity and explicitness, and also how Zig enables checked arithmetic by default for safe builds. 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. attacks like OpenSSL's Heartbleed, which are often remotely accessible and easier to pull off than a UAF.
In fact, no language is 100% memory safe, i.e. able to prevent a memory buffer bleed, because these are logic errors with respect to the protocol. However, explicit control flow and checked arithmetic do help to close semantic gaps and minimize ambiguity, which is what good security comes down to.
Of course, Zig only offers spatial memory safety, and not temporal memory safety like Rust. So Zig is more memory safe than C, and less memory safe than Rust or JavaScript. Nevertheless, Zig is safer than Rust when it comes to being able to handle memory allocation failure.
Again, Rust's borrow checker is also valuable for concurrency safety, i.e. 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.
Zig is something you can pick up in a week, with state of the art tooling, and fantastic C-ABI interop for libraries.
So... learn both!
- b20000 4y agosee? learn Rust, but yeah, also learn Zig, or whatever new flavor of the day. No thanks. I don't want my tool set to change every year. I got out of web dev exactly for that reason. I'll stick to my C++ or C, thanks.
- klysm 4y agoAnd your software will continue to have memory safety issues.
- b20000 4y agomemory safety issues are the result of poor software engineering.
- klysm 4y agoHistory has demonstrated over and over and over again that c/c++ code above a certain complexity threshold (which is fairly low), _will_ have memory safety issues. It doesn't matter how good you are at engineering.
- ameixaseca 4y agoFYI, the fact that you can do poor software engineering in safe Rust (or any memory-safe language) and still do not have memory safety issues completely disproves your statement.
- mlindner 4y agoI'm confused when people preach Zig and then safety in the same sentence. Zig has basically all the same problems that C++ has with a few extra bells and whistles. There are perfectly good reasons to like Zig, but it being "safe" is not one of them. > For example, this comes through in little things like Zig's extreme simplicity and explicitness "Simplicity" does not mean safety. In fact simplicity means you can't describe hard problems easily without being overly verbose, which means more code and more attack surfaces. Problems are what can be simple or complex. If your language advertises "simplicity" it just means it can't solve complex problems in straight forward ways. Zig is just repeating the mistakes of C++ as well as all the mistakes of Go. > 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. attacks like OpenSSL's Heartbleed, which are often remotely accessible and easier to pull off than a UAF. Zig does exactly what Rust does in this case. > In fact, no language is 100% memory safe, i.e. able to prevent a memory buffer bleed, because these are logic errors with respect to the file or protocol format. What are you trying to argue here? Buffer bleeds can't happen in safe rust. > The borrow checker is obviously great 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. Syncronization is a problem in any kind of multitasking. Whether that happens inside or outside the language is the only question. The OS can have all the same problems your code can have. https://mobile.twitter.com/axboe/status/1505335772706091011 https://mobile.twitter.com/axboe/status/1505335772706091011 Also io_uring assumes you're only ever writing for Linux. > Nevertheless, Zig is safer than Rust when it comes to checked arithmetic or being able to handle memory allocation failure. This is simply incorrect. Most of the problem with unchecked overflow is for buffer overflows, which are fully caught. Rust gives options to handle memory allocation failure if you want to handle it. Generally though for most applications simply crashing is completely fine.
- sk1pper 4y agoCounterpoint: Zig is unstable (as in, <1.0 release) and the docs are still pretty lacking. You’ll find yourself reading source code if you want to do anything nontrivial pretty much. Stick to C++ or Rust, which I won’t weigh in on here. But both are much more mature.
- jstx1 4y agoAlso there's no job market for it.
- infamouscow 4y agoI don't think Zig is recommended for production use. It's not at 1.0.0 yet. That said, there are at least three stealth-mode SaaS companies I know of betting on Zig for their performance sensitive / low-latency software. Where I work, we're tracking Zig's nightly build and follow/contribute to Zig progress and stability roadmap. Zig hits a sweet spot between C and C++. It feels really nice to work in -- in a way that many people describe Go. I think Zig is a very attractive option for allocation sensitive programs like games, audio, or purpose-built data stores. Give it a look and decide for yourself.
- pjmlp 4y agoD had a couple of such SaaS and doesn't seem to have helped much in the end.