Hacker News Reader

Comment by badsectoracula | Hacker News Reader

The reasoning does sound serious: "The properties of the language are not yet well-understood, having selected an unusual language design point (e.g., borrow checker) and having existed only for a relatively short period of time". It isn't just "it isn't popular thus it is not good" but "it does something weird that no other language does and because few people use it, we haven't yet figured out what potential issues that weird part may have".

View on HN

Reads to me like a slightly more general way of saying "this is not the time to specify an API in Rust that you intend to maintain in perfect backward compatibility forever". But if they said that directly they would be inviting a wave of counter-arguments that they most likely already went through themselves, repeatedly, considering how much love Rust is getting for in-tree use (where APIs can be refactored at will). I believe that their main issue is that they don't want to end up with the Rust equivalent of a Java API stuck with Vector and Enumeration.

After having 2.2 million lines of code in rust in their project they should know a bit better imho; that's more than any other language they use; with go they knew quite quickly it's not good for them.

Usually language related issues are only understood when a project scales beyond a core team of experts.

Apparently most of those lines are vendored dependencies.

0.7 million of of them are their own.

As someone who’s project was vendored into Fuchsia, I will say that there were a number of contributions that were made directly to the project to support its use in Fuchsia.

This means that while the overall project is used outside of Fuchsia, google is contributing upstream patches, to many of those projects specifically to support Fuchsia. At that point it’s not a clean separation of what’s “in house” vs. not.

Yes, but if you think about it, it doesn't make the argument weaker but arguably stronger - not only they use all those lines of code but also it seems that you can do it, ie. use low level (I'm guessing) 3rd party libraries and it will work for you; and they must be having high bar for quality, they operate on low level etc.

A relevant factor could be in the other con

Con: None of our current end-developers use Rust.

I seriously doubt that whether any of their “end users” are allowed to use Rust.

End users here means user-space application developers

> does sound serious

Do you mean legitimate, instead of serious? The issue you point out sounds more like technical debt and verification/specification rather than something that can’t or won’t be overcome.

Yes i meant legitimate, though i'm not sure why you say that it sounds like technical debt. I'd say it is the opposite - trying to avoid technical debt that could happen by betting on something unknown and instead staying on the safe side.

I meant technical debt for the Rust project, not for fuchsia. I don’t disagree, Fuchsia would end up incurring this debt in the kernel too.

I would say, that as debt goes, this seems like something not egregious, but I can understand not wanting to take it on. But, with every passing year and no significant flaws having been discovered (I mean language destroying not some of the unsoundness bugs that exist), empirical evidence is getting stronger and stronger that Rust has an excellent model.

Reply on news.ycombinator.com