4 ms·

If you don't have good tests with coverage information then your Python and Rust code is buggy too. If you want "as low of defects as I can get from the compile

If you don't have good tests with coverage information then your Python and Rust code is buggy too. If you want "as low of defects as I can get from the compiler alone" then your options are things like Haskell and theory-laden TypeScript. If you have low-defect appropriate test coverage, ASAN approaches linear typing for the class of bugs that the borrow checker catches. Python and Rust have their sweet spots just like C++ does, I use all three. The meme that either is a blanket replacement for all of C++'s assigned duties is both sikly by observation and not demonstrated by enthusiastic adoption in C/C++ in the highest-demand regimes: AI inference, HFT, extreme CERN-scale physics, your web browser. Python is better for fast prototyping and other iteration critical work, Rust is unmatched for "zero defect target with close to zero cost abstractions" (it was designed for writing a web browser and in that wildly demanding donain I can think of nothing better). C++ excels in extreme machine economics scenarios where you want a bit more flexibility in your memory management and a bit more license to overrule the compiler and a trivial FFI story. Zig to me looks likely to succeed it in this role someday. All have their place, software engineers in these domains should know all of them well, and any "one true language" crap is zealoty or cynical marketing or both.

galangalalgol 1y ago
A coworker found a stack use after free in production that no amount of linters or tidyers caught. It only actually happened in the release build, and asan caught it, but only when we pushed to 100% branch coverage instead of just line coverage. Rust makes coverage much easier to get with fewer tests due to it's type system. It seems really clear to me that rust will be the c++ successor. If you need that extra flexibility, you use unsafe. That still feels less foot gun ridden than c++. The slow adoption of rust is because c++ interoperability is bad and people are stuck maintaining c++ behemoths. Green field rust adoption in c++ domains is much higher. Zig is more of a c replacement, but as much as I like it, I don't think that will happen. C is like a standardized ir. But when sonos wanted to make an arm cpu only onnx inference engine for instance, they made it in rust (tract). When c++ developers get to choose rust, we often do. I can throw earlier career c++ devs with modern c++ experience directly into a rust codebase and have them be immediately productive, but also not worry about them doing horrible things.
- benreesman 1y ago
  Yeah, you and I are both entitled to our guesses about Rust and Zig respectively in the future. Both have serious production projects (bun and TigerBeetle are best-in-class to head off any "hobby project" stuff), neither is making serious inroads to the domains I'm talking about: it doesn't get any hotter than the new CUTLASS stuff, and that's greenfield modern C++ with a standardization regime (mdarray) with 100% industry voting as a bloc for "it's still modern C++ at the frontier". HFT shops have at least some Rust at least auditioning, but the reqs are still C++, and they rewrite anything that alpha decays out. When it's for all the marbles today? It's C++. The future is an open question, but a lot of us are pushing hard for C++.

galangalalgol 1y ago

A coworker found a stack use after free in production that no amount of linters or tidyers caught. It only actually happened in the release build, and asan caught it, but only when we pushed to 100% branch coverage instead of just line coverage. Rust makes coverage much easier to get with fewer tests due to it's type system. It seems really clear to me that rust will be the c++ successor. If you need that extra flexibility, you use unsafe. That still feels less foot gun ridden than c++. The slow adoption of rust is because c++ interoperability is bad and people are stuck maintaining c++ behemoths. Green field rust adoption in c++ domains is much higher. Zig is more of a c replacement, but as much as I like it, I don't think that will happen. C is like a standardized ir. But when sonos wanted to make an arm cpu only onnx inference engine for instance, they made it in rust (tract). When c++ developers get to choose rust, we often do. I can throw earlier career c++ devs with modern c++ experience directly into a rust codebase and have them be immediately productive, but also not worry about them doing horrible things.

benreesman 1y ago
Yeah, you and I are both entitled to our guesses about Rust and Zig respectively in the future. Both have serious production projects (bun and TigerBeetle are best-in-class to head off any "hobby project" stuff), neither is making serious inroads to the domains I'm talking about: it doesn't get any hotter than the new CUTLASS stuff, and that's greenfield modern C++ with a standardization regime (mdarray) with 100% industry voting as a bloc for "it's still modern C++ at the frontier". HFT shops have at least some Rust at least auditioning, but the reqs are still C++, and they rewrite anything that alpha decays out. When it's for all the marbles today? It's C++. The future is an open question, but a lot of us are pushing hard for C++.