Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

opensource.googleblog.com

Post reply on HN
Print view View original

171–180 of 233 posts

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#171

Post by predictabl3 »

c_crank wrote: post #167
predictabl3 wrote: post #153

Earlier quoted context omitted.

Actix was chalk full of not just unnecessary, but showably unsound usages of unsafe. And then resisted fixing it, and then after another review months later was found to still contain such deficits. Which, ironically, would have been even worse , written with the same level of care, in C.

"This Haskell program was chalk full of not just unnecessary, but showably unsound uses of UnsafePerformIO..." The language lets people write code that way if they wish. Why are Rust people so aggressive about that?

Who? Aggressive about what?

Do you get this offended when someone points out obvious bugs and security holes in your C code? What do you expect to happen? The community of people who care about safe systems programming to go "oh yeah it's totally fine that a growing library is full of unnecessary and buggy uses of a language feature"?

Take a step back, yeesh. You're just flailing now, and I think I'm going to let you do that by yourself.

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#172

Post by c_crank »

predictabl3 wrote: post #171
c_crank wrote: post #167

Earlier quoted context omitted.

"This Haskell program was chalk full of not just unnecessary, but showably unsound uses of UnsafePerformIO..." The language lets people write code that way if they wish. Why are Rust people so aggressive about that?

Who? Aggressive about what? Do you get this offended when someone points out obvious bugs and security holes in your C code? What do you expect to happen? The community of people who care about safe systems programming to go "oh yeah it's totally fine that a growing library is full of unnecessary and buggy uses of a language feature"? Take a step back, yeesh. You're just flailing now, and I think I'm going to let you…

>Who? Aggressive about what?

Rust 'community' (subreddit?) members, sending nasty messages to the Actix developer.

It was pretty clear the Actix developer was interested in making a fast, dependable web server that was especially good on benchmarks. If the community was so incensed that he did not follow the idiomatic safety standards (that are a language feature rather than a requirement of use), they had a perfectly easy tool to solve the issue: forking the project, to make a Safe-Actix. Naturally, they did not do this, because most of them are more interested in this idea of 'safety' rather than good software.

I don't get paid to write any C code, and I don't have much interest in benchmarking, myself, but if I did, I would also be annoyed if I had to deal with nasty comments or worse by a bunch of internet randos insisting I follow a vague standard that makes them feel important.

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#173

Post by gaganyaan »

norir wrote: post #129
epage wrote: post #34

> Rumor 2: The Rust compiler is not as fast as people would like – Confirmed ! I wish there was more context to these, especially this one. For example, how much of this is perception compared to what they were used to (go?, Python?, C++?)? Or is it "any waiting is bad"? From an improvement perspective, I'd also love to know why their builds are slow. Is it proc-macro heavy? Do they have wide and deep dependency grap…

> Or is it "any waiting is bad"? Yes, this is the problem. Waiting is always bad for productivity. Even a second is long enough to lose a bit of focus. When that stretches out to 10 seconds, it starts getting tempting to, say, check Hacker News and lose your train of thought. I believe that most of the programs that I might be tempted to write in rust could be written in an alternate language with a compiler that is…

I don't really wait for the compiler much. One initial wait for a clean compile, sure. But after that, LSP mode means immediate feedback in my editor before I could even switch to my terminal

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#174

Post by xscott »

whyever wrote: post #122
softirq wrote: post #30

> Low-level Operating Systems Sr. User Experience Researcher Wow, I didn't even know this job existed. IMO Rust as a C++ replacement is fine, Rust as a C replacement has more trade-offs than I still care to make. C is still far simpler (you can still read K&R in one day and keep most of the language in your head), has faster compile times, and the pain points cough macros are still often pain points in Rust. I think…

> you can still read K&R in one day and keep most of the language in your head Does this include all 193 cases of undefined behavior?

I know you're just trashing C UB because that's fashionable, but if you really think about it there are two popular options, and you can't have both at the same time:

a) UB enables valuable optimizations and is important to keep (or even add) when performance matters

b) UB makes the language unusable/insecure to anyone but genius level experts and should be avoided

