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

81–90 of 233 posts

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

#81

Post by the__alchemist »

dannymi wrote: post #44
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…

>Adding too many abstraction can be exceedingly dangerous in an environment where not having a full view of how memory and hardware registers are laid out leads to even worse errors than just buffer overflows. svd2rust is pretty good for having safe abstractions for hardware registers. That said, as an example, no, the type system doesn't prevent you from deallocating your DMA buffer while the hardware is using it--I…

Garbage in, garbage out! Svd2rust is a great tool, but the patching process (YAMLs) is currently not user friendly due to silent failures. Root cause is hardware makers putting out bugged SVDs that need patching.

I think re DMA buffer lifetimes, the easy approach is static buffers; they never drop.

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

#82

Post by c_crank »

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…

[flagged]

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

#83

Post by [deleted] »

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…

[deleted]

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

#84

Post by criddell »

summerlight wrote: post #70
criddell wrote: post #54

Earlier quoted context omitted.

Does Rust give guarantees around paging? Is Rust similar to C++ in that respect?

At least you won't get paged due to some weird memory bugs. Yes, this happens quite frequently. Worse, it's usually not something local to a single change but interaction across seemingly safe changes.

Is well written Rust code better with respect to paging than well written C++ code?

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

#85

Post by 59nadir »

bfrog wrote: post #65
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 and do use simple pointers in Rust, nothing prevents this. The abstractions can be more used like static interfaces you want to reuse. E.g. a byte stream interface, a regmap interface, etc.

I think there have been a few posts pointing out that the ergonomics around using just pointers in Rust is lacking severely in comparison to languages like Zig and Odin.

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

#86

Post by estebank »

hgs3 wrote: post #57

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

Without trying to sound dismissive, Rust is production ready today, Carbon isn't. Even if Carbon was significantly better, that alone accounts for the adoption of Rust and not Carbon today.

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

#87

Post by predictabl3 »

c_crank wrote: post #82
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…

[flagged]

> 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 insisting Rust is pure hype, this is not meaningfully true (of course the sentence structure allows for any language having a less impactful subset to qualify). I suspect you'd list them otherwise. I'll give you Ada, but again, not sure that's really salient to the point I'm making.

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

#88

Post by verdagon »

Kranar wrote: post #49
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.

Four months to become as proficient in a memory safe, data race safe, and high performance language as in other languages seems like an astonishing accomplishment. In fact it's frankly unbelievable, I'd have to imagine these guys are coming from a C++ background.

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 for getting these aspects. But there are almost a dozen other methods out there for getting memory safety besides RC, GC, or borrow checking.

I rather think that these other approaches aren't mature enough yet to enter the mainstream, and we haven't seen them yet.

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

#89

Post by c_crank »

predictabl3 wrote: post #87
c_crank wrote: post #82

Earlier quoted context omitted.

[flagged]

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

edit: the bogeyman you mention are the developers who flamed Actix, and who make posts saying that unsafe blocks rely on a social contract.

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

#90

Post by hbn »

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…

Also since it's a young language, a lot of these people are probably writing in a newer codebase that doesn't have 15 years of early fundamental bad decisions and hacky refactors to make it painful to work in.
Post reply on HN