Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022 • Hacker News Board

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

#151

Post by kramerger » Tue, Jun 27, 2023, 9:41 PM UTC

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.

Every time I play with embedded Rust I get this feeling that some of the people driving it are more into language esthetics and don't have experience in real-world embedded systems.

For example, I see inefficient patterns that are common in frontend world but have no place in an embedded system being promoted as "proper" way of doing things.

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

#152

Post by softirq » Tue, Jun 27, 2023, 9:44 PM UTC

jenadine wrote: post #136

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.

I think you missed the part about systems programming. When you are programming real hardware, the focus is entirely on low level details. You need to know the commands being sent to the device, the device state, and the ownership of resources by the device (which Rust doesn't solve for) are correct.

The innovation of Rust is the borrow checker, which is primarily of interest to systems programmers. If your primary interest is highly abstracted business logic, there are tools that don't require manual memory management or being pedantic about the different types of strings. You could just use Go, Java, Haskell, Python, etc.

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

#153

Post by predictabl3 » Tue, Jun 27, 2023, 9:44 PM UTC

c_crank wrote: post #89

predictabl3 wrote: post #87

Earlier quoted context omitted.

> But the stream of very angry developers with a bone to pick about 'safety' is new. /me looks around for the Boogeyman... Not seeing it. I'm not angry, but I guess I do have some emotions when I use critical software, written in C by devs who claim they can write perfect C, and I get segfaults. > Many of its features and promises have been done in other languages Also, no, despite often being repeated by those insis…

Ada, and Cyclone, and Misra C, and various other C formalization tools. It also borrows a lot of the ML stuff from... ML. Engineers who had safety as their prime goal can and often did use Ada and other tools to achieve that goal. The average Rust developer does not seem to be concerned with safety as a goal for the product specification, but rather as some kind of thematic justification divorced from the actual engi…

Actix was chalk full of not just unnecessary, but showably unsound usages of unsafe. And then resisted fixing it, and then after another review months later was found to still contain such deficits.

Which, ironically, would have been even worse, written with the same level of care, in C.

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

#154

Post by steveklabnik » Tue, Jun 27, 2023, 9:48 PM UTC

dureuill wrote: post #150

steveklabnik wrote: post #56

Earlier quoted context omitted.

Anecdotally, C++ developers often have a harder time coming to Rust than folks from a more scripty background. They have to unlearn things, and that can be harder than learning things. You can see similar opinions expressed in this thread, like here, for example: https://news.ycombinator.com/item?id=36496654

Really? Coming from C++, learning Rust felt very natural and welcome because it put a name and a structure to the mental model I had been using to keep a semblance of sanity while doing C++. Maybe learning primarily with C++11 was a factor?

It's a broad strokes kind of thing, not a universal thing. To be honest I think it has more to do with attitudes towards the language and compiler that tend to be more prevalent in C and C++ circles.

That is, a lot of people expect that the compiler is a tool that must do what they say, not a collaborative partner. Back in the IRC days, people used to join, and be like "Rust won't let me do X. X is obviously okay. How do I get the compiler to shut up and do X?" and the reply would be something like "what if there was another thread? that's what Rust is saving you from" or "Rust's pointer rules are different than the language you're used to."

Whereas folks from scripty backgrounds don't have preconceived notions of "I should be able to do this in this way," and so tend to trust the compiler more. Heck, that's why a lot of them are learning Rust instead of C; they know the compiler can help them out, and C's compilers cannot to the same degree.

Now, that doesn't mean that scripty people don't struggle, or that C and C++ developers don't have their own advantages in learning. Just that I don't think it's straightforward to say who has the overall easier time. It's more of a "having learned something like C or C++ does not universally advantage you."

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

#155

Post by dureuill » Tue, Jun 27, 2023, 9:59 PM UTC

steveklabnik wrote: post #154

dureuill wrote: post #150

Earlier quoted context omitted.

Really? Coming from C++, learning Rust felt very natural and welcome because it put a name and a structure to the mental model I had been using to keep a semblance of sanity while doing C++. Maybe learning primarily with C++11 was a factor?

It's a broad strokes kind of thing, not a universal thing. To be honest I think it has more to do with attitudes towards the language and compiler that tend to be more prevalent in C and C++ circles. That is, a lot of people expect that the compiler is a tool that must do what they say, not a collaborative partner. Back in the IRC days, people used to join, and be like "Rust won't let me do X. X is obviously okay. Ho…

Thanks for the elaboration. Now I'm wondering if this hasn't something to do with bottom-up people vs top-down people and their natural affinity towards lower level or higher level languages.

I'm very top-down, always starting by sketching the API I'd like to see for the feature, and then filling in the implementation. A lot of people I know from C++ are bottom-up, they toy with the implementation and then go up to the API. I found that what they like in systems programming is being close to the machine, while my interest lies in the OS boundaries and interfaces, not really the hardware.

I'm thinking maybe those different ways of approaching programming make it easier or harder to learn rust.

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

#156

Post by valzam » Tue, Jun 27, 2023, 10:04 PM UTC

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…

The main difference to me is that Async/await tends to permeate your whole codebase. Once one part of the system is Async/await everything is. With Go I can write most of my code synchronously and maybe somewhere down the stack make 3 HTTP calls in parallel without having to change anything about the calling functions.

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

#157

Post by steveklabnik » Tue, Jun 27, 2023, 10:09 PM UTC

dureuill wrote: post #155

steveklabnik wrote: post #154

Earlier quoted context omitted.

It's a broad strokes kind of thing, not a universal thing. To be honest I think it has more to do with attitudes towards the language and compiler that tend to be more prevalent in C and C++ circles. That is, a lot of people expect that the compiler is a tool that must do what they say, not a collaborative partner. Back in the IRC days, people used to join, and be like "Rust won't let me do X. X is obviously okay. Ho…

Thanks for the elaboration. Now I'm wondering if this hasn't something to do with bottom-up people vs top-down people and their natural affinity towards lower level or higher level languages. I'm very top-down, always starting by sketching the API I'd like to see for the feature, and then filling in the implementation. A lot of people I know from C++ are bottom-up, they toy with the implementation and then go up to t…

I think that's possibly insightful, yeah. A similar effect: a lot of people say "Rust is bad for exploratory programming because the compiler gets in your way." For me, it's fantastic for exploratory programming specifically because when I change something, it gives me a list of the other things I need to change! That's huge! But for others, it seems to harsh their buzz. I don't know how to reconcile these opinions other than "they're opinions and different people are different."

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

#158

Post by summerlight » Tue, Jun 27, 2023, 10:12 PM UTC

criddell wrote: post #126

brigadier132 wrote: post #93

Earlier quoted context omitted.

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

Aha, I should've mentioned that it's about getting paged on weekend...

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

#159

Post by littlestymaar » Tue, Jun 27, 2023, 10:19 PM UTC

valzam wrote: post #156

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…

The main difference to me is that Async/await tends to permeate your whole codebase. Once one part of the system is Async/await everything is. With Go I can write most of my code synchronously and maybe somewhere down the stack make 3 HTTP calls in parallel without having to change anything about the calling functions.

> make 3 HTTP calls in parallel without having to change anything about the calling functions.

Exception that now you need to bubble up the error condition comming from these functions (if you function didn't have other error already).

And in fact, adding those call do change things about how the calling function is run (yields point are inserted and the function isn't being run sequentially anymore), it's just not visible in the code, exactly like exceptions vs explicit error return values.

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

#160

Post by shrimp_emoji » Tue, Jun 27, 2023, 10:26 PM UTC

steveklabnik wrote: post #154

dureuill wrote: post #150

Earlier quoted context omitted.

Really? Coming from C++, learning Rust felt very natural and welcome because it put a name and a structure to the mental model I had been using to keep a semblance of sanity while doing C++. Maybe learning primarily with C++11 was a factor?

It's a broad strokes kind of thing, not a universal thing. To be honest I think it has more to do with attitudes towards the language and compiler that tend to be more prevalent in C and C++ circles. That is, a lot of people expect that the compiler is a tool that must do what they say, not a collaborative partner. Back in the IRC days, people used to join, and be like "Rust won't let me do X. X is obviously okay. Ho…

Ha. Given that the C and C++ compilers optimize your code by inferring undefined behavior and other crazy stuff like that, it's funny to imagine you're not just playing with just another code generator. :p

(In fact, if you decide to be responsible about what you're telling your poor compiler to do and use a `size_t i` instead of an `int i` in your for loop, since iteration can never go negative and, if overflow happens, overflow on a signed type is worse since that's UB, I think you just made your for loop slower since all the optimizations the compiler was going to generate from inferring that iteration won't be infinite because that would overflow the `int i` and that would be UB so it can just ignore the possibility that the iteration would be infite went out the window and...man I really need to switch to Rust.)

((I've pretty painlessly learned and love Rust, btw. I'm still using C at home lately though cuz... masochism.))