11 ms·

Rust Survey 2021 Results

166 points by surfingninja 5y ago

alfiedotwtf 5y ago
I found this surprising... 59% of respondents sounds huge! "Rust can now safely be classified as a language used by people in professional settings. Of those respondents using Rust, 59% use it at least occasionally at work with 23% using Rust for the majority of their coding. This is a large increase over last year where only 42% of respondents used Rust at work."
- adgjlsfhk1 5y ago
  I don't think this is entirely surprising. Rust isn't many people's first language. People who learn it, mostly do because they have become fed up with the unreliability (typically of C). This creates a bias towards people who are more experienced and have more organizational power. Also, language surveys tend to be biased towards power users which can shift the sample significantly. For example, the Julia survey from 2021 only had 25% Windows users, while Julia binaries are something like 70% windows.
  - psfried 5y ago
    That's an interesting statistic about Julia. Makes me curious what the stats would be for Rust.
  - eminence32 5y ago
    Your comment about people with "more organizational power" may be an accurate reflection of things, but I don't think it's necessary to explain this increase in people using rust at work. It could be that more and more people are using rust for small ad-hoc scripts, which might have been written in python or java before. These small things might not require any organizational approval, but people might be more comfortable now using rust (either because their own skills in the language have improved, or because they feel more comfortable justifying the use of rust, even if they don't need to).
    - pornel 5y ago
      I think that's a genuine use of Rust for Real Work™. For example, Cloudflare went from using Rust for one project 3 years ago, to depending on Rust in core components and using it by default for almost all new development.
  - zozbot234 5y ago
    > Rust isn't many people's first language. Has anyone actually tried to teach/learn Rust as a first programming language? People did it with C++ (and even C) at some point, is Rust that much more problematic? (And the attempt might even inform new convenience features: the proc macro system gives Rust a lot of inherent flexibility there.)
    - adgjlsfhk1 5y ago
      People have. In my opinion, it's a bad idea. I think that to appreciate Rust's design, you pretty much have to be familiar with the awfulness of memory leaks in C/C++ (and it helps if you have experience trying to make a program in a GCed language hit strict latency requirements). I think Rust's design is genius, but I think the first language you learn should be an easy language with a GC (there's enough hard parts of learning your first PL). The next step is to learn C (because it's beautiful but fatally flawed), and only after you have learned why manual allocs and frees suck, should you learn Rust.
      - zozbot234 5y ago
        The easiest way to conceptualize Rust's design at a basic level (suitable for first-time learners) is probably as a glorified functional language, where you initially pass everything by value (courtesy of .clone()) aside from shared immutable data (passed via shared references). Mutable borrowing can then be introduced next, followed by the "cell" patterns/constructs for shared mutable state. Not altogether trivial, but it seems like it could work. And the compiler would protect against many errors along the way, that bite C/C++ coders.
      - CornCobs 5y ago
        I agree. I think Rust (or at least many tutorials of Rust) paper over ownership as something the compiler deals with for you but I think that's false. You have to think about memory and ownership. Only when I started using C++ where you have to think about the same things but without the static checking do I appreciate the ability to statically check and enforce things like moving and borrowing
      - 5y ago
- spenczar5 5y ago
  I write a bit of Rust, but not for work, and I never heard about this survey. I think that's probably common - the more Rust you write, the more likely it is that you fill out the survey, so the sample is probably very biased towards people who work with it a lot (ie, professionally). Or - you could describe that as biased, at least. Alternatively, maybe the intent of these language surveys is exactly to find out what committed power-users think. Either way, interpreting results from language surveys is tricky business.
  - apendleton 5y ago
    I think it's true that surveys like this will skew towards more serious/dedicated practitioners, but in addition to professionals, the Rust community has also at various times attracted people who were excited about bleeding-edge things, or PLT/type-theory people, etc., and I think this survey probably does show a shift in the user base towards work-a-day users and away from these other groups. (Or more succinctly: the absolute numbers are probably meaningless, but the trends are maybe worth watching.)
  - estebank 5y ago
    The self-selection bias effect is why the survey on isolation is not enough to derive meaning on its own. But, looking at the trends over time as the yearly survey is analyzed and compared with the previous ones is useful.
FullyFunctional 5y ago
I'm definitely in the camp that worry about the feature/complexity creep. I saw it with Haskell. Haskell 98 is a pretty nice and simple language. GHC Haskell is a monster. This matters when you try to read other people code and the overuse of experimental cool new features becomes a major burden for comprehension. Rust is already a very large language and for intrinsic reasons pile on a load more complexity than Haskell (just look at the iterators). I write this as a fan and advocate of Rust.
- ekidd 5y ago
  I feel like the pace of Rust language evolution slowed down significantly after the 2018 edition and the work on async shortly thereafter. Most of the more recent language changes feel like pretty minor ergonomic improvements, things which always should have worked. I suppose we got const functions (can be evaluated at compile time), and const generics (allow you define fixed-length vectors for size N). But those features are well established in other languages and they don't interact much with anything else. And I'm sure I'm forgetting a few things, but that's sort of my point—subjectively, not a lot has changed for me recently. What I have seen is a lot of good work in the larger ecosystem. And the tooling continues to improve.
- zozbot234 5y ago
  No worries, Rust has a looong way to go before they reach C++ levels. And the editions system even makes it feasible to pursue some ex-post simplification, though that requires a number of years to complete and cross-linking across editions must be preserved regardless.
- stjohnswarts 5y ago
  Alas I had fun with rust and made some small apps but as I got deeper I just got scared off by the learning curve. I'm kind of over the hump with c++, javascript and python and I just couldn't do it again. Maybe I will revisit in a few years if it actually slows down.
  - pie_flavor 5y ago
    The language evolution speed has nothing whatsoever to do with the learning curve - there's like two major features a year, one of which is only for advanced users. The rolling release cycle just means the tiny incremental improvements arrive sooner. The learning curve has been in place since 1.0 and it only gets harder the more times you give up.
Animats 5y ago
The percentage of people using Rust continues to rise. How was the sample selected?
- Epskampie 5y ago
  Why, selfselected of course! How surprising that people who still chose to fill out a rust survey in 2021 increasingly use rust! ;-) On topic, i’d like to try out rust, but can’t find good cause in my daily webdev needs.
  - Animats 5y ago
    Although I write mostly in Rust, when I have to do some web server side work, I use Go. Go was designed at Google for their server-side applications, and it's well-suited to that. All the expected libraries have seen very heavy use and are unlikely to have unexpected problems. Goroutines handle the job of both async and threads, simplifying concurrency. Rust is overkill for such work. Rust is for complicated problems where both performance and safety matter. Web browsers. Databases. Operating systems. Industrial control. I'm writing a client for a virtual world in Rust. It's much easier to do complex concurrency in Rust than in C++. Use the right tool for the job.
