Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's time to halt starting any new projects in C/C++

twitter.com

Post reply on HN
Print view View original

71–80 of 929 posts

Re: It's time to halt starting any new projects in C/C++

#71

Post by dleslie »

woodruffw wrote: post #59
tejohnso wrote: post #54

> For the sake of security and reliability. I just read a few C++ vs Rust comparisons online yesterday and didn't see anything about a significant difference in security or reliability. Mind you the articles weren't very technical. How is Rust so much more secure and reliable than *modern* C++?

The primary defining quality of Rust (in a security context) is spatial and temporal memory safety: if you're an ordinary user of Rust, you cannot write code that produces memory corruption. Modern C++ is really nice (I write mostly C++17 and later for work), and does a great job of obsoleting bug-prone patterns from earlier versions of the language. But it's still very easy to introduce memory corruption (of either…

But you can use code that introduces memory corruption. Plenty of crates make use of unsafe blocks.

Re: It's time to halt starting any new projects in C/C++

#72

Post by jcelerier »

woodruffw wrote: post #64
jcelerier wrote: post #62

Earlier quoted context omitted.

C++ has Schrödinger's ABI: some will say that it has a too stable ABI and others will say that its ABI is not stable at all. Which one is it ? https://stackoverflow.com/questions/67839008/please-explain-... Can one link two rust static libraries communicating with actual rust symbols (not just C ones), one built with gcc-rs (assuming that this is possible yet), the other built with rustc with its default x86_64-pc-wi…

Well, it's a multiparadigm language, so both :-) I'm being facetious, but it really is both: it's too unstable in ways that are bad, and also too stable in other ways that are bad. Edit: since you updated your comment: Rust is not in the same position as C++. C++ has an unstable ABI that it cannot break; Rust has an unstable ABI that it can (and regularly does break). Rust works around this with developer tooling; C+…

> Rust works around this with developer tooling;

how does that work for companies that may use proprietary rust libraries? the proprietary lib authors won't recompile their shit for you just because you upgraded to the latest rustc

Re: It's time to halt starting any new projects in C/C++

#74

Post by dleslie »

jimbob45 wrote: post #50

I don’t feel that his opinion is all-encompassing. If Rust is being used in the name of security and reliability, then C/C++ should remain king of game development, where those two aren’t as important.

C# is the new King of game development.

Re: It's time to halt starting any new projects in C/C++

#75

Post by woodruffw »

throwaway2037 wrote: post #67
woodruffw wrote: post #59

Earlier quoted context omitted.

The primary defining quality of Rust (in a security context) is spatial and temporal memory safety: if you're an ordinary user of Rust, you cannot write code that produces memory corruption. Modern C++ is really nice (I write mostly C++17 and later for work), and does a great job of obsoleting bug-prone patterns from earlier versions of the language. But it's still very easy to introduce memory corruption (of either…

I would call myself an average C++ programmer. Starting with move semantics in C++11 (very cool!), I found myself frequently making bugs by re-using an "already moved" container (like a vector). I couldn't find any simple way to avoid that mistake. And, from my tooling, it was a hard problem to debug, as are double frees. Do you have any advice to avoid re-using "already moved" containers?

Nothing great, unfortunately -- C++'s decision to leave moved-from values in a "valid but unspecified" state makes a lot of sense from a memory corruption perspective, but has caused plenty of logic bugs in my codebases as well.

The best thing I've used so far is clang-tidy (specifically the "use-after-moved"[1] check). It catches some stuff though, which is better than nothing.

[1]: https://clang.llvm.org/extra/clang-tidy/checks/bugprone/use-...

Re: It's time to halt starting any new projects in C/C++

#76

Post by ReactiveJelly »

Someone else downthread: "young developers can pick up Rust quite fast, and that makes it vastly easier than trying to find talented C/C++ developers."

I hope so. I have a hypothesis that the big-O for language success is "How easily can new programmers learn it?" Nothing else matter. JavaScript was slow, but everyone learned it, so it got fast. Python still had bad tooling, but everyone learned it, so it got better. And C got popular in the first place cause it was easier than assembly.

I wanna ask my managers if we could try hiring Rust devs. I don't like hiring people fresh out of college, but I can't manifest more money to hire experienced C++ devs. If the pool of good-enough-Rust devs is growing faster, and maybe already bigger than the good-enough-C++ pool, why am we interviewing people who don't even know what they don't know about C++?

Re: It's time to halt starting any new projects in C/C++

#77

Post by synergy20 »

absolutelynobo wrote: post #34
synergy20 wrote: post #25

I'm waiting for Rust to support both static and dynamical link equally well. static link produces binaries too large for my embedded boards when stdlib is needed. dynamic link looks like a second class citizen to me in Rust. Is there some hope?

you can use no_std when available. not sure how dynamic linking would help when your boards don’t have enough (flash ?) space… the linked library still needs to go somewhere? how small of a flash medium are you using?

yes no_std for kernel or boot code or MCU boards, that's what rust-embedded is doing and I think it's fine.

many embedded boards typically have 16~64MB Flash running Linux with musl, one rust binary statically linked can easily exceeding 10MB. multi-entry is hard to manage when you have quite a few unrelated tasks, so yes I really need a true shared lib based rust for the mid-range embedded boards, which are, quite a huge number.

Re: It's time to halt starting any new projects in C/C++

#78

Post by dodobirdlord »

dleslie wrote: post #71
woodruffw wrote: post #59

Earlier quoted context omitted.

The primary defining quality of Rust (in a security context) is spatial and temporal memory safety: if you're an ordinary user of Rust, you cannot write code that produces memory corruption. Modern C++ is really nice (I write mostly C++17 and later for work), and does a great job of obsoleting bug-prone patterns from earlier versions of the language. But it's still very easy to introduce memory corruption (of either…

But you can use code that introduces memory corruption. Plenty of crates make use of unsafe blocks.

Unnecessary use of unsafe blocks is stylistically discouraged in Rust, so there's a lot less code that has the potential to harbor a memory safety bug, which makes bugs both less likely to exist and easier to spot when doing a code audit before introducing a dependency on third-party code.

Re: It's time to halt starting any new projects in C/C++

#79

Post by imron »

tejohnso wrote: post #54

> For the sake of security and reliability. I just read a few C++ vs Rust comparisons online yesterday and didn't see anything about a significant difference in security or reliability. Mind you the articles weren't very technical. How is Rust so much more secure and reliable than *modern* C++?

> How is Rust so much more secure and reliable than *modern* C++?

Rust catches things like use-after-free at compile time. *modern* C++ still lets things slip through e.g.

    #include 
    #include 
    #include 

    int main() {
      std::string s = "Hellooooooooooooooo ";
      std::string_view sv = s + "World\n";
      std::cout

Re: It's time to halt starting any new projects in C/C++

#80

Post by woodruffw »

dleslie wrote: post #71
woodruffw wrote: post #59

Earlier quoted context omitted.

The primary defining quality of Rust (in a security context) is spatial and temporal memory safety: if you're an ordinary user of Rust, you cannot write code that produces memory corruption. Modern C++ is really nice (I write mostly C++17 and later for work), and does a great job of obsoleting bug-prone patterns from earlier versions of the language. But it's still very easy to introduce memory corruption (of either…

But you can use code that introduces memory corruption. Plenty of crates make use of unsafe blocks.

Of course: you can call a C function that's unsound, and that unsoundness can make your surrounding Rust program unsound.

This doesn't change the surrounding point however, which is Rust's philosophy of safeness by construction: if a particular piece of code is safe, then no safe (i.e., invariant-preserving) use of it can be unsafe. That alone makes Rust's security properties strictly better than those of C++, where even the modern safer paradigms can violate underlying invariants.

Post reply on HN