Hacker News new | past | comments | ask | show | jobs | submit login

> The original poster claimed that Rust can save money by letting managers hire junior devs to replace senior C++ developers.

This is not at all what I said, nor meant. I never said anything about the hiring market, but merely stated a personal observation why I think Senior C++ devs often dislike Rust.




You were wrong about that, too:

Senior C++ developers are not impressed with Rust because it doesn't solve any problem they have. Switching to Rust would make them markedly less productive, with no corresponding benefit. The drain comes from slow compilation and from excess design overhead, the need to distort a simpler architecture to satisfy the borrow checker.

Put simply, the extra work to satisfy the borrow checker prevents errors they do not make.

This contradicts Rust propaganda, where a few CVE numbers are cited over and over, echo-chamber style. What these citations never mention is that they are for bugs in mostly very old code. We just don't need to write code that way anymore. It is not just error-prone, it is more work, so there is simply no temptation to write it that way.

I do hear of programmers who have elected to stop learning, and (proudly!) admit continuing to write C++98 or even "C-like C++". We used to say "you can write FORTRAN in any language"; there is no eliminating bad programmers, but plenty of reasons to avoid their product. What conclusions can we make about Rust from its worst adherents?


> What these citations never mention is that they are for bugs in mostly very old code.

It is unavoidably true that grave security holes get found only in existing code and not hypothetical future code written with a later language revision and whatever new features will definitely avoid those "errors they do not make". That's time's arrow for you.

Can you name a few of these "Senior C++ developers" and point us to, say, a few years of their work?

Is there a specific vintage of C++ where you feel like, at last, unlike C++ 98 you "don't need to write code that way" and so Senior C++ developers won't make these errors? C++ 11 maybe?


> Put simply, the extra work to satisfy the borrow checker prevents errors they do not make.

> This contradicts Rust propaganda, where a few CVE numbers are cited over and over, echo-chamber style. What these citations never mention is that they are for bugs in mostly very old code.

Empirically this is not true. https://twitter.com/LazyFishBarrel/ is not citing "a few CVE numbers over and over"; for example, in browsers, new code is disproportionately responsible for vulnerabilities. I know most of the people at the big tech companies doing the research into where the security problems in major C++ software come from; they're not making the results up.


When I look into these CVEs and see "use after free", I know immediately it is not a problem in modern code.


> it doesn't solve any problem they have

you mean a problem blithely ignored until the software becomes important enough to attack, at which point, it's too late to rewrite the "very old" code? https://googleprojectzero.blogspot.com/2022/01/zooming-in-on...

> errors they do not make.

bullshit. a quick look at oss-fuzz on c++ projects, many of them in modern c++, will show that they are teeming with memory unsafety.

> there is no eliminating bad programmers, but plenty of reasons to avoid their product.

on an unrelated note, what product are you responsible for, so i can avoid it?


There is no possibility you could ever afford it.


the world can't afford new code written in a blatantly memory-unsafe language




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: