4 ms·

> other than by invoking possible UB I addressed this when I talked about a compiler fork. Google could maintain a patchset against the Rust compiler that make

> other than by invoking possible UB I addressed this when I talked about a compiler fork. Google could maintain a patchset against the Rust compiler that makes this behavior well-defined in a way that suits them during the transition period as C++ code is rewritten. Or they could work with the Rust Core Team to address this issue in a way that is favorable to them over the next year or two. Either of these options are much less work than developing an entirely new language and ecosystem. As far as I can tell, Google tried neither option. Still, Mozilla and others have gotten along just fine as it is.

joshuamorton 4y ago
> Rust compiler that makes this behavior well-defined in a way that suits them during the transition period as C++ code is rewritten To be clear, this is "forever". I don't think anyone involved has an expectation to truly get rid of Google's existing C++ codebase ever. So the question is, do you really want Google to fork rustc to implement some google specific UB handling? Is that good or fair to the rust community? Even if it was, the HN comments would be along the line of "Google is using an embrace/extend/extinguish approach to force rust to do certain things bypassing the normal rust language processes", and they'd in some ways be correct! Could rust really choose different semantics from the already existing one, or would google-rust implicitly be a standard that rust would need to support? Would that be a good idea for anyone? > Still, Mozilla and others have gotten along just fine as it is. IIUC, one of the driving factors behind this is that vanilla C++ is too slow, and ABI compatibility prevents up-streaming certain performance improvements. So what works for Mozilla probably doesn't work here, because what works for Mozilla has a performance penalty. Sure it's small, but that's going in the wrong direction.
- coder543 4y ago
  > To be clear, this is "forever" I guess I didn't finish my thought in that comment, because it isn't forever... it's only until either the C++ is gone, or the Rust language has developed an equally acceptable alternative (which could be upstreamed by Google, or come from somewhere else). And realistically, the C++ would never have to go away entirely for this UB handling fork to become unnecessary, depending on the driving factors. Some code paths are more performance sensitive than others, and these tend to represent a small portion of the overall code. Once the performance sensitive code paths are rewritten, it matters less whether there is a small performance penalty for the remaining C++ code that is less sensitive to performance. But, at Google Scale, the cost of the developer-hours to maintain that fork would probably be less than the cost of the small increase in CPU hours that removing the fork would result in, so... yeah, maybe forever or until there is an upstream solution. Maintaining a patchset like this would still cost way less than maintaining an entire compiler and all the language tooling needed to support that language... does anyone really disagree? A new language is far more than just a compiler, let alone a patch for a compiler. > Would that be a good idea for anyone? IMHO, it definitely seems better than Carbon.
  - zozbot234 4y ago
    But the way the Rust compiler works today is quite acceptable already. This isn't a Rust-the-language problem other than in secondary ways that are hard to address by definition (such as "movable" data being the default and Pin<> references being special), it's a Rust-the-library-ecosystem (including, but not limited to, std and/or core) issue. It can only be addressed as such.

joshuamorton 4y ago

> Rust compiler that makes this behavior well-defined in a way that suits them during the transition period as C++ code is rewritten To be clear, this is "forever". I don't think anyone involved has an expectation to truly get rid of Google's existing C++ codebase ever. So the question is, do you really want Google to fork rustc to implement some google specific UB handling? Is that good or fair to the rust community? Even if it was, the HN comments would be along the line of "Google is using an embrace/extend/extinguish approach to force rust to do certain things bypassing the normal rust language processes", and they'd in some ways be correct! Could rust really choose different semantics from the already existing one, or would google-rust implicitly be a standard that rust would need to support? Would that be a good idea for anyone? > Still, Mozilla and others have gotten along just fine as it is. IIUC, one of the driving factors behind this is that vanilla C++ is too slow, and ABI compatibility prevents up-streaming certain performance improvements. So what works for Mozilla probably doesn't work here, because what works for Mozilla has a performance penalty. Sure it's small, but that's going in the wrong direction.

coder543 4y ago
> To be clear, this is "forever" I guess I didn't finish my thought in that comment, because it isn't forever... it's only until either the C++ is gone, or the Rust language has developed an equally acceptable alternative (which could be upstreamed by Google, or come from somewhere else). And realistically, the C++ would never have to go away entirely for this UB handling fork to become unnecessary, depending on the driving factors. Some code paths are more performance sensitive than others, and these tend to represent a small portion of the overall code. Once the performance sensitive code paths are rewritten, it matters less whether there is a small performance penalty for the remaining C++ code that is less sensitive to performance. But, at Google Scale, the cost of the developer-hours to maintain that fork would probably be less than the cost of the small increase in CPU hours that removing the fork would result in, so... yeah, maybe forever or until there is an upstream solution. Maintaining a patchset like this would still cost way less than maintaining an entire compiler and all the language tooling needed to support that language... does anyone really disagree? A new language is far more than just a compiler, let alone a patch for a compiler. > Would that be a good idea for anyone? IMHO, it definitely seems better than Carbon.
- zozbot234 4y ago
  But the way the Rust compiler works today is quite acceptable already. This isn't a Rust-the-language problem other than in secondary ways that are hard to address by definition (such as "movable" data being the default and Pin<> references being special), it's a Rust-the-library-ecosystem (including, but not limited to, std and/or core) issue. It can only be addressed as such.