45 ms·

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

250 points by rhaen 3y ago

Ygg2 3y ago
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.
- Macha 3y ago
  I think Google has a lot of C++ programmers who may have assumed they'd have to use unsafe so they could continue to write everything like they did in C++ (much like many refuse to use features that aren't from ancient versions of C when writing C++), but then likely in practice ended up writing much less unsafe code than they thought they would.
- Animats 3y ago
  That can be a real problem. It's quite possible to reach a point in Rust where you have one borrow error that takes days of rewriting to fix. 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.
thesuperbigfrog 3y ago
"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 developers prefer. It would be really nice if the Rust standard library were to get structured concurrency similar to what Ada has: https://en.wikibooks.org/wiki/Ada_Style_Guide/Concurrency https://en.wikibooks.org/wiki/Ada_Style_Guide/Concurrency https://learn.adacore.com/courses/Ada_For_The_CPP_Java_Developer/chapters/11_Concurrency.html https://learn.adacore.com/courses/Ada_For_The_CPP_Java_Devel...
- VWWHFSfQ 3y ago
  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
  - steveklabnik 3y ago
    That is never going to happen, for both good reasons and bad reasons.
    - VWWHFSfQ 3y ago
      Yeah I figured. Fragmentation by design.
      - steveklabnik 3y ago
        One person's "fragmentation" is another's "supporting multiple use cases is important, even if their requirements are divergent."
  - estebank 3y ago
    The Rust team doesn't have its own execution runtime. Tokio is certainly the closest thing to the "default".
  - Animats 3y ago
    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.
    - arijun 3y ago
      Sorry if this is ignorant, but what’s the difference between async and concurrent? Is the problem that async schedules everything itself?
durandal1 3y ago
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.
- larsberg 3y ago
  Gah! Typo there. It's over 50% (66.8%) in 2 months. And over 80% in 4 months. The chart is correct, not the text :facepalm: I'll see about whether I can push an update. Thanks for the catch!
  - larsberg 3y ago
    Actually, it's complicated stuff pulling together two data points: 1) 2/3 of people are confident contributing in 2 months or less 2) And 50% of people are AS PRODUCTIVE IN RUST as they were in their other language within four months Given that #2 is talking about people who are all professional programmers and where only a small percentage of respondents previously knew Rust, that's pretty amazing to me.
- summerlight 3y ago
  I've been studying C++ over 15+ years and still don't feel very productive thanks to the fear of getting paged every releases.
  - criddell 3y ago
    Does Rust give guarantees around paging? Is Rust similar to C++ in that respect?
    - summerlight 3y ago
      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.
