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

91–100 of 233 posts

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

#91

Post by adamnemecek »

the__alchemist wrote: post #76
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 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.

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

#92

Post by brigadier132 »

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…

How do you build a data race safe language without taking on the restriction of immutable data (which is imo, a much worse and bigger tradeoff than the borrow checker)?

I actually really like the borrow checker as a tradeoff, I think it makes code much easier to understand and it makes all aliasing bugs impossible. The removal of aliasing bugs is I think an undersold benefit of using rust.

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

#93

Post by brigadier132 »

criddell wrote: post #84
summerlight wrote: post #70

Earlier quoted context omitted.

At least you won't get paged due to some weird memory bugs. Yes, this happens quite frequently. Worse, it's usually not something local to a single change but interaction across seemingly safe changes.

Is well written Rust code better with respect to paging than well written C++ code?

Rust code that compiles gives you certain guarantees that C++ code that compiles does not. The question isn't is well written code in one language better than well written code in another language. The question is, do I know this code is well written? In Rust you know, in C++ you don't without jumping through a bunch of other hoops.

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

#94

Post by jsgf »

steveklabnik wrote: post #56
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.

Anecdotally, C++ developers often have a harder time coming to Rust than folks from a more scripty background. They have to unlearn things, and that can be harder than learning things. You can see similar opinions expressed in this thread, like here, for example: https://news.ycombinator.com/item?id=36496654

Python programmers love Rust: - Lots of compilation errors, but then the code does what it says - Fast! That gives an immediate benefit that people coming from C++ don't see.

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

#96

Post by sanxiyn »

c_crank wrote: post #89
predictabl3 wrote: post #87

Earlier quoted context omitted.

> But the stream of very angry developers with a bone to pick about 'safety' is new. /me looks around for the Boogeyman... Not seeing it. I'm not angry, but I guess I do have some emotions when I use critical software, written in C by devs who claim they can write perfect C, and I get segfaults. > Many of its features and promises have been done in other languages Also, no, despite often being repeated by those insis…

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…

Cyclone is garbage collected.

Yes, Cyclone is probably the single biggest influence on Rust. No, but Rust had to introduce theoretical novelties on top of Cyclone. (Rust was very reluctant to do "research", considering its job to be productizing existing research, but it was forced to research anyway, because nothing existing worked.)

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

#97

Post by kaba0 »

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…

C has beyond useless “macros”, they should not be compared with Rust’s, that are actually useful.

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

#98

Post by jsgf »

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…

In my experience from a Googlish environment (tho mostly focusing on backend service development): 1. people don't know about check builds and have a much nicer iteration experience once they learn about it, 2: rust-analyzer red wiggles also help, and 3. a lot of the actual build time is from build/link of C++ dependencies from the rest of the codebase.

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

#99

Post by kaba0 »

no_wizard wrote: post #20
thesuperbigfrog wrote: post #3

"The top three challenging areas of Rust for current Google developers were: * Macros * Ownership and borrowing * Async programming " Async programming is the area I would like to see the most improvement, especially in the standard library. So much concurrent and parallel Rust code relies on third-party libraries because the standard library offers primitives that work but lack the "creature comforts" that developer…

Color functions are just not the right road to go down. Something akin to Javas new green threads would be better, or Go style coroutines. The path Rust is going means async becomes viral, and is something I dislike a lot about JavaScript[0] and other languages I’ve worked in[1]. I’d love to see Rust avoid this trap. [0]: I work in TypeScript in actuality not sure which to use here. It’s certainly by far the language…

> Color functions are just not the right road to go down. Something akin to Javas new green threads would be better, or Go style coroutines

I agree with you on this in case of high-level languages. Rust is not that, and wouldn’t be half as interesting that way — but by going the system/low-level language route it does have to make certain design decisions that are not ideal. They can’t do what java’s loom does as it requires knowing every method implementation, which is fine with a fat runtime, but is not possible in case of Rust, with plenty FFI boundaries, etc.

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

#100

Post by shepmaster »

criddell wrote: post #54
summerlight wrote: post #38

Earlier quoted context omitted.

I've been studying C++ over 15+ years and still don't feel very productive thanks to the fear of getting paged every releases.

Does Rust give guarantees around paging? Is Rust similar to C++ in that respect?

FWIW, I believe the person you are replying to means "paged" as in "an alert was sent to my pager at 3AM that the entire system is down and I need to wake up and fix it", not the paging in/out of memory.
Post reply on HN