Hacker News Reader

Comment by antonvs | Hacker News Reader

Much of the drive to rewrite software in Rust is a reaction to the decades-long dependence on C and C++. Many people out there sit in the burning room like the dog in that meme, saying "this is fine". Most of them don't have to deal at all directly with the consequences involved.

Rust is the first language for a long time with a chance at improving this situation. A lot of the pushback against evangelism is from people who simply want to keep the status quo, because it's what they know. They have no concept of the systemic consequences.

I'd rather see over-the-top evangelism than the lack of it, because the latter implies that things aren't going to change very fast.

View on HN

> I'd rather see over-the-top evangelism than the lack of it, because the latter implies that things aren't going to change very fast.

No new technology should be an excuse to engage in unprofessional conduct.

When you propose changes to software, you listen to feedback, provide analysis of the benefits and detriments, and make an informed decision.

Rust isn't special, and isn't a pass to cause endless heartache for end users and developers because your code is in a "safer" language.

New rust code should be held to the same standards as new C and C++ code that causes breakage.

Evangelism isn't useful here, let the tool speak for itself.

If you were right, then people should not be using Rust or C/C++. They should be using SPARK/Ada. The SPARK programming language, a subset of Ada, was used for the development of safety-critical software in the Eurofighter Typhoon, a British and European fighter jet. The software for mission computers and other systems was developed by BAE Systems using the GNAT Pro environment from AdaCore, which supports both Ada and SPARK. It's not just choosing the PL, but the whole environment including the managers.

This is an interesting read on software projects and failure: https://spectrum.ieee.org/it-management-software-failures

Nvidia evaluated Rust and then chose SPARK/Ada for root of trust for GPU market segmentation licensing, which protects 50% profit margin and $4T market cap.

"Nvidia Security Team: “What if we just stopped using C?”, 170 comments (2022), https://news.ycombinator.com/item?id=42998383

> If you were right, then people should not be using Rust or C/C++. They should be using SPARK/Ada.

Not all code needs that level of assurance. But almost all code can benefit from better memory safety than C or C++ can reliably provide.

Re what people "should" be using, that's why I chose my words carefully and wrote, "Rust is the first language for a long time with a chance at improving this situation."

Part of the chance I'm referring to is the widespread industry interest. Despite the reaction of curmudgeons on HN, all the hype around Rust is a good thing for wider adoption.

We're always going to have people resistant to change. They're always going to use any excuse to complain, including "too much hype!" It's meaningless noise.

You can’t change things faster than persuading the people that maintain the things. Over-the-top evangelism doesn’t work well for persuasion.

That was probably a mischaracterization on my part. I wouldn't consider rewriting almost everything useful that's currently in C or C++ to be over the top. That would be a net good.

Posts that say "I rewrote X in Rust!" shouldn't actually be controversial. Every time you see one, you should think to yourself wow, the software world is moving towards being more stable and reliable, that's great!

But it is nonsense. Every time some rewrote something (in Rust or anything else), I instead worry about what breaks again, what important feature is lost for the next decade, how much working knowledge is lost, what muscle memory is now useless, what documentation is outdated, etc.

I also doubt Rust brings as many advantages in terms of stability that people claim. The C code I rely on in my daily work basically never fails (e.g. I can't remember "vim" ever crashing on me in the last 30 years I use it). That this is all rotten code C that needs to be written is just nonsense. IMHO it would far more useful to invest in proper maintenance and incremental improvements.

You want the computing infrastructure to remain essentially as it was in the 1970s. I don't.

Me neither, I just do not want to make steps backwards because people rewriting stuff for stupid reasons. But your argument is just the old "you do not want to adapt" shaming attempt which I think has no intellectual substance anyway.

Regarding VIM - it's not as risky as something that's exposed over a network, but it's had plenty of CVEs, and skimming them shows many if not most are related to memory safety. See:

https://www.cvedetails.com/vulnerability-list/vendor_id-8218...

On the other hand, the presence of an alternative is the persuasion.

It's very easy to justify for yourself why you aren't addressing the hard problems in your codebase. Combine that with a captive audience, and you end up with everyone running the same steaming heap of technical debt and being unhappy about it.

But the second an alternative starts to get off the ground there's suddenly a reason to address those big issues: people are leaving, and it is clear that complacency is no longer an option. Either evolve, or accept that you'll perish.

Except in many of such cases, like here in apt, any compiled language with GC/RC would do.

This is the kind of UNIX stuff that we would even write in Perl or Tcl back in the day.

Sometimes good things are ruined by people around. I think Rust is fine, although I doubt its constraints are universally true and sensible in all scenarios.

This is also not an endorsement of C/C++.

Reply on news.ycombinator.com