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

161–170 of 233 posts

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

#161

Post by steveklabnik »

shrimp_emoji wrote: post #160
steveklabnik wrote: post #154

Earlier quoted context omitted.

It's a broad strokes kind of thing, not a universal thing. To be honest I think it has more to do with attitudes towards the language and compiler that tend to be more prevalent in C and C++ circles. That is, a lot of people expect that the compiler is a tool that must do what they say, not a collaborative partner. Back in the IRC days, people used to join, and be like "Rust won't let me do X. X is obviously okay. Ho…

Ha. Given that the C and C++ compilers optimize your code by inferring undefined behavior and other crazy stuff like that, it's funny to imagine you're not just playing with just another code generator. :p (In fact, if you decide to be responsible about what you're telling your poor compiler to do and use a `size_t i` instead of an `int i` in your for loop, since iteration can never go negative and, if overflow happe…

I agree with you, but many trot out the "portable assembly" line.

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

#162

Post by WaffleIronMaker »

estebank wrote: post #10

Really happy to see these results on the perception of googlers on quality of the Rust compiler errors, an area I'm highly passionate about. I'd like to take this as an opportunity to encourage the 9% (and the other 91% as well) to file tickets when we don't meet the bar we've set for ourselves.

I'm a junior developer learning Rust, and I just want to say thank you for all of the work you've put into making the errors high quality. It makes learning the language such a better experience.

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

#163

Post by carlmr »

flylikeabanana wrote: post #106
Animats wrote: post #77

Earlier quoted context omitted.

"Async" is optimized for the special case of a server that is I/O bound and spends most of its time waiting for network traffic. This covers most webcrap, so many people who do nothing else want that. It also works like JavaScript, a model with which many web programmers are comfortable. It's a bad fit if you have enough compute work to keep all the CPUs busy. Then you're dealing with thread priorities, infinite over…

Isn't this the difference between concurrency and parallelism? Like you said, Tokio (I'm coming from effect systems in Scala, the current generation of which take heavy inspiration from Tokio) is good for informing your program when your code is blocked so it can perform some useful work elsewhere, which is a fundamentally different problem to parallelizing code. So if I'm understanding your complaint right it's that…

Not OP, but I think the problem they are trying to explain is that if you create an async function it can only be called from other async functions, so it's quite an infectious concept.

If you create a library that uses async, you're forcing everybody that uses the library into async as well (with the same executor).

If somebody writes a library now that's generally useful but uses async, it forces others to use async or rewrite the library themselves.

On the one hand a lot of people put this down as whining about free code, which is somewhat true, but the infectious nature makes the whole ecosystem less useful if you want to build something non-async.

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

#164

Post by PartiallyTyped »

saulrh wrote: post #19
durandal1 wrote: post #8

After four months , only 50% of the developers though they were as productive in Rust as other language. Given that the respondents are arguably a very capable group of engineers, this doesn't seem that great for any company looking to adopt Rust.

Consider an alternative reading: 50% of developers think they are as productive in a language they have four months of practice with as they are in a language they have four teen years of practice with. 50% of developers think they are as productive in a high-performance bit-bashing-capable language as they are in a high-level glue language. The people in this statistic are switching from languages they have years or…

I am willing to bet that the type system and the opinionated way of doing things helps a lot here.

Anecdata but I found myself very productive with Haskell when I was learning it for grad school, to the point where I knew that if it compiled, it was most likely right.

I had similar experiences though not to that degree with Rust with very little time spent on it in comparison to Haskell. I feel a lot more comfortable sleeping at night over C or Python.

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

#165

Post by davidhyde »

softirq wrote: post #152
jenadine wrote: post #136

Earlier quoted context omitted.

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.

I think you missed the part about systems programming. When you are programming real hardware, the focus is entirely on low level details. You need to know the commands being sent to the device, the device state, and the ownership of resources by the device (which Rust doesn't solve for) are correct. The innovation of Rust is the borrow checker, which is primarily of interest to systems programmers. If your primary i…

> “and the ownership of resources by the device (which Rust doesn't solve for) are correct.”

For embedded software, the underlying code basically reads and writes a bunch of registers. Unsafe memory access with side effects. The benefit of using rust here is that you can easily model these access patterns to make an api that cannot be abused. So the driver reads and writes addresses and the user code operates through the driver with all the benefits of ownership at hand to avoid race conditions and other foot-guns.

So, in this way rust does indeed “solve for” ownership of devices. You can’t have two threads (or interrupt handlers) mutating the same device without satisfying the ownership rules.

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

#166

Post by dmytrish »

verdagon wrote: post #88
Kranar wrote: post #49

Earlier quoted context omitted.

Four months to become as proficient in a memory safe, data race safe, and high performance language as in other languages seems like an astonishing accomplishment. In fact it's frankly unbelievable, I'd have to imagine these guys are coming from a C++ background.

I don't think it has to be this hard to have memory safety, data race safety, and performance. After building and doing PL design in this space for a decade, I don't believe the assumption that Rust's or C++'s difficulties are inherent. I think C++ has its own legacy difficulties (which also make transitioning to memory safety tricky), and Rust's choice of borrow checking is only one (sometimes difficult) technique f…

Please demonstrate a practical and memory safe systems programming language without borrowing.

I'd be delighted to see it, because right now I am not aware of any practical way to have memory safe regions without static tracking of borrowing from these regions. It's either that or runtime checking.

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

#167

Post by c_crank »

predictabl3 wrote: post #153
c_crank wrote: post #89

Earlier quoted context omitted.

Ada, and Cyclone, and Misra C, and various other C formalization tools. It also borrows a lot of the ML stuff from... ML. Engineers who had safety as their prime goal can and often did use Ada and other tools to achieve that goal. The average Rust developer does not seem to be concerned with safety as a goal for the product specification, but rather as some kind of thematic justification divorced from the actual engi…

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?

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

#168

Post by verdagon »

dmytrish wrote: post #166
verdagon wrote: post #88

Earlier quoted context omitted.

I don't think it has to be this hard to have memory safety, data race safety, and performance. After building and doing PL design in this space for a decade, I don't believe the assumption that Rust's or C++'s difficulties are inherent. I think C++ has its own legacy difficulties (which also make transitioning to memory safety tricky), and Rust's choice of borrow checking is only one (sometimes difficult) technique f…

Please demonstrate a practical and memory safe systems programming language without borrowing. I'd be delighted to see it, because right now I am not aware of any practical way to have memory safe regions without static tracking of borrowing from these regions. It's either that or runtime checking.

This might be of interest: https://verdagon.dev/blog/first-regions-prototype

It uses region-based static analysis without borrow checking: it doesn't impose aliasability-xor-mutability per object, or even per-region.

Though, if you'd like to move the goalposts further to no form of borrowing at all, then I recommend looking at languages like Forty2 and Verona, they might be what you're looking for.

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

#169

Post by c_crank »

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.

Several successor languages have kept the simple syntax of C while eliminating a large class of warts. Hindsight and not having to keep a wide reaching set of compiler standards let a language have simple syntax and not so many problems with UB.

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

#170

Post by RcouF1uZ4gsC »

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…

> I think the biggest thing is that systems programming still requires a language that gets out of the way so you can focus on very technical problem domains where what the hardware is actually doing really matters.

Just the fact that Rust doesn’t do implicit integer conversions is by itself a huge win over C which has promotion rules that can easily trip you up when you are trying to exactly specify bits.

Post reply on HN