Whenever someone (including famous/relevant people like Dennis Ritchie [0], DJ Bernstein [1], or Linus Torvalds [2]) tries to suggest cleaning up, removing, or simply not adding new cases of undefined behavior in C/C++, the optimization experts come running from the other room screaming about how important it is that "signed integer overflow must be undefined" [3] or else things will run a percent more slowly (signed overflow being just one example of UB). Also there are people who suggest adding new UB to Rust [4].

So really, either Rust is significantly slower than C because Rust doesn't have the UB you're criticizing, or C could be a cleaner language without compromising on speed and the compiler writers and standards committees are wrong. You choose, but both options are considered heresy.

[0] https://www.lysator.liu.se/c/dmr-on-noalias.html

[1] https://groups.google.com/g/boring-crypto/c/48qa1kWignU

[2] https://lkml.org/lkml/2018/6/5/769

[3] https://youtu.be/yG1OZ69H_-o

[4] https://www.ralfj.de/blog/2021/11/24/ub-necessary.html

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#175

Post by chlorion »

xscott wrote: post #174
whyever wrote: post #122

Earlier quoted context omitted.

> you can still read K&R in one day and keep most of the language in your head Does this include all 193 cases of undefined behavior?

I know you're just trashing C UB because that's fashionable, but if you really think about it there are two popular options, and you can't have both at the same time: a) UB enables valuable optimizations and is important to keep (or even add) when performance matters b) UB makes the language unusable/insecure to anyone but genius level experts and should be avoided Whenever someone (including famous/relevant people l…

Rust does actually do the many of the same optimizations, and in unsafe rust this can and does lead to UB.

An example of this, is aliasing mutable references. Rust has been designed to assume that two mutable refs will never alias, if you attempt to do this it is instant UB. My understanding is that even creating the aliasing reference is UB, even if you don't use it.

Another example would be uninitialized values. In rust, the compiler assumes that values are always "valid" and initialized. Since you need to allocate memory before writing to it, you need some way to safely have uninit values, and this is what the MaybeUninit wrapper type is for. The wrapper allows you to safely have uninit values, and once you write to them you can tell the compiler that they are initialized, but if you tell the compiler before on accident, it is UB.

References also are guaranteed to point to initialized and valid data, and can never be null, though my understanding is that there is some uncertainty about the exact rules of this with regards to uninitialized values and the exact semantics may change in the future.

