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

101–110 of 233 posts

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

#101

Post by jimbob45 »

kaba0 wrote: post #97
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.

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.

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

#102

Post by larsberg »

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.

Thanks for all of your work (in addition to that of others) - it really shows! We do encourage people to create minimal repro cases and open bugs whenever possible. And, even more ideally, to consider contributing a PR upstream...

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

#103

Post by sanxiyn »

jimbob45 wrote: post #101
kaba0 wrote: post #97

Earlier quoted context omitted.

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

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?

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

#104

Post by softirq »

moonchrome wrote: post #75
softirq wrote: post #63

Earlier quoted context omitted.

I'm not really looking for a replacement for C, the ecosystem of system programming is still really C centric, it would take a large shift in the industry for me to justify investing in another language. I've dabbled with Rust only because early support was merged into Linux. IMO most languages are only marginal improvements over the previous generation that don't outweigh fighting against the entrenchment of experti…

Marginal improvements add up.

I agree, at some point they do build up to the point that change is inevitable. There's usually a lot of false starts along the way (AI is a good example of this). No matter what it is, there's going to be a lot of fighting against entrenchment and a lot of us old timers simply have to retire for newer developers, whether they be Rust developers to come in and elicit change.

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

#105

Post by larsberg »

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.

Gah! Typo there. It's over 50% (66.8%) in 2 months. And over 80% in 4 months. The chart is correct, not the text :facepalm:

I'll see about whether I can push an update. Thanks for the catch!

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

#106

Post by flylikeabanana »

Animats wrote: post #77
arijun wrote: post #66

Earlier quoted context omitted.

Sorry if this is ignorant, but what’s the difference between async and concurrent? Is the problem that async schedules everything itself?

"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 Tokio sneaks in when its concurrency features aren't particularly useful for parallelization?

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

#107

Post by kaba0 »

littlestymaar wrote: post #80
no_wizard wrote: post #20

Earlier quoted context omitted.

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…

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 perspective as it then has to recursively decide the same for all its subcalls.

The new experimental languages with effect types might be able to give us the best of both as they actually expose what you are talking about as an abstraction at the type level. We will see.

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

#108

Post by jimbob45 »

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?

https://stackoverflow.com/a/3685576

There’s one approach. I wouldn’t personally recommend using macros outside of include guards and file inclusion. Still, if you need more functionality, the methods exist.

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

#109

Post by [deleted] »

littlestymaar wrote: post #80
no_wizard wrote: post #20

Earlier quoted context omitted.

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…

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…

[deleted]

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

#110

Post by larsberg »

larsberg wrote: post #105
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.

Gah! Typo there. It's over 50% (66.8%) in 2 months. And over 80% in 4 months. The chart is correct, not the text :facepalm: I'll see about whether I can push an update. Thanks for the catch!

Actually, it's complicated stuff pulling together two data points: 1) 2/3 of people are confident contributing in 2 months or less 2) And 50% of people are AS PRODUCTIVE IN RUST as they were in their other language within four months

Given that #2 is talking about people who are all professional programmers and where only a small percentage of respondents previously knew Rust, that's pretty amazing to me.

Post reply on HN