LAC-Tech 5y ago
I have some time between contracts and I've found myself learning rust. Pros: - Sum types. I am an OO apologist, but trying to use classes in C++ is an exercise in frustration. Sum types map very well to union types and are a better fit for systems programming. - Unit tests built right into the language - it seems like a small thing but it's a hassle in most languages to choose a library, set it up etc. - The above, combined with cargo-watch [0]. With the right flags, you hit save, and your tests all run. It's a god-send. - Ecosystem is pretty big. I can find most things I need. - Discord channel is nice. I was put off a bit by the Rust Evangelism Strikeforce back in the day, but so far everyone is pretty chill. - Options & Results in the standard library. All languages should have this Cons: - I find it hard to transfer knowledge of C to rust, because they use different terminology. - Docs can be confusing to read because every method on collections like `map` or `filter` returns its own Trait. People have explained why this is to me a couple of times but I still haven't gotten it through my head. - You still have to think about memory and pointers. Not always a bad thing, but it is an extra dimension when solving a problem. Overall I'm powering through. I'm hoping to get to a point where Rust is an obvious choice for anything that involves finer control of memory. [0] https://github.com/watchexec/cargo-watch https://github.com/watchexec/cargo-watch
- berkut 5y ago
  As someone with 20 years of C++ experience, in industries from everything from real-time systems through to low-level HPC graphics on CPU/GPU (currently in VFX), I really don't understand the hatred for OO programming, and I must be either missing something, or being lucky with the codebases I'm working on... It's a tool for encapsulation: you can get into trouble with it, but I'd argue the same is possible with many things - it's how well you use it. You can easily use state composition in C++ if you want, and generally (multiple inheritance can cause issues in some cases) you can use interface classes as well. And as someone who's been learning Rust for the past 6+ months, I've found that of the three new projects I started which I started in Rust instead of C++/Python over the past 4 months, Composition actually worked quite less well (it's quite verbose due to all the plumbing needed to connect things up) than if I could have used OO interitance in many situations where I wanted specialisation - i.e. hierarchy behaviour traits that had both common shared state and functionality AND specialised state and functionality. Thankfully Traits can at least have default implementations - if not, things would have been a bit worse. To be clear: there's a lot to like in Rust though.
