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

111–120 of 233 posts

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

#111

Post by pcthrowaway »

The idea that people might spend 2 months learning rust and become as productive in other languages is frankly unbelievable to me. If they're coming from any background other than C/C++ I'm suspicious that people can even become as productive in general (which is fine, reduced productivity is in my mind one of the trade-offs you make for memory safety and increased performance when choosing Rust)

But this is Google, and the people doing self-assessments were likely influenced by the context of operating in cut-throat bureaucracy where self-aggrandisement is a requisite to career progression within the org.

Whether or not this survey was tied to any performance evaluation (and from the article it's not even clear that it wasn't) the relevant thing is whether the employees knew without a doubt that they weren't going to be compared against one another based on their self-assessment

edit: I'm curious if the people downvoting disagree with my assertion that the survey methodology is flawed, or the assertion that it's unlikely to become as competent in rust in 2 months as you would be in languages you have years of experience with.

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

#112

Post by sanxiyn »

VWWHFSfQ wrote: post #5
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…

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.

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

#113

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

#114

Post by thesuperbigfrog »

shellac wrote: post #53
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…

For many languages I absolutely agree: stackful coroutines are the way to go since the programmer experience is much smoother, with fewer hiccups like having different kinds of functions, or being unable to yield in loops. Lua, Go, and now Java got this right; python, javascript, and c# have to live with a bit of a mess. But Rust is not a language which can dictate its execution environment. It needs to be able to ex…

>> But Rust is not a language which can dictate its execution environment. It needs to be able to exist in a C-ish world, and that's not something that supports yielding. It's a shame, but at least you can write kernel modules in Rust.

Ada is also used in embedded and low-level environments where the execution environment can be limited. The way that Ada "gets around" such limitations is through language "annexes". Annexes are optional language extensions for specialized use cases:

https://www.cambridge.org/core/books/abs/programming-in-ada-...

http://www.ada-auth.org/standards/22rm/html/RM-1-1-2.html

Rust partially does this already with [no_std] (https://docs.rust-embedded.org/book/intro/no-std.html), so the concept is not too different.

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

#116

Post by steveklabnik »

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.

I do not have as strong of feelings as your parent, but:

1. A lot of the APIs make use of the typestate pattern, which is nice, but also very verbose, and might turn many people off.

2. The generated API documentation for the lower level crates relies on you knowing the feel for how it generates the various APIs. It can take some time to get used to, especially if you're used to the better documentation of the broader ecosystem.

3. A bunch of the ecosystem crates assume the "I am running one program in ring0" kind of thing, and not "I have an RTOS" sort of case. See the discussion in https://github.com/rust-embedded/cortex-m/issues/233 for example.

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

#117

Post by verdagon »

brigadier132 wrote: post #92
verdagon wrote: post #88

Earlier quoted context omitted.

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.

There are a lot of ways, but I think the most promising ones involve regions. We do this a lot manually in Rust, but a language could make this a first class concept. Some examples:

* Vale combines generational references and linear types with regions to eliminate overhead.

* Verona lets you divide memory into regions which can be backed by either arena allocation or GC. I think this is promising because for most GC regions you can completely avoid the collections.

* Cone lets you put borrow checking on top of any aliasing memory strategy, so could be something like the best of all these worlds.

* No language is doing this yet, but RC plus regions to eliminate the refcounts, then adding in value types for better cache usage, could be a real winner.

On phone so it's hard to get links, but you get the idea. The nice thing about regions is that they allow composing borrowing and shared mutability, something that the borrow checker struggles a bit with. Regions let us alias freely, and then freeze an entire area of memory all at once. Not that Rust isnt a good approach (it is!) but there are some easier techniques on the horizon IMO.

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

#118

Post by steveklabnik »

hgs3 wrote: post #57

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

To put it even more plainly than the others: https://github.com/carbon-language/carbon-lang#project-statu...

> Carbon Language is currently an experimental project. There is no working compiler or toolchain. You can see the demo interpreter for Carbon on compiler-explorer.com.

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

#119

Post by Ygg2 »

predictabl3 wrote: post #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 ra…

“It is difficult to get a man to understand something, when his salary depends on his not understanding it.”

― Upton Sinclair

Amount of dislike on HN for Rust is frankly unexpected, one part might be response to evangelization, but I've seen more hate on evangelization than actual evangelization. Sure, Rust ain't perfect but like C++ is even more imperfect. So that leaves me with job security in C++.

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

#120

Post by Animats »

flylikeabanana wrote: post #106
Animats wrote: post #77

Earlier quoted context omitted.

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

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 robotics, but is not something often seen in web-related software.

Post reply on HN