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

131–140 of 233 posts

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

#131

Post by bsder »

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.

Well, for starters, allocators. The standard library is now making adjustments around that, but it's not mainstream and most people don't use them and they don't get the same level of attention as the happy path.

However, Rust, the language has its issues on embedded.

Rust's ownership model is directly at odds with lots of embedded. These bits inside a register are owned by the ADC and these bits inside a register are owned by the DAC is not a happy thing in Rust.

Lack of arbitrary sized integers and how they slice.

Cargo. Quite annoying to deal with cargo and an embedded toolchain. The Rust embedded guys have done really good work if you're on ARM. If you're not, good luck.

That having been said, if you have to go implement something like Reference Counting in something not Rust, you will weep tears of blood debugging every single time your reference counts go wrong.

Embedded is engineering. It has tradeoffs. That's life.

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

#132

Post by worik »

AtNightWeCode wrote: post #95

Rust is for sure much easier to learn than some people claim. Some parts of Rust is different but it is not very difficult. I think the ecosystem is the major problem with Rust.

> I think the ecosystem is the major problem with Rust.

How? Explain please

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

#133

Post by tick_tock_tick »

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've always been taught and memorized 197 are you forgetting some? Most from those lists are very easy since they are basically the same error played out slightly different.

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

#134

Post by bsder »

sanxiyn wrote: post #103
jimbob45 wrote: post #101

Earlier quoted context omitted.

While that’s true, preprocessors are pretty trivial to write these days if you want macros that the language doesn’t support. Racket excels at this.

Which preprocessor do you recommend for writing C?

None.

Use an actual different language. Ada, Rust, Zig, D, Lisp/Scheme/Racket, Tcl, Forth, etc. ... something other than C.

Don't preprocess C into a slightly broken other language that you wish it were. Use C as C, or use something else.

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

#135

Post by sanxiyn »

bigyikes wrote: post #127
steveklabnik wrote: post #21

Earlier quoted context omitted.

People used to say "when people are forced to use Rust at their job, they'll start hating it, only hobbyists use it and that's why it's so beloved." Do you really consider people learning Rust on the job to be "Rust adopters" who are partisan? Is anyone who ever uses Rust a "Rust adopter" who is unable to give an unbiased opinion? Who would be able to give that opinion, in your view?

> Do you really consider people learning Rust on the job to be "Rust adopters" who are partisan? Not necessarily, but it seems not unlikely. > Is anyone who ever uses Rust a "Rust adopter" who is unable to give an unbiased opinion? It’s still a relatively new and niche language, so, yes. > Who would be able to give that opinion, in your view? Nobody, and maybe that’s my real point, which is why I’d like some metrics…

I agree the post could include more concrete metrics than self-assessment, but more than 1000 data points, even self-assessment data points, are usually not called anecdotes.

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

#136

Post by jenadine »

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.

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

#137

Post by AtNightWeCode »

worik wrote: post #132
AtNightWeCode wrote: post #95

Rust is for sure much easier to learn than some people claim. Some parts of Rust is different but it is not very difficult. I think the ecosystem is the major problem with Rust.

> I think the ecosystem is the major problem with Rust. How? Explain please

I mostly looked at Rust to replace tools written in GO and Webapis written in ASP.NET/C#. In both cases there seems to be options in Rust but not reliable ones. With reliable I mean that it is just too few people involved. Not that it does not work.

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

#138

Post by littlestymaar »

kaba0 wrote: post #107
littlestymaar wrote: post #80

Earlier quoted context omitted.

I really wish people stopped using this concept of “function colors”, especially in the context of Rust because the `async fn`/“regular function” split is strictly equivalent to the `try_something()`/`something()` split (the first one being fallible and returning a `Result` in case of failure). `Result`s and `Option`s are coloring the stack in exactly the same way a `Future` does (and `async` is pure syntactic sugar…

While you are technically right, one area where the two are unlike is that you want to be polymorph with regards to async/non-async, while it is less often the case for error handling. That exact same sleep implementation, or db query should be usable both as an async call, as well as a blocking one and it is the caller that wants to decide that. Which is not trivial to do on the calling side from a language perspect…

> While you are technically right, one area where the two are unlike is that you want to be polymorph with regards to async/non-async, while it is less often the case for error handling.

The reason why we don't want to be polymorphic between fallible and “infallible” functions is that we put a clear social hierarchy between “properly handle error cases” and “panicking”. Using panics instead of `Result` make error handling much less cumbersome in Rust too, but we've clearly internalized that this isn't something you should do for real. Symmetrically, I'd argue that there's no much point to have both async and sync interfaces, if the user just want the quick and dirty approach, `spawn_blocking` is barely more typing effort than `unwrap`. The broad developer community (most of which having programmed well before Futures/Promises went mainstream) disagrees with me on that point, but that's a cultural thing.

Oh, and Result/Options aren't the sole “stack coloring” thing in Rust either: if you have an “owned” variable down the stack, then you need to either change your entire call stack to take the variable “by ownership” instead of “by reference”, or you can `Clone` it.

And you known what's even worse than this: `&mut`, because then you have no quick-and-dirty fallback (cloning and mutably borrowing the clone variable means you're now dealing with a reference that has a much shorter lifetime than the original one and it only works if your reference doesn't leave the current scope).

As a personal anecdote of someone that's been doing Rust full time for 6 years now, I've encountered the `Option`/`Result `/“owned”/`&mut` function coloring problem many times, and exactly zero times the “async/blocking” function coloring problem. Yet for some reason people are obsessed by an old rant about JavaScript's callback hell ¯\_(ツ)_/¯

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

#139

Post by steveklabnik »

izacus wrote: post #130
steveklabnik wrote: post #68

Earlier quoted context omitted.

The blog post says only 13% of these people have had experience with Rust before joining Google. How do you think Google ended up with so many people who are hardcore evangelists, imposing their views on others? A significant focus of the post is about on-the-job training; do you think that these evangelists were created by these trainings, or did they come to these opinions on their own, and are now pushing for it i…

What on earth are you trying to say here? I'm just saying that Rust fans are currently self-selecting by choosing to work on Rust projects which skews the satisfaction numbers against other languages. That doesn't have a lot to do with previous experience - with Rust being so new, __MOST__ developers, even fans, don't have much experience with it.

I am trying to understand your perspective.

I do not understand how what you're saying here relates to this post, which does not seem to be saying the things that you are saying. I do not understand how to reconcile "we paid to train 1,000 people on the job and here's what they thought" and "only 13% of people had Rust experience before this" with "Rust fans are currently self-selecting by choosing to work on Rust projects."

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

#140

Post by jenadine »

sanxiyn wrote: post #112
VWWHFSfQ wrote: post #5

Earlier quoted context omitted.

rust team needs to abandon their own execution runtime and just bless tokio and pull it into std. They're doing nobody any favors right now

Given that Linux kernel is using async Rust which is implemented on top of kernel workqueue, and tokio won't be usable in kernel, it is a good thing tokio is not blessed. That's what enables both userland and kernel to use async Rust.

There can be both a "blessed" executor, while staying optional for such cases.

For example, Rust std lib has blessed Mutex. Even though these can't be used in the kernel, it is still good to have them in the std lib for >90% of normal crates.

Post reply on HN