boberoni 5y ago
I'm curious about the methodology of this survey. The first thing I think about when reading survey results is the possibility of selection bias.
- dgb23 5y ago
  Ah yes these things are not scientific studies. Just read them as tech culture with diagrams and numbers.
danielscrubs 5y ago
How's the compiler speed? I've been so burnt out on hobby programming on SwiftUI because of the horrendous long compilation times. Makes me long for some Pascal. :)
- zozbot234 5y ago
  It depends on what you're doing. Rust is not uniformly slow to compile, the slowness is associated to a few specific features like generics and macros. (Good generic code should delegate to a less-generic implementation as early as possible. Hopefully full "const" generics will soon make this feasible in more cases.)
- Tobu 5y ago
  The compiler itself is fine and its performance well managed, with weekly perf triage and efforts driven by profiling[1], but because adding dependencies is effortless and vetting them isn't, dependency trees tend to get large if not careful. In particular, widely used proc-macros (code transformations pulled by popular packages like serde, clap, tokio…) add very heavy dependencies (like syn) to the critical path. As a consequence, downloading and installing a tool from source is often a poor experience. As far as development experience, cargo clippy / cargo check / rust-analyzer give you the feedback you need without involving codegen (except for any proc-macros in your dependency tree), and incremental compilation makes codegen faster after the first build. Work is also ongoing[2] to make debug-quality codegen faster. Here is a quality article on the art of keeping a Rust project fast to build: https://matklad.github.io/2021/09/04/fast-rust-builds.html https://matklad.github.io/2021/09/04/fast-rust-builds.html The overall series on organizing a large project is worth reading as well: https://matklad.github.io/2021/09/05/Rust100k.html https://matklad.github.io/2021/09/05/Rust100k.html [1]: https://nnethercote.github.io/2021/11/12/the-rust-compiler-has-gotten-faster-again.html https://nnethercote.github.io/2021/11/12/the-rust-compiler-h... [2]: https://bjorn3.github.io/ https://bjorn3.github.io/
- edflsafoiewq 5y ago
  IMO the other responses downplay it. Compile times are not good.
cryptojournal 5y ago
Lovely Survey :)
zerr 5y ago
Pity that it is hard to find Rust jobs outside blockchain.
pornel 5y ago
If you want more data, I've compiled statistics from crates.io: https://lib.rs/stats https://lib.rs/stats
dgb23 5y ago
Rust is a terribly slow language to write in, especially if you’re trying to fight it in any way - because you‘ll lose. It’s verbose and quite ugly as it tries to appeal to C family programmers while being expression and pattern based. When trying to resolve ownership issues with closures the first time, you‘ll be doubting whether Rust is in fact a language or just a sick elaborate joke that tries to mock you for even considering to use it. But with every concept learned you feel accomplished and start to develop Stockholm syndrome. The Rust compiler beats you to pieces and puts you together again. As a new programmer, you rise from the ashes of your past inadequacies and delusions: „Rust is actually a pretty productive language.“ On a more serious note: there is a book „Programming Rust“ and likely others that help with a structured introduction to the language, which I feel is a warranted approach, especially if the memory management concepts seem alien to you.
- blurker 5y ago
  I feel like some others aren't seeing the humour in your comment. Or maybe I'm just weird. Orr maybe I'm new enough to Rust still that I don't get offended. Anyways, you got a laugh from me at least!
  - dgb23 5y ago
    Yeah! It’s a language that’s highly praised for good reason. But it’s also quite challenging to grasp some of the unique concepts to a degree where humor is the only viable self defense!
