Live data from Hacker News

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

opensource.googleblog.com

71–80 of 233 posts

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

#71
If only we could harness the people who still insist that rust is all hype and engage in impressive gymnastics to ignore all evidence to the contrary...

Some of the stuff people say about Rust reminds me of iOS users talking about Android. "Tell me you are operating from a place of near total ignorance, without telling me that you're talking out your butt".

See: the number of people, here, acting like you can't do raw pointers in Rust, or acting like it's militant woke youngins forcing poor big Google to adopt a safer, productive language.

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

#72
post #60

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 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.

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

#74
post #57

No mention of Carbon? I was under the impression Google was designing Carbon to be their C++ successor?

Carbon is sort of a plan B, for working on existing C++ code that would be too difficult to migrate to Rust. It also doesn't really exist yet.

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

#75
post #63
post #39

Earlier quoted context omitted.

Try Zig as a C replacement.

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.

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

#76
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.

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

#77
post #66
post #37

Earlier quoted context omitted.

I'm struggling to get tokio out of my executable. I'm not using it, but stuff keeps pulling it in. Async contamination is a huge problem. For highly concurrent code with threads running at different priority levels, if async gets in there it makes a mess.

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 overtaking and starvation, fairness, and related issues.

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

#78
post #50

Earlier quoted context omitted.

Going by stackoverflow surveys, the majority of younger engineers would be happier to see it implemented than not, regardless of whether they've even used the language before.

The "most loved" statistic (which they have since renamed) counts people who have used Rust before, and want to continue using it. Unless you're suggesting that they're all lying, I don't see how that connects to "regardless of whether they've even used the langauge." Furthermore, at least in 2023, only ~25% of respondants are under 25. I'm not sure what counts as "younger" to you, but 37% are over 35, so it would se…

[flagged]

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

#79
post #39
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…

Try Zig as a C replacement.

Does Zig run on everything C can, including weird devices?[0]

If the answer is still No, then it can't replace C.

0: https://en.wikipedia.org/wiki/Small_Device_C_Compiler

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

#80

"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…

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 on top of future).

So, someone may like exceptions and green threads more than `Result` and `async` (and this is a completely valid PoV, even though I personally like the explicitness better), but thinking `async` is somehow special is just a conceptual mistake.

Edit to give an little more substance to the parallelism:

If you want to call a fallible function inside an infallible one, you MUST handle the result. If you want to use `?` then your function MUST return a Result.

Symmetrically, if you want to call an async function from a non-async one, you MUST `spawn` the future. If you want to use `await` then your function MUST be async.

The only practical difference between async functions and functions returning a `Result` is that `Future` is a trait, not a struct like `Result` (and that means that your future may have a lifetime that's not visible in your function definition, which is an endless source of confusion for beginners).

Post reply on HN