(There are also a lot more things that I don't know very much about!)

All of these things are assumed to never happen, and optimizations are performed based on that assumption.

The nice part about rust, is that it makes it impossible to represent invalid states using the type system!

For aliasing, you can only have a single live mutable reference at any time, attempting to create a second one while another is live is a compile time error!

For uninitialized values, you simply can't create uninitialized values at all in safe rust. My understanding is that the only way to create an uninitialized value is with the MaybeUninit type or by using raw pointers.

So rust still has heaps of UB, but it doesn't allow you to do it by default, so you still get some of the optimizations you'd expect.

I think there are some cases where rust is missing out on optimizations though, like with signed int overflow for example, and probably more that I don't know about!

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#176

Post by WiSaGaN »

jenadine wrote: post #136
softirq wrote: post #30

> Low-level Operating Systems Sr. User Experience Researcher Wow, I didn't even know this job existed. IMO Rust as a C++ replacement is fine, Rust as a C replacement has more trade-offs than I still care to make. C is still far simpler (you can still read K&R in one day and keep most of the language in your head), has faster compile times, and the pain points cough macros are still often pain points in Rust. I think…

The "simplicity" of C is not a good thing. The Brainfuck language is even "simpler" and you can read the spec in 2 minutes. But that does not make it easier, because all the complexity is in the usage. The abstraction layer that one can build with rust allow the programmer to actually focus of the actual business logic instead of trying to get low level details right.

Absolutely. I used to work in a C++ shop writing mission critical software. We would be far more concerned to let a newcomer to contribute on existing C++ codebase than on existing Rust codebase. The newcomer surely would have a harder time to make a pull request that compiles and passes tests in Rust than in C++, but that is a good thing for maintainers.

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#177

Post by xscott »

chlorion wrote: post #175
xscott wrote: post #174

Earlier quoted context omitted.

I know you're just trashing C UB because that's fashionable, but if you really think about it there are two popular options, and you can't have both at the same time: a) UB enables valuable optimizations and is important to keep (or even add) when performance matters b) UB makes the language unusable/insecure to anyone but genius level experts and should be avoided Whenever someone (including famous/relevant people l…

Rust does actually do the many of the same optimizations, and in unsafe rust this can and does lead to UB. An example of this, is aliasing mutable references. Rust has been designed to assume that two mutable refs will never alias, if you attempt to do this it is instant UB. My understanding is that even creating the aliasing reference is UB, even if you don't use it. Another example would be uninitialized values. In…

I can see your enthusiasm for Rust, but my comment was more directed to whether criticisms of UB in C can be taken seriously considering suggestions to remove it where possible have almost always been shot down in the name of speed.

> I think there are some cases where rust is missing out on optimizations though, like with signed int overflow for example

Before you push for UB in safe Rust, I politely suggest you write your own benchmark for this in C or C++. Try a few combinations of { signed, unsigned } X { 32 bit, 64 bit } X { gcc, clang }, compiled at -O2 or higher, and see what you get for results. Maybe throw in -fwrapv for some of the runs. My own conclusion on my own benchmarks is that UB advocates are mostly wrong.

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#178

Post by joshka »

pcthrowaway wrote: post #111

The idea that people might spend 2 months learning rust and become as productive in other languages is frankly unbelievable to me. If they're coming from any background other than C/C++ I'm suspicious that people can even become as productive in general (which is fine, reduced productivity is in my mind one of the trade-offs you make for memory safety and increased performance when choosing Rust) But this is Google,…

>The idea that people might spend 2 months learning rust and become as productive in other languages is frankly unbelievable to me.

Upvoted even though I anecdotally disagree with your perspective based on personal experience. I wrote my first line of rust in March this year (just as a hobby), and now am one of the maintainers of a popular TUI framework (Ratatui). I feel just as productive or more than any of the previous languages I've written code in (over the last 30 something years).

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#179

Post by pcthrowaway »

joshka wrote: post #178
pcthrowaway wrote: post #111

The idea that people might spend 2 months learning rust and become as productive in other languages is frankly unbelievable to me. If they're coming from any background other than C/C++ I'm suspicious that people can even become as productive in general (which is fine, reduced productivity is in my mind one of the trade-offs you make for memory safety and increased performance when choosing Rust) But this is Google,…

>The idea that people might spend 2 months learning rust and become as productive in other languages is frankly unbelievable to me. Upvoted even though I anecdotally disagree with your perspective based on personal experience. I wrote my first line of rust in March this year (just as a hobby), and now am one of the maintainers of a popular TUI framework (Ratatui). I feel just as productive or more than any of the pre…

Interesting. I've been learning/using rust for work for the last 3 months.

I'm at the point now where I'm productive (took me over a month to even get to that point), but I still feel incredibly slow compared to Typescript. The compilation time doesn't help.

Anyway, thanks for the perspective.

I'm still skeptical that the survey reflects honest feedback given Google's culture, but perhaps I'm just biased from how long it's been taking myself and the rest of the team to achieve a higher level of productivity

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#180

Post by the__alchemist »

adamnemecek wrote: post #91
the__alchemist wrote: post #76

Earlier quoted context omitted.

I think this is often a function of Rust OSS libs vice the language itself. The embedded Rust community has created and promoted bad APIs. I think it's worth pointing this out and building other APIs, even though this doesn't endear you to the Rust community. I'm worried people will get the wrong idea about embedded Rust ergonomics and attribute these APIs to the language itself.

Can you talk more about this? I'm very curious.

The other replies reflect my thoughts, so I don't have much to add. So, these are elaborations on those:

It appears most of the peripheral support libs (eg those that use Embedded-HAL traits) are not designed with practical ends in mind; I've found it easier for all I2C/SPI etc devices I've used to start from scratch with a `setup` fn with datasheet references, than DMA transfers. So, you have these traits designed to abstract over busses etc; they sound nice in principle, but are (so far) not useful for writing firmware.

I get a general sense that the OSS libs are designed with a "let's support this popular MCU/IC, and take advantage of Rust's type system and language features!" mindset. A bare minimum is done, it's tested on a dev board, then no further testing or work. There are flaws that show up immediately when designing a device with the lib in question.

So, at least for the publicly-available things, they're designed in an abstract sense, instead of for a practical case.

Post reply on HN