- axiosgunnar 5y ago
  > When trying to resolve ownership issues aka fix provably buggy code before it makes it to production?
  - dgb23 5y ago
    I was trying to joke about the experience of learning the language rather than making an educated assessment of it.
dgellow 5y ago
That's not covered by the survey but I'm wondering how much of Rust usage is driven by crypto-currency projects. I'm personally completely convinced by the Rust language and the ecosystem, and decided to bet on it as my main tool for the next decade or so, but I'm also a bit worried that a lot of the money for Rust roles comes from crypto-currency projects (an industry I'm now very sceptical of given the amount of scam/bullshit we've seen during recent years). Not sure if my worries are warranted given my personal bias. Just something I have in mind.
- beingflo 5y ago
  I fully agree, that's exactly what I'm seeing in the job market for Rust in switzerland. It's unfortunate, but I guess more traditional industries are firmly in the grip of Java etc.
- nindalf 5y ago
  To my knowledge, most of the people working on Rust, the project, are employed full time at Amazon, Facebook, Google, Microsoft etc. There are a few folks who benefit from sponsorship from some crypto firms but I think that’s the minority. While it’s a legitimate concern that many jobs appear to be from the crypto industry, I wouldn’t worry too much. Whether they’re scams or not, the entire community benefits from the software they sponsor and open source.
  - sanxiyn 5y ago
    Re: blockchain sponsorship. Minority, yes, but not without weight. For example, current Rust language team leader and library team leader are sponsored by blockchain projects. See https://medium.com/concordium/the-devx-initiative-rust-ecosystem-sponsorship-program-a11a481b70f3 https://medium.com/concordium/the-devx-initiative-rust-ecosy... for details.
    - kibwen 5y ago
      Perhaps I'm asking you to trust me, but I can stake my own reputation on the fact that neither Mara not Josh are in any way compromised by this sort of sponsorship. Both of them have been doing incredible work for years, and while I can't speak to Mara's financial situation, Josh gets sponsored by a ton of different companies to do Rust work (including my own, and we have nothing to do cryptocurrency).
