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

121–130 of 233 posts

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

#121

Post by ithkuil »

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…

Yes. To make this more concrete: If your non-async function uses a parameter whose type is a dyn trait or a generic bounded by a trait, it can call the methods of that trait and thus potentially call different implementations of that trait.

Currently, none of those trait implementations can be async because that would change the function signature.

So the only option you have in a trait implementation that needs to call a library that happens to use async apis internallt, is to "block_on" the async. Unfortunately iirc blocking on an async like that is executor specific and your impl must pick a concrete async executor which may be different from the one used elsewhere in the program.

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

#122

Post by whyever »

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?

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

#123

Post by sanxiyn »

estebank wrote: post #72
nmlt wrote: post #60

Earlier quoted context omitted.

I haven’t tried debugging with lldb in some time so I don’t know whether it has improved significantly, but couldn’t the 9% also include that?

It could be the case. There are multiple separate efforts to improve the debugging experience in production (improving monitoring, cheap profiling, improving logging, encoding more info in the DWARF output), but all of those will take some time to reach the same level of quality that, for example, Java has today.

I am somewhat pessimistic because LLVM is significantly behind GCC in debug information quality (for example, see https://robert.ocallahan.org/2018/11/comparing-quality-of-de...) and there is limit to what Rust can do about it short of fixing LLVM.

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

#124

Post by criddell »

shepmaster wrote: post #100
criddell wrote: post #54

Earlier quoted context omitted.

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.

Oh wow, I totally missed that. Thanks for clearing it up.

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

#125

Post by hgomersall »

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" in this case just means signature. Of course you can't mix signatures - why would you want to? You might as well argue that Rust shouldn't have had any more than a single integer argument to every function. Async in rust essentially desugars to a return trait impl.

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

#126

Post by criddell »

brigadier132 wrote: post #93
criddell wrote: post #84

Earlier quoted context omitted.

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.

What I'm trying to get to is if the guarantees include better control over the heap and paging. Everybody wants to tell me C++ likely has bugs which I understand, but it's not what I'm asking about.

Edit: I missed that the original person I responded to was talking about being paged when a problem arises and not about memory performance. I'm still curious though if Rust memory guarantees give the programmer better tools for dealing with memory paging.

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

#127

Post by bigyikes »

steveklabnik wrote: post #21
bigyikes wrote: post #14

> Rumor 5: Rust code is high quality – Confirmed! > The respondents said that the quality of the Rust code is high — 77% of developers were satisfied with the quality of Rust code. Well, that’s exactly what I’d expect Rust developers to say. Nobody loves Rust more than Rust adopters. Would be interesting to see more objective measures of code quality (e.g. defect rate) Also, the type of person to work on a Rust codeb…

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 to supplement the anecdotes. This especially applies to Rust, but I think also applies to any language.

Note that I don’t mean to imply that there isn’t value in anecdotes. There is.

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

#128

Post by yazaddaruvala »

Animats wrote: post #120
flylikeabanana wrote: post #106

Earlier quoted context omitted.

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…

Correct. I have an unusual application, a metaverse client for big 3D worlds. It has to deal with a flood of data while maintaining a 60 FPS frame rate. It's essential that the rendering thread(s) not be delayed, even though other background threads are compute bound dealing with a flood of incoming 3D assets. This does not fit well with the async model. This sort of thing comes up in games, real time control, and ro…

> This sort of thing comes up in games, real time control, and robotics, but is not something often seen in web-related software.

I think you're not familiar with web-related software.

> It's essential that the rendering thread(s) not be delayed, even though other background threads are compute bound dealing with a flood of incoming 3D assets.

This is exactly how the browser behaves, and why Javascript needs to be entirely async on the main thread.

For your application it should be very easy to spin up a render thread (pinned to a single core or whatever priority mechanisms you want to use) that loops, and use message passing to get the results from Tokio based futures.

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

#129

Post by norir »

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 up to 100x faster. Of course this hypothetical language would have to be simpler than rust and would lack many of its features. As it currently stands though, I believe that it will be impossible to make the rust compiler 10x faster, let alone 100x faster so it would be nice if there was more effort to design alternative languages that build on what we've learned from rust to make something better.

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

#130

Post by izacus »

steveklabnik wrote: post #68
izacus wrote: post #45

Earlier quoted context omitted.

Mostly? Yes. Google has more than 120.000 engineers. Those 1000 are less than 1% of engineers. It's like having one Rust dude in a 100 person company. Most of people work in other languages.

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.

Post reply on HN