estebank 3y ago
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.
- nmlt 3y ago
  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?
  - estebank 3y ago
    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.
    - sanxiyn 3y ago
      I am somewhat pessimistic because LLVM is significantly behind GCC in debug information quality (for example, see https://robert.ocallahan.org/2018/11/comparing-quality-of-debug-information.html https://robert.ocallahan.org/2018/11/comparing-quality-of-de...) and there is limit to what Rust can do about it short of fixing LLVM.
- larsberg 3y ago
  Thanks for all of your work (in addition to that of others) - it really shows! We do encourage people to create minimal repro cases and open bugs whenever possible. And, even more ideally, to consider contributing a PR upstream...
- WaffleIronMaker 3y ago
  I'm a junior developer learning Rust, and I just want to say thank you for all of the work you've put into making the errors high quality. It makes learning the language such a better experience.
bigyikes 3y ago
> 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 codebase might also be more likely to write high quality code in any language, as compared to the average developer (or even average Googler).
- steveklabnik 3y ago
  People used to say "when people are forced to use Rust at their job, they'll start hating it, only hobbyists use it and that's why it's so beloved." Do you really consider people learning Rust on the job to be "Rust adopters" who are partisan? Is anyone who ever uses Rust a "Rust adopter" who is unable to give an unbiased opinion? Who would be able to give that opinion, in your view?
  - izacus 3y ago
    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.
    - steveklabnik 3y ago
      Do you think all 1,000 people that Google referenced here are people who are pushing it into organizational adoption?
      - izacus 3y ago
        Mostly? Yes. Google has more than 120.000 engineers. Those 1000 are less than 1% of engineers. It's like having one Rust dude in a 100 person company. Most of people work in other languages.
softirq 3y ago
> 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 biggest thing is that systems programming still requires a language that gets out of the way so you can focus on very technical problem domains where what the hardware is actually doing really matters. Rust is a language designed to get in your way and force you to create type abstractions. 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. IMO Rust makes this type of programmer more difficult just as C++ does.
- loudmax 3y ago
  Are tracking memory allocation or variable types not pain points for large complicated programs?
  - softirq 3y ago
    In my experience as a kernel programmer tracing allocations isn't the hard part, it's keeping the correct view of hardware state and the different type of mappings at play, be it an MMU or IOMMU device mapping, and register state. Use after free bugs and overflows do happen, but there are more and more tools that come out every year that can find these things in C code, some of them are even hardware based. IMO the code quality of the kernel is very high and the defect rate isn't greater than projects I've worked on that use garbage collection.
- ljlolel 3y ago
  Try Zig as a C replacement.
  - softirq 3y ago
    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 expertise, documentation, and integration that come with established languages. It's also hard to be a true expert at a low level domain and multiple programming languages unless you're willing to give up all of your free time.
epage 3y ago
> 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 graphs? Do they have large individual crates? And so on.
- IshKebab 3y ago
  Yeah most of these results are meaningless without comparison to other languages. Same with the "how quick is it to learn?" what are the equivalent numbers of Go? 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.
  - wredue 3y ago
    [flagged]
  - nicoburns 3y ago
    > Compilation is fairly fast these days. I would say it's faster than C++ feature-for-feature, at least for clean builds. Faster than C++ is of course very faint praise. C++ is also very slow!
  - pjmlp 3y ago
    Only when considering clean builds as building the whole world from scratch. Which we seldom due on most C++ projects, we rather rely on binary libraries and build only our own code. Also when comparing with Delphi, Ada, D, or even Haskell or OCaml, it isn't that great. You might feel like pointing out that Haskell or OCaml can be even slower, which is true, however they package multiple toolchains and a REPL, and as of today Rust still isn't as flexible in having multiple toolchains for different purposes.
hgs3 3y ago
No mention of Carbon? I was under the impression Google was designing Carbon to be their C++ successor?
- howinteresting 3y ago
  Google is a very big company which has many parts that aren't all necessarily aligned.
- Hemospectrum 3y ago
  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.
- estebank 3y ago
  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.
- summerlight 3y ago
  That's more of a moonshot strategy. Rust is more of a safer bet.
- steveklabnik 3y ago
  To put it even more plainly than the others: https://github.com/carbon-language/carbon-lang#project-status 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.
predictabl3 3y ago
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.
- c_crank 3y ago
  [flagged]
  - predictabl3 3y ago
    > 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.
    - c_crank 3y ago
      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.
AtNightWeCode 3y ago
Rust is for sure much easier to learn than some people claim. Some parts of Rust is different but it is not very difficult. I think the ecosystem is the major problem with Rust.
- worik 3y ago
  > I think the ecosystem is the major problem with Rust. How? Explain please
  - AtNightWeCode 3y ago
    I mostly looked at Rust to replace tools written in GO and Webapis written in ASP.NET/C#. In both cases there seems to be options in Rust but not reliable ones. With reliable I mean that it is just too few people involved. Not that it does not work.
pcthrowaway 3y ago
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.
- joshka 3y ago
  >The idea that people might spend 2 months learning rust and become as productive in other languages is frankly unbelievable to me. Upvoted even though I anecdotally disagree with your perspective based on personal experience. I wrote my first line of rust in March this year (just as a hobby), and now am one of the maintainers of a popular TUI framework (Ratatui). I feel just as productive or more than any of the previous languages I've written code in (over the last 30 something years).
  - pcthrowaway 3y ago
    Interesting. I've been learning/using rust for work for the last 3 months. I'm at the point now where I'm productive (took me over a month to even get to that point), but I still feel incredibly slow compared to Typescript. The compilation time doesn't help. Anyway, thanks for the perspective. I'm still skeptical that the survey reflects honest feedback given Google's culture, but perhaps I'm just biased from how long it's been taking myself and the rest of the team to achieve a higher level of productivity
pvorb 3y ago
I really like Rust and all its features, but I have a feeling that people really underestimate the importance of having a fast compiler. Being able to have a subpar compiler error sooner might still make you more productive than having good compiler errors but having to wait for the compiler all the time.

250 points by rhaen 3y ago

Ygg2 3y ago

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.

Macha 3y ago
I think Google has a lot of C++ programmers who may have assumed they'd have to use unsafe so they could continue to write everything like they did in C++ (much like many refuse to use features that aren't from ancient versions of C when writing C++), but then likely in practice ended up writing much less unsafe code than they thought they would.
Animats 3y ago
That can be a real problem. It's quite possible to reach a point in Rust where you have one borrow error that takes days of rewriting to fix. 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.