anton_ai 5y ago
Rust is so good, I would switch from python to Rust in a moment if there was the right ecosystem for Data Science / AI stuff
blurker 5y ago
> The next largest concern was that the language would become too complex (33%). I'm also in this camp, although I would go further to say that Rust is already "too complex." Or maybe not. Go has already done an excellent job of being a very simple and effective language. Rust's complexity makes it very useful for some cool stuff. Like building DSL's. But because of its complexity, Rust is not the language I would reach for in most cases when building almost anything pretty standard, like a basic web app backend. For that, I would choose Go over Rust every time. The reason being: the cognitive load of Go is far, far lower, and that is super important for maintainability and being able to collaborate with others. Basically, in the Venn diagram of what Rust can do and what Go can do, I'd mostly use Rust only for what it can do well and Go can't. For example, a real time system that can't have GC overhead. Or sometimes I'll choose it anyway for my hobby projects, just 'cuz I think it's cool and want to use it. But if I put on my pragmatism/business hat and want to build anything seriously, that's the way it will go. Take that for what it's worth since I'm very new to Rust (and I quite like it actually!). Although I have a lot of experience with a lot of other languages including C/C++, Java, Go, Perl, JS/TS, Python, and more. Rust is up there as one of the more complex languages I've used. I've really noticed it on the learning curve so far. Reminds me a lot of Scala, actually. The onboarding experience of Go vs Rust is night and day. You can legitimately go from reading "A tour of Go" to understanding most Go projects within a day (if you're already an experienced programmer). And it's not because Rust is lacking good learning resources. It has amazing docs and so many amazing free resources. I'm honestly enjoying and learning a lot about it rather quickly, I think. But it's still taking a long time and I can see I'm in for a ride and will be going "oh wtf is that" in Rust source code for a very long time!

166 points by surfingninja 5y ago

I found this surprising... 59% of respondents sounds huge! "Rust can now safely be classified as a language used by people in professional settings. Of those respondents using Rust, 59% use it at least occasionally at work with 23% using Rust for the majority of their coding. This is a large increase over last year where only 42% of respondents used Rust at work."

adgjlsfhk1 5y ago
I don't think this is entirely surprising. Rust isn't many people's first language. People who learn it, mostly do because they have become fed up with the unreliability (typically of C). This creates a bias towards people who are more experienced and have more organizational power. Also, language surveys tend to be biased towards power users which can shift the sample significantly. For example, the Julia survey from 2021 only had 25% Windows users, while Julia binaries are something like 70% windows.
- psfried 5y ago
  That's an interesting statistic about Julia. Makes me curious what the stats would be for Rust.
- eminence32 5y ago
  Your comment about people with "more organizational power" may be an accurate reflection of things, but I don't think it's necessary to explain this increase in people using rust at work. It could be that more and more people are using rust for small ad-hoc scripts, which might have been written in python or java before. These small things might not require any organizational approval, but people might be more comfortable now using rust (either because their own skills in the language have improved, or because they feel more comfortable justifying the use of rust, even if they don't need to).
  - pornel 5y ago
    I think that's a genuine use of Rust for Real Work™. For example, Cloudflare went from using Rust for one project 3 years ago, to depending on Rust in core components and using it by default for almost all new development.
- zozbot234 5y ago
  > Rust isn't many people's first language. Has anyone actually tried to teach/learn Rust as a first programming language? People did it with C++ (and even C) at some point, is Rust that much more problematic? (And the attempt might even inform new convenience features: the proc macro system gives Rust a lot of inherent flexibility there.)
  - adgjlsfhk1 5y ago
    People have. In my opinion, it's a bad idea. I think that to appreciate Rust's design, you pretty much have to be familiar with the awfulness of memory leaks in C/C++ (and it helps if you have experience trying to make a program in a GCed language hit strict latency requirements). I think Rust's design is genius, but I think the first language you learn should be an easy language with a GC (there's enough hard parts of learning your first PL). The next step is to learn C (because it's beautiful but fatally flawed), and only after you have learned why manual allocs and frees suck, should you learn Rust.
    - zozbot234 5y ago
      The easiest way to conceptualize Rust's design at a basic level (suitable for first-time learners) is probably as a glorified functional language, where you initially pass everything by value (courtesy of .clone()) aside from shared immutable data (passed via shared references). Mutable borrowing can then be introduced next, followed by the "cell" patterns/constructs for shared mutable state. Not altogether trivial, but it seems like it could work. And the compiler would protect against many errors along the way, that bite C/C++ coders.
    - CornCobs 5y ago
      I agree. I think Rust (or at least many tutorials of Rust) paper over ownership as something the compiler deals with for you but I think that's false. You have to think about memory and ownership. Only when I started using C++ where you have to think about the same things but without the static checking do I appreciate the ability to statically check and enforce things like moving and borrowing
    - 5y ago
spenczar5 5y ago
I write a bit of Rust, but not for work, and I never heard about this survey. I think that's probably common - the more Rust you write, the more likely it is that you fill out the survey, so the sample is probably very biased towards people who work with it a lot (ie, professionally). Or - you could describe that as biased, at least. Alternatively, maybe the intent of these language surveys is exactly to find out what committed power-users think. Either way, interpreting results from language surveys is tricky business.
- apendleton 5y ago
  I think it's true that surveys like this will skew towards more serious/dedicated practitioners, but in addition to professionals, the Rust community has also at various times attracted people who were excited about bleeding-edge things, or PLT/type-theory people, etc., and I think this survey probably does show a shift in the user base towards work-a-day users and away from these other groups. (Or more succinctly: the absolute numbers are probably meaningless, but the trends are maybe worth watching.)
- estebank 5y ago
  The self-selection bias effect is why the survey on isolation is not enough to derive meaning on its own. But, looking at the trends over time as the yearly survey is analyzed and compared with the previous ones is useful.

FullyFunctional 5y ago

I'm definitely in the camp that worry about the feature/complexity creep. I saw it with Haskell. Haskell 98 is a pretty nice and simple language. GHC Haskell is a monster. This matters when you try to read other people code and the overuse of experimental cool new features becomes a major burden for comprehension. Rust is already a very large language and for intrinsic reasons pile on a load more complexity than Haskell (just look at the iterators). I write this as a fan and advocate of Rust.

ekidd 5y ago
I feel like the pace of Rust language evolution slowed down significantly after the 2018 edition and the work on async shortly thereafter. Most of the more recent language changes feel like pretty minor ergonomic improvements, things which always should have worked. I suppose we got const functions (can be evaluated at compile time), and const generics (allow you define fixed-length vectors for size N). But those features are well established in other languages and they don't interact much with anything else. And I'm sure I'm forgetting a few things, but that's sort of my point—subjectively, not a lot has changed for me recently. What I have seen is a lot of good work in the larger ecosystem. And the tooling continues to improve.
zozbot234 5y ago
No worries, Rust has a looong way to go before they reach C++ levels. And the editions system even makes it feasible to pursue some ex-post simplification, though that requires a number of years to complete and cross-linking across editions must be preserved regardless.
stjohnswarts 5y ago
Alas I had fun with rust and made some small apps but as I got deeper I just got scared off by the learning curve. I'm kind of over the hump with c++, javascript and python and I just couldn't do it again. Maybe I will revisit in a few years if it actually slows down.
- pie_flavor 5y ago
  The language evolution speed has nothing whatsoever to do with the learning curve - there's like two major features a year, one of which is only for advanced users. The rolling release cycle just means the tiny incremental improvements arrive sooner. The learning curve has been in place since 1.0 and it only gets harder the more times you give up.

Animats 5y ago

The percentage of people using Rust continues to rise. How was the sample selected?

Epskampie 5y ago
Why, selfselected of course! How surprising that people who still chose to fill out a rust survey in 2021 increasingly use rust! ;-) On topic, i’d like to try out rust, but can’t find good cause in my daily webdev needs.
- Animats 5y ago
  Although I write mostly in Rust, when I have to do some web server side work, I use Go. Go was designed at Google for their server-side applications, and it's well-suited to that. All the expected libraries have seen very heavy use and are unlikely to have unexpected problems. Goroutines handle the job of both async and threads, simplifying concurrency. Rust is overkill for such work. Rust is for complicated problems where both performance and safety matter. Web browsers. Databases. Operating systems. Industrial control. I'm writing a client for a virtual world in Rust. It's much easier to do complex concurrency in Rust than in C++. Use the right tool for the job.

LAC-Tech 5y ago

I have some time between contracts and I've found myself learning rust. Pros: - Sum types. I am an OO apologist, but trying to use classes in C++ is an exercise in frustration. Sum types map very well to union types and are a better fit for systems programming. - Unit tests built right into the language - it seems like a small thing but it's a hassle in most languages to choose a library, set it up etc. - The above, combined with cargo-watch [0]. With the right flags, you hit save, and your tests all run. It's a god-send. - Ecosystem is pretty big. I can find most things I need. - Discord channel is nice. I was put off a bit by the Rust Evangelism Strikeforce back in the day, but so far everyone is pretty chill. - Options & Results in the standard library. All languages should have this Cons: - I find it hard to transfer knowledge of C to rust, because they use different terminology. - Docs can be confusing to read because every method on collections like `map` or `filter` returns its own Trait. People have explained why this is to me a couple of times but I still haven't gotten it through my head. - You still have to think about memory and pointers. Not always a bad thing, but it is an extra dimension when solving a problem. Overall I'm powering through. I'm hoping to get to a point where Rust is an obvious choice for anything that involves finer control of memory. [0] https://github.com/watchexec/cargo-watch https://github.com/watchexec/cargo-watch

berkut 5y ago
As someone with 20 years of C++ experience, in industries from everything from real-time systems through to low-level HPC graphics on CPU/GPU (currently in VFX), I really don't understand the hatred for OO programming, and I must be either missing something, or being lucky with the codebases I'm working on... It's a tool for encapsulation: you can get into trouble with it, but I'd argue the same is possible with many things - it's how well you use it. You can easily use state composition in C++ if you want, and generally (multiple inheritance can cause issues in some cases) you can use interface classes as well. And as someone who's been learning Rust for the past 6+ months, I've found that of the three new projects I started which I started in Rust instead of C++/Python over the past 4 months, Composition actually worked quite less well (it's quite verbose due to all the plumbing needed to connect things up) than if I could have used OO interitance in many situations where I wanted specialisation - i.e. hierarchy behaviour traits that had both common shared state and functionality AND specialised state and functionality. Thankfully Traits can at least have default implementations - if not, things would have been a bit worse. To be clear: there's a lot to like in Rust though.

