41–50 of 233 posts
Great post. Aligns with my experiences. Although who thought unsafe would be bigger hurdle than borrowing. I do wish to know did Rust impact their velocity and by how much.
This tends to lead to people putting in unsafe code to work around a borrow restriction. I don't do that, but I don't have deadlines.
> 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…
Are tracking memory allocation or variable types not pain points for large complicated programs?
"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…
(Generally, I avoid this problem these days by avoiding threads in favor of other abstractions or multiple processes communicating over an RPC channel).
> 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…
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 don't think it's reasonable to add that to the type system (and the type system right now doesn't know about DMA).
Earlier quoted context omitted.
People who are adopting Rust now at their jobs are in most majority people who are so keen on using Rust to push it into organizational adoption. Most companies don't yet have legacy Rust codebases on which people are told to work, but instead choose to work on. This creates a self-selection, where Rust lovers work on Rust projects and report utopian happy-go-lucky times. It's normal for most technologies.
Do you think all 1,000 people that Google referenced here are people who are pushing it into organizational adoption?
Most of people work in other languages.
> Rumor 2: The Rust compiler is not as fast as people would like – Confirmed ! I wish there was more context to these, especially this one. For example, how much of this is perception compared to what they were used to (go?, Python?, C++?)? Or is it "any waiting is bad"? From an improvement perspective, I'd also love to know why their builds are slow. Is it proc-macro heavy? Do they have wide and deep dependency grap…
Based on my experience they're overselling how easy it is to learn and underselling the compiler speed.
Compilation is fairly fast these days. I would say it's faster than C++ feature-for-feature, at least for clean builds.
But on the other hand most people could probably learn all of Go in the time it takes to begin to understand the borrow checker.
> Rumor 2: The Rust compiler is not as fast as people would like – Confirmed ! I wish there was more context to these, especially this one. For example, how much of this is perception compared to what they were used to (go?, Python?, C++?)? Or is it "any waiting is bad"? From an improvement perspective, I'd also love to know why their builds are slow. Is it proc-macro heavy? Do they have wide and deep dependency grap…
Rust itself might as well be considered a highly constrained macro language at this point.
> 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…
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.
In fact it's frankly unbelievable, I'd have to imagine these guys are coming from a C++ background.
Earlier quoted context omitted.
People who are adopting Rust now at their jobs are in most majority people who are so keen on using Rust to push it into organizational adoption. Most companies don't yet have legacy Rust codebases on which people are told to work, but instead choose to work on. This creates a self-selection, where Rust lovers work on Rust projects and report utopian happy-go-lucky times. It's normal for most technologies.
Do you think all 1,000 people that Google referenced here are people who are pushing it into organizational adoption?