thesuperbigfrog 3y ago

"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 developers prefer. It would be really nice if the Rust standard library were to get structured concurrency similar to what Ada has: https://en.wikibooks.org/wiki/Ada_Style_Guide/Concurrency https://en.wikibooks.org/wiki/Ada_Style_Guide/Concurrency https://learn.adacore.com/courses/Ada_For_The_CPP_Java_Developer/chapters/11_Concurrency.html https://learn.adacore.com/courses/Ada_For_The_CPP_Java_Devel...

VWWHFSfQ 3y ago
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
- steveklabnik 3y ago
  That is never going to happen, for both good reasons and bad reasons.
  - VWWHFSfQ 3y ago
    Yeah I figured. Fragmentation by design.
    - steveklabnik 3y ago
      One person's "fragmentation" is another's "supporting multiple use cases is important, even if their requirements are divergent."
- estebank 3y ago
  The Rust team doesn't have its own execution runtime. Tokio is certainly the closest thing to the "default".
- Animats 3y ago
  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.
  - arijun 3y ago
    Sorry if this is ignorant, but what’s the difference between async and concurrent? Is the problem that async schedules everything itself?

durandal1 3y ago

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.

larsberg 3y ago
Gah! Typo there. It's over 50% (66.8%) in 2 months. And over 80% in 4 months. The chart is correct, not the text :facepalm: I'll see about whether I can push an update. Thanks for the catch!
- larsberg 3y ago
  Actually, it's complicated stuff pulling together two data points: 1) 2/3 of people are confident contributing in 2 months or less 2) And 50% of people are AS PRODUCTIVE IN RUST as they were in their other language within four months Given that #2 is talking about people who are all professional programmers and where only a small percentage of respondents previously knew Rust, that's pretty amazing to me.
summerlight 3y ago
I've been studying C++ over 15+ years and still don't feel very productive thanks to the fear of getting paged every releases.
- criddell 3y ago
  Does Rust give guarantees around paging? Is Rust similar to C++ in that respect?
  - summerlight 3y ago
    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.

estebank 3y ago

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.