boberoni 5y ago

I'm curious about the methodology of this survey. The first thing I think about when reading survey results is the possibility of selection bias.

dgb23 5y ago
Ah yes these things are not scientific studies. Just read them as tech culture with diagrams and numbers.

danielscrubs 5y ago

How's the compiler speed? I've been so burnt out on hobby programming on SwiftUI because of the horrendous long compilation times. Makes me long for some Pascal. :)

zozbot234 5y ago
It depends on what you're doing. Rust is not uniformly slow to compile, the slowness is associated to a few specific features like generics and macros. (Good generic code should delegate to a less-generic implementation as early as possible. Hopefully full "const" generics will soon make this feasible in more cases.)
Tobu 5y ago
The compiler itself is fine and its performance well managed, with weekly perf triage and efforts driven by profiling[1], but because adding dependencies is effortless and vetting them isn't, dependency trees tend to get large if not careful. In particular, widely used proc-macros (code transformations pulled by popular packages like serde, clap, tokio…) add very heavy dependencies (like syn) to the critical path. As a consequence, downloading and installing a tool from source is often a poor experience. As far as development experience, cargo clippy / cargo check / rust-analyzer give you the feedback you need without involving codegen (except for any proc-macros in your dependency tree), and incremental compilation makes codegen faster after the first build. Work is also ongoing[2] to make debug-quality codegen faster. Here is a quality article on the art of keeping a Rust project fast to build: https://matklad.github.io/2021/09/04/fast-rust-builds.html https://matklad.github.io/2021/09/04/fast-rust-builds.html The overall series on organizing a large project is worth reading as well: https://matklad.github.io/2021/09/05/Rust100k.html https://matklad.github.io/2021/09/05/Rust100k.html [1]: https://nnethercote.github.io/2021/11/12/the-rust-compiler-has-gotten-faster-again.html https://nnethercote.github.io/2021/11/12/the-rust-compiler-h... [2]: https://bjorn3.github.io/ https://bjorn3.github.io/
edflsafoiewq 5y ago
IMO the other responses downplay it. Compile times are not good.

