17 ms·
The ROI on rewriting existing code may be questionable, but the long-term ROI on writing new projects in safe languages seems unassailable. Choosing C or C++ fo
by roca 5y ago
The ROI on rewriting existing code may be questionable, but the long-term ROI on writing new projects in safe languages seems unassailable. Choosing C or C++ for new infrastructure projects is madness at this point.
- AceJohnny2 5y agoIt's still way easier to find experienced C++ coders than Rust coders. :\
- paavohtl 5y agoAn experienced C++ programmer can learn Rust quite easily. The hard part (ownership & lifetimes) is what experienced C++ developers should already know by heart, but the primary difference is that the compiler enforces the same rules.
- _0w8t 5y agoIt is hard to write in Rust style in C++ since many libraries are hostile to it. Iterators require at least two mutable references or mixing mutable and non-mutable references. Move-only types require a lot of boiler plate and accidental usage of moved thing is not detected by the compiler. Using std::variant feels like a trolling from the language designers who refused to provide proper type-safe unions into the language.
- eru 5y ago> Using std::variant feels like a trolling from the language designers who refused to provide proper type-safe unions into the language. And, alas, deliberate trolling would be preferable to reality. Deliberate trolling would indicate a conscious design. C++ accumulated cruft over the years in what looks like brownian motion in retrospect, and almost never shed any.
- GhettoComputers 5y agoDepends on what its for. I wouldn't mind any unsafe non network connected device, if they really want to hack my programmable thermometer with no network access, or my wired keyboard, they can be my guest! If my server is on intranet, I don't have any fears either, without memory safety hacks can happen, but spectre and meltdown haven't been seen in the wild. For OS and browsers though, I agree completely if infrastructure as long as its not always connected to the open internet, it doesn't seem to be much of a threat, and even though I don't care about memory safety, the performance of rust tools impresses me! I wish people talked about performance of rust more than its memory safety, I don't care as much about that, but everything being faster? Who wouldn't want that? I made this thread a few days ago. https://news.ycombinator.com/item?id=29456115 https://news.ycombinator.com/item?id=29456115
- eru 5y agoI remember quite a few posts on the Firefox blog about how Rust allowed them to write faster programs. See eg https://hacks.mozilla.org/2019/02/rewriting-a-browser-component-in-rust/ https://hacks.mozilla.org/2019/02/rewriting-a-browser-compon...
- GhettoComputers 5y agoThey could write better performing programs, as well as do it faster than C, the thread I linked to has GNU coreutils in rust for instance, it has excellent performance and every CLI tool I used is very fast, much faster. This is another example if you are interested. https://github.com/BurntSushi/ripgrep https://github.com/BurntSushi/ripgrep
- roca 5y agoThe thing is, code tends to be reused across projects. If you write a library or a utility program and it's full of holes, that's only OK if you're sure it will always be used in a "safe" context with no untrusted input. Who really wants to commit to that?
- eru 5y ago
- dymk 5y agoRust just kinda sucks to develop in, and the library support isn’t anywhere near C/C++
- ksec 5y ago>Choosing C or C++ for new infrastructure projects is "madness" at this point. If Spartans were alive they would be using C or C++.
- newaccount74 5y agoMy experience writing in Swift (a mostly memory safe language) is that it's nice for high level stuff, but as soon as you have to interface with low level or legacy code it quickly becomes unmanageable. What would be two or three lines of C code quickly turns into 10 or more lines of very hard to understand Swift code full of types named UnsafeRawBufferPointer or similar and it's doubtful that thing is in any way safer than a char* with a manual range check.