At Cloudflare we have big Rust projects/teams and onboard new developers regularly.
There is a learning curve. Rust is rigid and unforgiving, and noobs need assistance when the compiler says “no” (although error messages and Clippy do a good job for common mistakes).
However, the big upside is that noobs can contribute safely to Rust projects. Rust limits severity of the damage an inexperienced programmer can cause. Once they manage to get the code to compile, it already has lots of correctness guarantees. “Bad” Rust code may just clone more than strictly necessary, or write 10 lines of code for something that has a helper method in the stdlib, but it won’t corrupt memory or blindly run the happy path without checking for errors. Rust prefers to be locally explicit, so it’s also easy to review.
I was going to say, measured by how much time and effort it takes to be able to confidently contribute to projects written in it, Rust is easier than many popular languages, in my opinion and experience (which mostly consists of doing just that.)
C++ is also a very complex language. Sure, it may be easier to write than Rust because the compiler is more forgiving, but it’s also much harder to guarantee its correctness.
Agree. Depending on what you care about, the tables turn completely, and it’s not limited to writing:
It occured to me today that I can’t actually read C++: At least when correctness means not creating accidental copies of a vector that’s wrapped in a generated class that doesn’t implement move operators, and passed up through function calls involving both RVO with multiple returns and assignment to out-arguments. The only way to inquire about whether that vector is accidentally copied is to replace it with your own that is uncopyable. Which can be a lot of work if that involves changing a pervasively used code generator. Suffice to say, the code wasn’t readable in a day.
In contrast, Rust doesn’t implicitly .clone() things.
I forgot to say that in Rust, you wouldn’t even write this (particular) code yourself, because Serde exists. Thanks to more powerful macros, things like Serde are possible without code generation.
(This wasn’t my main point, but perhaps a good one about how laborious it is to get the same job done if your language is not expressive enough.)
Another hurdle to learn Rust is how disjoint the sync vs async experience is. A lot of teaching material presupposes sync Rust, but the patterns you learn for sync are only half applicable to async.
I love Rust, but more specifically, I love sync Rust. I’m reluctantly pushed into async every day because a lot of crates we rely on have opted to go the async route. This makes it harder for me to bring the rest of the team along.
Do you have any examples of crates pushing you into using async where you otherwise wouldn’t? Not to cast doubt on your experience, I just haven’t noticed this yet and I’m curious what kind of libraries it affects.
Sure. Latest was rusoto_dynamodb and webrtc-rs. I believe all of the rusoto AWS api crates are async. webrtc-rs is ported from Go, so async is closest to the original code.
I’m very sad about rust going with async / await and splitting the library ecosystem in two. I get that javascript/node pretty much has no other choise. Python should’ve shown how bad it can be. I think Rust is great overall, but wish for a Go-like experience of not having to worry about async. I get that Rust wants to offer the option of not having a runtime. But for most usecases having the go runtime take care of it is a bliss. Sometimes I also wish for a GC instead of the borrow checker, but I guess a GC couldn’t give the same assurances about safe concurrency that the borrow checker can. I really like the typing / error handling. Wish go would adopt a more modern type system in addition to generics.
At least with C++ developers can slowly learn the more arcane part of the language language while they use it. A bit more difficult with Rust.
Furthermore, it might be possible to implement some form of borrow checking for existing languages.
Any language should be easy to learn. That’s true for C and python. Language popularity is highly correlated with ease of learning. And this is true for all the new languages out there that try to do fancy things: most developers do not care.
Personally, all I would ever want, is something mostly like C/C++, with pythonic features, easier to read and use, faster to compile, without a GC, statically compiled, without sophisticated things.
I wouldn’t call C easy to learn. It probably has less essential complexity than Rust has, but there’s still a lot of fiddly details to learn that wouldn’t come up in languages created decades later with garbage collection and better tooling and syntactic defaults.
A couple issues I found when wanting to learn C is all of the variation because of its history. What tooling should I use? Which conventions should I follow? Which version is the current version?
The various C standards are not conveniently discoverable and even when you map them out, they’re written in reference to past standards. So to get the set of rules you have to mentally diff K&R C with a handful of other standards published over 40 years, etc.
Starting completely from no knowledge and trying to figure out “What are the complete set of rules for the most modern version of C?” is nearly impossible. At least that has been my experience and biggest struggle when trying to get started with C multiple times over the years.
Then I constantly see veteran C programmers arguing with each other about correct form, there seems to be far less consensus than with modern languages.
I think there is a big difference to what is the absolute minimum you can learn.
You can “learn” C with programs that compile and run the happy path mostly correctly. The probably have tons of bugs and security issues but you are using the language.
Rust forces you to handle these issues up front. This does make the minimal learning longer but the total learning to be a “production ready coder” is probably actually shorter.
Man, I was terrified when I was learning C++. I would stick to the parts I was “comfortable” with, but when I would call someone else’s code (or a library) I couldn’t reliably know how the features they used would intersect with mine. And the consequences very often were debugging core dumps for hours. I’m no Rust fanboy, but if you’re going to have a language as complicated as Rust or C++, I’d rather learn with one that slaps my hand when doing something I probably oughtn’t do.
Is that not the case already ?
I unfortunately do not use Nim often these days so I might be out of touch, but if I recall correctly arc/orc are available but not the default.
EDIT: Yeah, It seems to use ref counting by default currently but the doc advise to use orc for newly written code
Cf: https://nim-lang.github.io/Nim/mm.html
Any language should be easy to learn. That’s true for C and python. Language popularity is highly correlated with ease of learning.
All other things being equal, yes, ease of learning is good. But at some point one may have to sacrifice ease of learning to make the expert’s work easier or more reliable or faster or leaner. Sometimes that’s what has to be done to reach the level of quality we require.
If it means some programmers can’t use it, so be it. It’s okay to keep the incompetents out.
Can we at least agree that there is such a thing as incompetent programmers? I’m all for inclusivity, but at some point the job has to get done. Also, people can learn. It’s not always easy, but it’s rarely impossible.
There are, but generally they’re not going to be successful whether they use Rust or another language. There are inexperienced developers who aren’t incompetent but just haven’t learned yet who will have an easier time learning some languages than Rust, and there are also experienced programmers who simply don’t know Rust who will also have an easier time learning other languages than Rust. Since the incompetent programmers will fail with or without Rust, it seemed like you were referring to the other groups as incompetent.
Ah, the permanent connotation of “incompetent” eluded me. I was including people who are not competent yet. You only want to keep them out until they become competent.
My original point was the hypothesis that sometimes, being expert friendly means being beginner hostile to some extent. While it is possible (and desirable) to lower the learning curve as much as we reasonably can, it’s rarely possible to flatten it down to zero, and in some cases, it just has to be steep.
Take oscilloscopes for instance. The ones I was exposed to in high school were very simple. But the modern stuff I see now is just pouring buttons all over the place like a freaking airliner! That makes them much scarier to me, who have very little skill in electronics. But I also suspect all these buttons are actually valuable to experts, who may have lots of ways to test a wide variety of circuits. And those button give them a more direct access to all that goodness.
In the end, the question is, are steep learning curve worth it? I believe that in some cases, they are.
That makes sense. Thanks for clarifying. I don’t know if I have a strong opinion, but I do believe that there are cases that require extreme performance and that often requires expertise. Moreover, having been a C++ programmer for a time, I’m grateful that where C++ would accept a broken program, Rust slaps my hand.
At least with C++ developers can slowly learn the more arcane part of the language language while they use it. A bit more difficult with Rust.
I’m not sure what parts of Rust you consider “arcane”. The tough parts to learn, borrow checking and lifetimes, aren’t “arcane” parts of Rust; they are basically it’s raison d’être.
Any language should be easy to learn.
Ideally languages would be as simple/easy as they can be to meet their goals. But a language might be the easiest-to-learn expression of a particular set of goals and still be tough to learn – it depends on the goals. Some goals might have a lot of inherent complexity.
If carefully aware of escape analyses as a programmer, you might realize that with Go, and, while programming Go for several years, I’m by no means a Go fanboy.
In particular, I conjecture that you could write a program in Go that does not use GC, unless the standard library functions you use themselves use GC.
I need to learn Rust, i realize, having written that prior sentence, and having been originally a C fan.
Personally, I would strongly recommend the O’Reilly “Programming Rust, 2nd ed.” For me it was a breakthrough that finally allowed me to write Rust and not get stuck. It may not be “perfectly shiny” what I write, but before that, I often stumbled into some situations I just couldn’t get out of. Now I understand enough to be able to at least find some workaround - ugly or not, but it lets me go on writing.
Also, coming from Go (with a history of C++ long ago beforehand), one thing I had to get over and understand “philosophically” was the apparent lack of simplicity in Rust. For this, my “a ha” moment was realizing, that the two languages make different choices in a priorities triangle of: simplicity vs. performance vs. security. Go does value all 3, but chooses simplicity as the highest among them (thus GC, nulls, etc; but super approachable lang spec and stdlib APIs and docs). Rust does value all 3 too, but chooses performance AND security as the highest. Thus simplicity necessarily is just forced to the back-seat, with a “sorry, man; yes, we do care about you, but now just please stay there for a sec and let us carry out the quarrel we’re having here; we’ll come back to you soon and really try to look into what you’d like us to hear.” And notably the “AND” here is IMO a rather amazing feat, where before I’d assume it just has to often be an “or”. Also this theory rather nicely explains to me the sparking and heated arguments around the use of unsafe in the community - it would appear to happen around the lines where the “AND” is, or looks like it is, kind of stretching/cracking.
Personally, all I would ever want, is something mostly like C/C++, with pythonic features, easier to read and use, faster to compile, without a GC, statically compiled, without sophisticated things.
I think you’re looking for Myddin (still WIP) or possibly Hare. Whether they’re “pythonic” is debatable though.
Not only easy to run. Easy. Because why would one make it difficult if it clearly can be made easy?
The whole point of programming languages is providing simoler alternatives to the targets of their compilers.
It’s difficult because of the safety checks it implements, among other reasons. A lot of people I see starting out try to use an object oriented approach, if anything rust is closer to functional languages (it certainly has some inspiration from something like Haskell). But also, for someone who is just working on a hobbyist project, rust may be a tad too much, however how else will you learn it without actually trying it?
Most of my trouble with Rust came from trying to use it functionally. Closures in particular were hard to figure out as they pertained to the borrow checker, depending on what state they closed over. I would often write more imperative code in Rust than I would in Python, for example.
A key aspect of Rust is allowing company lock-in. Once you have large teams, you find that lack of a large standard library allows you to create a proprietary custom one. You can create a library, or even an ecosystem, that does prevents skills from transferring to a new position and thus lowers your staffing costs.
It is easily defended as ‘cutting edge’.
This leads to the odd question: is it a good idea for a developer to work in Rust?
A key aspect of Rust is allowing company lock-in. Once you have large teams, you find that lack of a large standard library allows you to create a proprietary custom one. You can create a library, or even an ecosystem, that does prevents skills from transferring to a new position and thus lowers your staffing costs.
This might be more convincing if, say, crates.io didn’t exist and if Cargo wasn’t built entirely around making a shared ecosystem easy, but as it stands this idea seems, to put it mildly, preposterous – and suggests you’re reaching for uncharitable assertions.
The job market for developers with experience in a language with a famously batteries-included standard lib, Python, currently pays a lot less than it does for Rust (there are more Python jobs, of course, but your average salary is about $30,000 less per: https://www.zdnet.com/article/heres-how-much-money-you-can-make-as-a-developer-in-2021/). There’s zero reason to imagine that a larger standard library size is correlated with higher pay, or vice-versa.
I’ve used Rust as several jobs and never seen a company create any kind of alternate standard library for it, proprietary or otherwise. There are a number of well-known crates used for specific things - e.g. reqwests, serde, nom - that are open source, easily available via crates.io, and applicable to projects across multiple firms. Which is similar to the situation in other modern languages with easily-accessible package ecosystems like Python and JavaScript, and is the opposite of discouraging skill transfer.
You can create a library, or even an ecosystem, that does prevents skills from transferring to a new position and thus lowers your staffing costs.
Someone would have to be unusually incompetent to be unable to transfer their skills from one standard lib to another. Fundamentals, people! Once you know them, it’s mostly a matter of knowing how stuff is named. You won’t hit the ground running, but then again nobody does. Even when you already know the standard stuff there will be tons of proprietary and bespoke code to wade through.
At Cloudflare we have big Rust projects/teams and onboard new developers regularly.
There is a learning curve. Rust is rigid and unforgiving, and noobs need assistance when the compiler says “no” (although error messages and Clippy do a good job for common mistakes).
However, the big upside is that noobs can contribute safely to Rust projects. Rust limits severity of the damage an inexperienced programmer can cause. Once they manage to get the code to compile, it already has lots of correctness guarantees. “Bad” Rust code may just
clonemore than strictly necessary, or write 10 lines of code for something that has a helper method in the stdlib, but it won’t corrupt memory or blindly run the happy path without checking for errors. Rust prefers to be locally explicit, so it’s also easy to review.I was going to say, measured by how much time and effort it takes to be able to confidently contribute to projects written in it, Rust is easier than many popular languages, in my opinion and experience (which mostly consists of doing just that.)
Agree. Depending on what you care about, the tables turn completely, and it’s not limited to writing:
It occured to me today that I can’t actually read C++: At least when correctness means not creating accidental copies of a vector that’s wrapped in a generated class that doesn’t implement move operators, and passed up through function calls involving both RVO with multiple returns and assignment to out-arguments. The only way to inquire about whether that vector is accidentally copied is to replace it with your own that is uncopyable. Which can be a lot of work if that involves changing a pervasively used code generator. Suffice to say, the code wasn’t readable in a day.
In contrast, Rust doesn’t implicitly
.clone()things.I forgot to say that in Rust, you wouldn’t even write this (particular) code yourself, because Serde exists. Thanks to more powerful macros, things like Serde are possible without code generation.
(This wasn’t my main point, but perhaps a good one about how laborious it is to get the same job done if your language is not expressive enough.)
Another hurdle to learn Rust is how disjoint the sync vs async experience is. A lot of teaching material presupposes sync Rust, but the patterns you learn for sync are only half applicable to async.
I love Rust, but more specifically, I love sync Rust. I’m reluctantly pushed into async every day because a lot of crates we rely on have opted to go the async route. This makes it harder for me to bring the rest of the team along.
Do you have any examples of crates pushing you into using async where you otherwise wouldn’t? Not to cast doubt on your experience, I just haven’t noticed this yet and I’m curious what kind of libraries it affects.
Sure. Latest was rusoto_dynamodb and webrtc-rs. I believe all of the rusoto AWS api crates are async. webrtc-rs is ported from Go, so async is closest to the original code.
I’m very sad about rust going with async / await and splitting the library ecosystem in two. I get that javascript/node pretty much has no other choise. Python should’ve shown how bad it can be. I think Rust is great overall, but wish for a Go-like experience of not having to worry about async. I get that Rust wants to offer the option of not having a runtime. But for most usecases having the go runtime take care of it is a bliss. Sometimes I also wish for a GC instead of the borrow checker, but I guess a GC couldn’t give the same assurances about safe concurrency that the borrow checker can. I really like the typing / error handling. Wish go would adopt a more modern type system in addition to generics.
Yes it matters.
At least with C++ developers can slowly learn the more arcane part of the language language while they use it. A bit more difficult with Rust.
Furthermore, it might be possible to implement some form of borrow checking for existing languages.
Any language should be easy to learn. That’s true for C and python. Language popularity is highly correlated with ease of learning. And this is true for all the new languages out there that try to do fancy things: most developers do not care.
Personally, all I would ever want, is something mostly like C/C++, with pythonic features, easier to read and use, faster to compile, without a GC, statically compiled, without sophisticated things.
I wouldn’t call C easy to learn. It probably has less essential complexity than Rust has, but there’s still a lot of fiddly details to learn that wouldn’t come up in languages created decades later with garbage collection and better tooling and syntactic defaults.
A couple issues I found when wanting to learn C is all of the variation because of its history. What tooling should I use? Which conventions should I follow? Which version is the current version?
The various C standards are not conveniently discoverable and even when you map them out, they’re written in reference to past standards. So to get the set of rules you have to mentally diff K&R C with a handful of other standards published over 40 years, etc. Starting completely from no knowledge and trying to figure out “What are the complete set of rules for the most modern version of C?” is nearly impossible. At least that has been my experience and biggest struggle when trying to get started with C multiple times over the years.
Then I constantly see veteran C programmers arguing with each other about correct form, there seems to be far less consensus than with modern languages.
I’d say C is easy to learn but hard to master. But that could be said about a lot of languages.
I think there is a big difference to what is the absolute minimum you can learn.
You can “learn” C with programs that compile and run the happy path mostly correctly. The probably have tons of bugs and security issues but you are using the language.
Rust forces you to handle these issues up front. This does make the minimal learning longer but the total learning to be a “production ready coder” is probably actually shorter.
Man, I was terrified when I was learning C++. I would stick to the parts I was “comfortable” with, but when I would call someone else’s code (or a library) I couldn’t reliably know how the features they used would intersect with mine. And the consequences very often were debugging core dumps for hours. I’m no Rust fanboy, but if you’re going to have a language as complicated as Rust or C++, I’d rather learn with one that slaps my hand when doing something I probably oughtn’t do.
So, Nim once ARC lands?
Is that not the case already ? I unfortunately do not use Nim often these days so I might be out of touch, but if I recall correctly arc/orc are available but not the default.
EDIT: Yeah, It seems to use ref counting by default currently but the doc advise to use orc for newly written code Cf: https://nim-lang.github.io/Nim/mm.html
All other things being equal, yes, ease of learning is good. But at some point one may have to sacrifice ease of learning to make the expert’s work easier or more reliable or faster or leaner. Sometimes that’s what has to be done to reach the level of quality we require.
If it means some programmers can’t use it, so be it. It’s okay to keep the incompetents out.
I was mostly with you, but “incompetents” is harsh.
Can we at least agree that there is such a thing as incompetent programmers? I’m all for inclusivity, but at some point the job has to get done. Also, people can learn. It’s not always easy, but it’s rarely impossible.
There are, but generally they’re not going to be successful whether they use Rust or another language. There are inexperienced developers who aren’t incompetent but just haven’t learned yet who will have an easier time learning some languages than Rust, and there are also experienced programmers who simply don’t know Rust who will also have an easier time learning other languages than Rust. Since the incompetent programmers will fail with or without Rust, it seemed like you were referring to the other groups as incompetent.
Ah, the permanent connotation of “incompetent” eluded me. I was including people who are not competent yet. You only want to keep them out until they become competent.
My original point was the hypothesis that sometimes, being expert friendly means being beginner hostile to some extent. While it is possible (and desirable) to lower the learning curve as much as we reasonably can, it’s rarely possible to flatten it down to zero, and in some cases, it just has to be steep.
Take oscilloscopes for instance. The ones I was exposed to in high school were very simple. But the modern stuff I see now is just pouring buttons all over the place like a freaking airliner! That makes them much scarier to me, who have very little skill in electronics. But I also suspect all these buttons are actually valuable to experts, who may have lots of ways to test a wide variety of circuits. And those button give them a more direct access to all that goodness.
In the end, the question is, are steep learning curve worth it? I believe that in some cases, they are.
That makes sense. Thanks for clarifying. I don’t know if I have a strong opinion, but I do believe that there are cases that require extreme performance and that often requires expertise. Moreover, having been a C++ programmer for a time, I’m grateful that where C++ would accept a broken program, Rust slaps my hand.
True. Ada Programming language easy to learn but not widely accepted or used
I’m not sure what parts of Rust you consider “arcane”. The tough parts to learn, borrow checking and lifetimes, aren’t “arcane” parts of Rust; they are basically it’s raison d’être.
Ideally languages would be as simple/easy as they can be to meet their goals. But a language might be the easiest-to-learn expression of a particular set of goals and still be tough to learn – it depends on the goals. Some goals might have a lot of inherent complexity.
If carefully aware of escape analyses as a programmer, you might realize that with Go, and, while programming Go for several years, I’m by no means a Go fanboy.
In particular, I conjecture that you could write a program in Go that does not use GC, unless the standard library functions you use themselves use GC.
I need to learn Rust, i realize, having written that prior sentence, and having been originally a C fan.
Personally, I would strongly recommend the O’Reilly “Programming Rust, 2nd ed.” For me it was a breakthrough that finally allowed me to write Rust and not get stuck. It may not be “perfectly shiny” what I write, but before that, I often stumbled into some situations I just couldn’t get out of. Now I understand enough to be able to at least find some workaround - ugly or not, but it lets me go on writing.
Also, coming from Go (with a history of C++ long ago beforehand), one thing I had to get over and understand “philosophically” was the apparent lack of simplicity in Rust. For this, my “a ha” moment was realizing, that the two languages make different choices in a priorities triangle of: simplicity vs. performance vs. security. Go does value all 3, but chooses simplicity as the highest among them (thus GC, nulls, etc; but super approachable lang spec and stdlib APIs and docs). Rust does value all 3 too, but chooses performance AND security as the highest. Thus simplicity necessarily is just forced to the back-seat, with a “sorry, man; yes, we do care about you, but now just please stay there for a sec and let us carry out the quarrel we’re having here; we’ll come back to you soon and really try to look into what you’d like us to hear.” And notably the “AND” here is IMO a rather amazing feat, where before I’d assume it just has to often be an “or”. Also this theory rather nicely explains to me the sparking and heated arguments around the use of
unsafein the community - it would appear to happen around the lines where the “AND” is, or looks like it is, kind of stretching/cracking.I think you’re looking for Myddin (still WIP) or possibly Hare. Whether they’re “pythonic” is debatable though.
Not only easy to run. Easy. Because why would one make it difficult if it clearly can be made easy? The whole point of programming languages is providing simoler alternatives to the targets of their compilers.
It’s difficult because of the safety checks it implements, among other reasons. A lot of people I see starting out try to use an object oriented approach, if anything rust is closer to functional languages (it certainly has some inspiration from something like Haskell). But also, for someone who is just working on a hobbyist project, rust may be a tad too much, however how else will you learn it without actually trying it?
Most of my trouble with Rust came from trying to use it functionally. Closures in particular were hard to figure out as they pertained to the borrow checker, depending on what state they closed over. I would often write more imperative code in Rust than I would in Python, for example.
As someone several repos deep in “I’m going to build my next toy in rust!” campaigns, I feel this comment :D
A key aspect of Rust is allowing company lock-in. Once you have large teams, you find that lack of a large standard library allows you to create a proprietary custom one. You can create a library, or even an ecosystem, that does prevents skills from transferring to a new position and thus lowers your staffing costs.
It is easily defended as ‘cutting edge’.
This leads to the odd question: is it a good idea for a developer to work in Rust?
This might be more convincing if, say, crates.io didn’t exist and if Cargo wasn’t built entirely around making a shared ecosystem easy, but as it stands this idea seems, to put it mildly, preposterous – and suggests you’re reaching for uncharitable assertions.
The job market for developers with experience in a language with a famously batteries-included standard lib, Python, currently pays a lot less than it does for Rust (there are more Python jobs, of course, but your average salary is about $30,000 less per: https://www.zdnet.com/article/heres-how-much-money-you-can-make-as-a-developer-in-2021/). There’s zero reason to imagine that a larger standard library size is correlated with higher pay, or vice-versa.
I’ve used Rust as several jobs and never seen a company create any kind of alternate standard library for it, proprietary or otherwise. There are a number of well-known crates used for specific things - e.g. reqwests, serde, nom - that are open source, easily available via crates.io, and applicable to projects across multiple firms. Which is similar to the situation in other modern languages with easily-accessible package ecosystems like Python and JavaScript, and is the opposite of discouraging skill transfer.
The exact same thing can be said of C and its tiny stdlib. Did it lead to this situation you describe?
Someone would have to be unusually incompetent to be unable to transfer their skills from one standard lib to another. Fundamentals, people! Once you know them, it’s mostly a matter of knowing how stuff is named. You won’t hit the ground running, but then again nobody does. Even when you already know the standard stuff there will be tons of proprietary and bespoke code to wade through.