cryptojournal 5y ago

Lovely Survey :)

zerr 5y ago

Pity that it is hard to find Rust jobs outside blockchain.

pornel 5y ago

If you want more data, I've compiled statistics from crates.io: https://lib.rs/stats https://lib.rs/stats

dgb23 5y ago

Rust is a terribly slow language to write in, especially if you’re trying to fight it in any way - because you‘ll lose. It’s verbose and quite ugly as it tries to appeal to C family programmers while being expression and pattern based. When trying to resolve ownership issues with closures the first time, you‘ll be doubting whether Rust is in fact a language or just a sick elaborate joke that tries to mock you for even considering to use it. But with every concept learned you feel accomplished and start to develop Stockholm syndrome. The Rust compiler beats you to pieces and puts you together again. As a new programmer, you rise from the ashes of your past inadequacies and delusions: „Rust is actually a pretty productive language.“ On a more serious note: there is a book „Programming Rust“ and likely others that help with a structured introduction to the language, which I feel is a warranted approach, especially if the memory management concepts seem alien to you.

blurker 5y ago
I feel like some others aren't seeing the humour in your comment. Or maybe I'm just weird. Orr maybe I'm new enough to Rust still that I don't get offended. Anyways, you got a laugh from me at least!
- dgb23 5y ago
  Yeah! It’s a language that’s highly praised for good reason. But it’s also quite challenging to grasp some of the unique concepts to a degree where humor is the only viable self defense!
