4 ms·

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 ch

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".

bluejekyll 7y ago
> 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.
- badsectoracula 7y ago
  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.
  - bluejekyll 7y ago
    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.
mirekrusin 7y ago
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.
- pjmlp 7y ago
  Usually language related issues are only understood when a project scales beyond a core team of experts.
- saagarjha 7y ago
  Apparently most of those lines are vendored dependencies.
  - Sammi 7y ago
    0.7 million of of them are their own.
  - mirekrusin 7y ago
    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.
  - bluejekyll 7y ago
    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.
- afiori 7y ago
  A relevant factor could be in the other con Con: None of our current end-developers use Rust.
  - eonil 7y ago
    I seriously doubt that whether any of their “end users” are allowed to use Rust.
usrusr 7y ago
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.

bluejekyll 7y ago

> 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.

badsectoracula 7y ago
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.
- bluejekyll 7y ago
  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.

mirekrusin 7y ago

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.

pjmlp 7y ago
Usually language related issues are only understood when a project scales beyond a core team of experts.
saagarjha 7y ago
Apparently most of those lines are vendored dependencies.
- Sammi 7y ago
  0.7 million of of them are their own.
- mirekrusin 7y ago
  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.
- bluejekyll 7y ago
  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.
afiori 7y ago
A relevant factor could be in the other con Con: None of our current end-developers use Rust.
- eonil 7y ago
  I seriously doubt that whether any of their “end users” are allowed to use Rust.

usrusr 7y ago

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.