nmlt 3y ago
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?
- estebank 3y ago
  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.
  - sanxiyn 3y ago
    I am somewhat pessimistic because LLVM is significantly behind GCC in debug information quality (for example, see https://robert.ocallahan.org/2018/11/comparing-quality-of-debug-information.html https://robert.ocallahan.org/2018/11/comparing-quality-of-de...) and there is limit to what Rust can do about it short of fixing LLVM.
larsberg 3y ago
Thanks for all of your work (in addition to that of others) - it really shows! We do encourage people to create minimal repro cases and open bugs whenever possible. And, even more ideally, to consider contributing a PR upstream...
WaffleIronMaker 3y ago
I'm a junior developer learning Rust, and I just want to say thank you for all of the work you've put into making the errors high quality. It makes learning the language such a better experience.

bigyikes 3y ago

> 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 codebase might also be more likely to write high quality code in any language, as compared to the average developer (or even average Googler).

steveklabnik 3y ago
People used to say "when people are forced to use Rust at their job, they'll start hating it, only hobbyists use it and that's why it's so beloved." Do you really consider people learning Rust on the job to be "Rust adopters" who are partisan? Is anyone who ever uses Rust a "Rust adopter" who is unable to give an unbiased opinion? Who would be able to give that opinion, in your view?
- izacus 3y ago
  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.
  - steveklabnik 3y ago
    Do you think all 1,000 people that Google referenced here are people who are pushing it into organizational adoption?
    - izacus 3y ago
      Mostly? Yes. Google has more than 120.000 engineers. Those 1000 are less than 1% of engineers. It's like having one Rust dude in a 100 person company. Most of people work in other languages.

softirq 3y ago

> 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 biggest thing is that systems programming still requires a language that gets out of the way so you can focus on very technical problem domains where what the hardware is actually doing really matters. Rust is a language designed to get in your way and force you to create type abstractions. 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. IMO Rust makes this type of programmer more difficult just as C++ does.

loudmax 3y ago
Are tracking memory allocation or variable types not pain points for large complicated programs?
- softirq 3y ago
  In my experience as a kernel programmer tracing allocations isn't the hard part, it's keeping the correct view of hardware state and the different type of mappings at play, be it an MMU or IOMMU device mapping, and register state. Use after free bugs and overflows do happen, but there are more and more tools that come out every year that can find these things in C code, some of them are even hardware based. IMO the code quality of the kernel is very high and the defect rate isn't greater than projects I've worked on that use garbage collection.
ljlolel 3y ago
Try Zig as a C replacement.
- softirq 3y ago
  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 expertise, documentation, and integration that come with established languages. It's also hard to be a true expert at a low level domain and multiple programming languages unless you're willing to give up all of your free time.

epage 3y ago

> 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 graphs? Do they have large individual crates? And so on.

IshKebab 3y ago
Yeah most of these results are meaningless without comparison to other languages. Same with the "how quick is it to learn?" what are the equivalent numbers of Go? 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.
- wredue 3y ago
  [flagged]
- nicoburns 3y ago
  > Compilation is fairly fast these days. I would say it's faster than C++ feature-for-feature, at least for clean builds. Faster than C++ is of course very faint praise. C++ is also very slow!
- pjmlp 3y ago
  Only when considering clean builds as building the whole world from scratch. Which we seldom due on most C++ projects, we rather rely on binary libraries and build only our own code. Also when comparing with Delphi, Ada, D, or even Haskell or OCaml, it isn't that great. You might feel like pointing out that Haskell or OCaml can be even slower, which is true, however they package multiple toolchains and a REPL, and as of today Rust still isn't as flexible in having multiple toolchains for different purposes.

hgs3 3y ago

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

howinteresting 3y ago
Google is a very big company which has many parts that aren't all necessarily aligned.
Hemospectrum 3y ago
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.
estebank 3y ago
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.
summerlight 3y ago
That's more of a moonshot strategy. Rust is more of a safer bet.
steveklabnik 3y ago
To put it even more plainly than the others: https://github.com/carbon-language/carbon-lang#project-status 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.

predictabl3 3y ago

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.

c_crank 3y ago
[flagged]
- predictabl3 3y ago
  > 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.
  - c_crank 3y ago
    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.

AtNightWeCode 3y ago

Rust is for sure much easier to learn than some people claim. Some parts of Rust is different but it is not very difficult. I think the ecosystem is the major problem with Rust.

worik 3y ago
> I think the ecosystem is the major problem with Rust. How? Explain please
- AtNightWeCode 3y ago
  I mostly looked at Rust to replace tools written in GO and Webapis written in ASP.NET/C#. In both cases there seems to be options in Rust but not reliable ones. With reliable I mean that it is just too few people involved. Not that it does not work.

pcthrowaway 3y ago

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.

joshka 3y ago
>The idea that people might spend 2 months learning rust and become as productive in other languages is frankly unbelievable to me. Upvoted even though I anecdotally disagree with your perspective based on personal experience. I wrote my first line of rust in March this year (just as a hobby), and now am one of the maintainers of a popular TUI framework (Ratatui). I feel just as productive or more than any of the previous languages I've written code in (over the last 30 something years).
- pcthrowaway 3y ago
  Interesting. I've been learning/using rust for work for the last 3 months. I'm at the point now where I'm productive (took me over a month to even get to that point), but I still feel incredibly slow compared to Typescript. The compilation time doesn't help. Anyway, thanks for the perspective. I'm still skeptical that the survey reflects honest feedback given Google's culture, but perhaps I'm just biased from how long it's been taking myself and the rest of the team to achieve a higher level of productivity

pvorb 3y ago

I really like Rust and all its features, but I have a feeling that people really underestimate the importance of having a fast compiler. Being able to have a subpar compiler error sooner might still make you more productive than having good compiler errors but having to wait for the compiler all the time.