axiosgunnar 5y ago
> When trying to resolve ownership issues aka fix provably buggy code before it makes it to production?
- dgb23 5y ago
  I was trying to joke about the experience of learning the language rather than making an educated assessment of it.

dgellow 5y ago

That's not covered by the survey but I'm wondering how much of Rust usage is driven by crypto-currency projects. I'm personally completely convinced by the Rust language and the ecosystem, and decided to bet on it as my main tool for the next decade or so, but I'm also a bit worried that a lot of the money for Rust roles comes from crypto-currency projects (an industry I'm now very sceptical of given the amount of scam/bullshit we've seen during recent years). Not sure if my worries are warranted given my personal bias. Just something I have in mind.

beingflo 5y ago
I fully agree, that's exactly what I'm seeing in the job market for Rust in switzerland. It's unfortunate, but I guess more traditional industries are firmly in the grip of Java etc.
nindalf 5y ago
To my knowledge, most of the people working on Rust, the project, are employed full time at Amazon, Facebook, Google, Microsoft etc. There are a few folks who benefit from sponsorship from some crypto firms but I think that’s the minority. While it’s a legitimate concern that many jobs appear to be from the crypto industry, I wouldn’t worry too much. Whether they’re scams or not, the entire community benefits from the software they sponsor and open source.
- sanxiyn 5y ago
  Re: blockchain sponsorship. Minority, yes, but not without weight. For example, current Rust language team leader and library team leader are sponsored by blockchain projects. See https://medium.com/concordium/the-devx-initiative-rust-ecosystem-sponsorship-program-a11a481b70f3 https://medium.com/concordium/the-devx-initiative-rust-ecosy... for details.
  - kibwen 5y ago
    Perhaps I'm asking you to trust me, but I can stake my own reputation on the fact that neither Mara not Josh are in any way compromised by this sort of sponsorship. Both of them have been doing incredible work for years, and while I can't speak to Mara's financial situation, Josh gets sponsored by a ton of different companies to do Rust work (including my own, and we have nothing to do cryptocurrency).

anton_ai 5y ago

Rust is so good, I would switch from python to Rust in a moment if there was the right ecosystem for Data Science / AI stuff

blurker 5y ago

> The next largest concern was that the language would become too complex (33%). I'm also in this camp, although I would go further to say that Rust is already "too complex." Or maybe not. Go has already done an excellent job of being a very simple and effective language. Rust's complexity makes it very useful for some cool stuff. Like building DSL's. But because of its complexity, Rust is not the language I would reach for in most cases when building almost anything pretty standard, like a basic web app backend. For that, I would choose Go over Rust every time. The reason being: the cognitive load of Go is far, far lower, and that is super important for maintainability and being able to collaborate with others. Basically, in the Venn diagram of what Rust can do and what Go can do, I'd mostly use Rust only for what it can do well and Go can't. For example, a real time system that can't have GC overhead. Or sometimes I'll choose it anyway for my hobby projects, just 'cuz I think it's cool and want to use it. But if I put on my pragmatism/business hat and want to build anything seriously, that's the way it will go. Take that for what it's worth since I'm very new to Rust (and I quite like it actually!). Although I have a lot of experience with a lot of other languages including C/C++, Java, Go, Perl, JS/TS, Python, and more. Rust is up there as one of the more complex languages I've used. I've really noticed it on the learning curve so far. Reminds me a lot of Scala, actually. The onboarding experience of Go vs Rust is night and day. You can legitimately go from reading "A tour of Go" to understanding most Go projects within a day (if you're already an experienced programmer). And it's not because Rust is lacking good learning resources. It has amazing docs and so many amazing free resources. I'm honestly enjoying and learning a lot about it rather quickly, I think. But it's still taking a long time and I can see I'm in for a ride and will be going "oh wtf is that" in Rust source code for a very long time!