Hacker News Reader

Comment by mike_hearn | Hacker News Reader

Worth noting that the JVM ecosystem doesn't have this issue because there is no notion of installing dependencies, and the package managers are just downloaders with nothing else. No build.rs equivalent.

To solve the problem of native/C dependencies, they just bundle pre-compiled libraries as data files.

Rust could do the same thing.

View on HN

But then that shifts the issue. You've now got an opaque binary blob being injected into programs. What if it is malicious?

It may or may not be a problem depending on whether it's actually used, which is still better than "gets you instantly the moment you compile the app". A lot of codepaths and even whole libraries aren't invoked just because a program depends on them.

It doesn't really matter anyway, because nobody is reading anything in their dependencies before it gets downloaded. Malware can also be hiding in plain sight in source code, as this attack and many others shows.

ABI stability is significantly different in a VM language to a native language, and reified generics necessarily require source compilation. Binary-only development for Rust would be exactly as 'sort of not really' as C++, for exactly the same reasons. (There is also no notion of 'installing' dependencies in Rust, and build-time code being malicious isn't much worse than runtime code being malicious.)

But people say build.rs is used mostly to compile C dependencies, in which case the lack of ABI stability of Rust is neither here nor there.

It's used to do all sorts of things. Rust version probing, bindings generation, precompiling bundled data, etc. The only reason it isn't used to do more is because proc macros do it instead, with an essentially identical execution model and sandboxing situation (ie build scripts in isolation are a red herring).

Reply on news.ycombinator.com