Hacker News Reader

Comment by sudeepj | Hacker News Reader

From an ecosystem p.o.v Rust has a big advantage. The strictness is built into the compiler and the entire ecosystem is subjected to same high standards. One has to fix the errors.

The same strictness in C++ can arguably be availed by using static linters. This has 3 problems:

1. Static linter errors are inherently optional to fix. One has to have some CI rules to block check-ins if linter flags something

2. Your project might follow best practices but not your dependencies.

3. Static linters are not foolproof (last I checked back 4-5 years)

View on HN

As a Rust user, I'm afraid I disagree with these following points:

> The strictness is built into the compiler and the entire ecosystem is subjected to same high standards.

> 2. Your project might follow best practices but not your dependencies.

The crates ecosystem is the weakest part of Rust and it is not always subjected to the 'same' high standards, despite the 'strictness' of the compiler.

A simple command line app or library (even worse) can depend on hundreds of other third-party libraries and cargo reminds others of the same ills of npm to some extent as developers throw in unnecessary libraries in your project. Point (2) can be still said about Rust given that the developer can still abuse unsafe{} or still have dangerous .unwraps() written by the developer. Just look at the immense scrutiny that actix-web was under because of this.

Just the fact that a large amount of scrutiny is placed on crates using unsafe in the ecosystem is a huge step up from C/C++. Compare to how critical openssl was and how few people were actually looking at the code before heartbleed.

It's not a big step up when the software was written by a single person who did it to learn rust and doesn't understand the problem domain, over a weekend. Software doesn't need to use unsafe blocks to have dangerous bugs and vulnerabilities.

I would take openssl over most (though not all, for sure) rust cryptographic code. OpenSSL's bugs have not been RCEs for the most part, and many of them could happily exist in rust. The cult like perspective that language choice can make software automatically safe in the absence of things like domain expertise or long term production usage increases risk even where the language itself theoretically reduces them. ( See also: https://en.wikipedia.org/wiki/Risk_compensation )

Especially with the deeply nested dependencies the rust ecosystem seems to me like a ticking time bomb for security disasters. The same bad practices exist in NPM and have already produced a number of high profile incidents, as it repeats in rust there really won't be any excuse but to admit that it resulted from an excess of hubris.

Rust has a higher floor set by the compiler, which still might not be up to your standards. That doesn’t mean that either C++ or Rust can’t have dependencies all over the quality spectrum, but it does mean that there are certain problems that Rust crates can’t have.

And npm style of libraries, which does very little to improve quality versus C++.

Specifically how does it make it worse than any other library package manager?

Having a thin standard library, which makes reaching out to third party libraries a must have in any project, many of each far from reaching 1.0, and not necessarly available in all deployment targets of the compiler.

There is stuff in ISO C++ standard library that requires third party libraries in Rust, yet another thing to certify in security sensitive domains.

Why is this downvoted?

Being politically incorrect to web developers?

Reply on news.ycombinator.com