Rust is currently my favorite language for personal projects. It's got a very good value proposition in terms of giving some high level features along with low level control and performance, great compatibility story, and the tooling and community is absolutely great.
However, as the manager of a technical team, I would not choose it for professional projects. The learning curve is very steep, and to reap the benefits you have to pay a high cost in terms of accepting additional complexity. I think Rust is a good choice for some professional use-cases, for instance performance-sensitive applications like embedded, or safety-critical applications. But for many applications, like your average webserver for example, I believe you will lose productivity and have a hard time hiring if you choose Rust.
For my team, we chose Go because it is easy to hire and onboard people, the tooling and compatibility story is plenty good enough, and due to the complexity ceiling, there's only so much damage a developer can do in terms of taking the codebase in a bad direction.
Rust is a capable language for a professional setting, but it is also a language ideally suited for people who enjoy indulging in complexity and tricky problem solving, and this is not the right choice for every project or team.
As an indie developer, switching from Go to Rust for web APIs was extremely satisfying. At first there was a productivity loss, but after a few months the productivity was better than Go thanks to Rust's functional features which make it extremely pleasant to write business logic, and the type system catching bugs during development instead of production.
How much of a productivity boost would you’ve gotten from java or kotlin which provides a lot of those features with all the complexity and build times?
“Complexity is the enemy of execution.” - Tony Robbins
I don’t think Tony ever did any coding, but you’re right that it still applies here.
A google search shows complexity has many other enemies: security,reliability, agility, and progress itself.
In most cases I think this is right, use Go and simple tools whenever you can. There are cases where complexity is unavoidable though, like when you’re trying to land a rover in a precise location on Mars, where the sky crane makes sense, but don’t introduce the complexity when it’s unneeded.
Rust is more complex than Go, but when you are dealing with the inherent complexity in a problem, sometimes Rust can allow you to make the decision to take a larger chunk of that complexity and handle it at compile time (instead of at runtime with a crash->debug->fix feedback loop).
So you get sometimes stressful and frustrating writing sessions, coupled with more confidence in the runtime correctness. Also the more expressive type system can allow you to more closely match the domain, which helps when you add new features in the future as you can rule out certain invalid states or interactions.
I often feel you need to know the right conventions to write correct Go programs, where as Rust will just tell you you cannot run it.
I would get things done faster in Go for sure, but the compiled artifact would likely have more issues during runtime.
> don’t introduce the complexity when it’s unneeded.
Prediction is hard. Sometimes I start with something simple, and it ends up growing in scope until it's quite large and complex. Other times I start with something simple, and it stays simple.
So, what's worse, using a complex and/or strict language for something simple, or a simple and less strict language for something that ends up being very large and/or complex?
Interestingly, some people will probably read that last paragraph as my trying to make a point through implication. I suspect different people will assume I'm saying completely opposite things based on their own experience. Really, it's just hard, you get better at making the right choice as you go along, but you'll never always get it right.
'Embedded' doesn't require supporting everyone's favorite microcontroller. Even if ESP32 is really popular, there's plenty of others. OBTW experimental xtensa backend is landing in upstream llvm lately.
Here I am on day three of an attempt to modify a rust program with logic that would have taken about twenty minutes to implement in C# or Java. It has to do with operations on strings (use a regex to find a string in some text, escape all the regex-reserved characters in that string, then use the string as a regex to find other occurrences of itself in the text) so I get that I'm really thrown into the borrow-checker deep-end, but man writing rust feels like working on one of those puzzles where you try to fit a set of tiles inside a rectangle. You'll almost get it but then some edge is sticking out. So you move the tiles around but this leads to two edges sticking out now! So you do a whole bunch of additional exploring before ending up right back where you started with the one edge sticking out.
I even abandoned the learn-by-stackoverflow-search approach to rust and read the first seven or so chapters of the rust book. But even that hasn't helped very much. I know I am just currently in the painful, frustrating stage of learning where nothing really makes sense, and at some future point it will all click, but it really can't be overstated just what a wicked learning curve this language has.
I don't know if this helpful, but from your description of your problem, here's how I'd do that in Rust:
- Use a regex to find a string in some text: use regexes, get a &str
- Escape all the regex reserved characters in that string: Okay this requires mutation but we can't mutate a &str, let's loop over the &str's characters (using the Chars iterator) and push them into a new String with the proper escapes
- The new String we own, so we can easily turn it into a regex and use it to search the original string.
That's where I always end up when I start playing with Rust too. At this point I genuinely think I've given up on belief that the "borrow checker" paradigm is ever really going to be broadly successful (vs. "screw it, just do it in <other managed language>").
Problems with well-constrained allocation paradigms do really well in rust. Problems with reading/parsing/storing messy data structures from external data just really, really hurt.
I think a big part of the problem is that the ownership analysis layer has the dual crises of being (1) really complicated and too hard to keep in your head as a single model and (2) specified in an ad-hoc way that resists formal rules. So eventually you end up in of those puzzles like you mention where... there's just no answer! No one's been where you have, and the lack of rigor means you end up trying to reverse engineer the compiler front end trying to find the trick that works. And then you give up and write it in Go or Python or whatever.
While this can be painful, my basic suggestion -- clone more. The temptation is to never clone, butin C++ people run copy constructors all the time without thinking about it (as they are called automatically).
I clone all the time to make the borrow checker leave me alone. If this code shows up as a hot spot in a profile I can spend the extra energy to optimize it.
I hope to evolve my understanding so that I can do the right thing at design time to minimize unnecessary clone()s.
Cloning means runtime inefficiency, but the cost is so pathetically small compared to the amount of code we run in Python and Java with their larger footprints. Yes. Clone more.
> use a regex to find a string in some text, escape all the regex-reserved characters in that string, then use the string as a regex to find other occurrences of itself in the text)
and I don't recall what's the last time I used the regex crate.
I'm certainly doing all the regex stuff incorrectly, no idea how to match regex-reserved characters, no idea if I'm using the iterator API correctly (its the second example in the regex docs..), etc.
But the idea is simple, search the text for the regex, escape all the reserved characters, use that regex to search for occurrences of the same regex.
I guess that if you want a fully-vectorized, zero-allocation, zero-copy, multi-threaded, gpu... version of this that maxes out the theoretical peak of the hardware available, then you'll probably end up putting a considerable amount of work here.
But otherwise, for someone with literally 30 seconds of experience with the regex crate, it was as straightforward to implement as you mentioned. Just c&p their second example, and just added some glue. This is how I'd implement this in Python, or Java...
EDIT: other responses suggest cloning, but that seems to suggest that one has to explicitly and deliberately think about cloning. I instead just played a game of type golf using functions like `.to_string()` or `.collect` to "clone" stuff behind the scenes. My code is probably horrible, but is the first thing that came to mind.
You can't learn Rust by StackOverflow, that just doesn't work. It is well known, I repeat this everytime I see it happening, and they never listen. It's deeply frustrating.
You can't learn any language by StackOverflow, but some languages are more forgiving to people who don't actually know them.
If you don't really know Rust and in particular understand the borrow checker and how it works (and why it exists), you are going to have a bad time.
Rust in general has a learning curve, but once you do learn it there is a payoff. If Rust code compiles (and if you didn't use 'unsafe'), you can be pretty damn sure it is free of a long list of potential bugs including concurrency bugs, buffer overflows, null pointer dereferences, alignment problems, double-free, use-after-free, stack smashing, most memory leaks, and so on. The runtime cost of that assurance is less in Rust than in any other language I know, and sometimes the safety of Rust actually lets you do things in higher performing ways that would be dangerous to code in C. In C/C++ you have to knit your own straightjacket, and yours may not be as well thought out or efficient as the one the Rust compiler issues you.
I've really started to appreciate Rust's safety. If the code compiles there can still be bugs, but they're going to be higher up at the logic/algorithm level instead of the annoying sorts of bugs that constantly crop up in C/C++.
I mean yeah, that's why I went and read a bunch of the book. But I still run into lots of issues. Like what the hell is a borrow cow and when would I want to use it? And how do I fix the "temporary value dropped when borrowed" error in a series of maps on options?
I had a similar experience. It really made me question whether the borrow checker is worth it. I'm all for memory safety, but there are some pretty compelling low pause GCs out there now that can give you memory safety without the ergonomic problems.
I'm in a similar position. I highly recommend posting snippets of what you're trying to do in the Rust discord. The people are super nice and very helpful.
Honestly the friendliness of the community is a big part of why I'm learning Rust. I found it so much harder to get free help from volunteers with c code issues. Not that I deserve it or anything, but it's really nice and I try to contribute back by writing PRs to improve the docs once I understand something.
As someone who's been there, I strongly recommend asking for help (maybe posting this on HN counts?). Bashing your head against the wall against Rust without some correct code to look at is not (IMO) a great way to learn the language... I definitely get the appeal, as someone who hates asking for help, but it's just not worth it in this case, especially when you're starting out and aren't even sure what terms to look for.
Short suggestion: If performance isn't critical, sprinkle some .clone()s in there on your strings and the borrow-checker will get off your back
Long suggestion: Working with strings in Rust requires that you have a C++ mental model of what strings are and what properties (in the abstract sense of the word) they have. Rust will make sure you can't misuse them, and it will make them as ergonomic as they can be within that C++-like model, but it's a fundamentally different concept from what you have in languages like C# and Java, and if you're trying to look at things from that other perspective, you're going to keep running into walls over and over.
More broadly, when you're using Rust you need to be in the basic mindset of a C++ programmer. From there Rust will make things significantly easier in many ways, but if you don't start with the right mental model, you're going to have a bad time. Strings are probably the most striking case of this because the way they get treated in virtually all higher-level languages is so wildly different from the way they get treated at the low-level.
This is my experience with the language. It's a good language - but it's a tool at the end of the day. One with edges and trade offs like any other. I can't help but think the people like the author only feel "giddy" because its been hyped up on this website.
That seems rather trivial, and I'm not sure how you could possibly have any issues with the borrow checker.
Just do the first regex search, then escape into a String with regex::escape, then build a regex from the String and search with it.
Of course what you are doing is probably wrong since you should use a string matching crate rather than escaping characters and using a regex matching crate.
I agree with that, but this applied to nearly any language for me. I started doing Python back when 2013, then i learned Go, i started writing better Python code, then i learned C, i started writing better Go code, then i learned Rust, i started writing better code in general. The more you play with other language the more you learn other programming paradigms, it changes the way you thinking about programming completely.
A while back there was an interesting post about dry stone walls[1] (e.g. stone walls erected without any mortar). The top comment included this recommendation for beginners in stone masonry:
> When you pick up a stone from the pile, it MUST be placed on the wall. You either have to make it fit your intended spot through rotation or another adjustment, or you have to find another place on the wall for it. It CANNOT be placed back on the pile.[2]
The post explains that using this restriction makes you a better masonry overall because you train your self to the exact skills required. I find this a lot better analogy to restrictive programming languages then a straitjacket. When you restrict your self to always place a stone you pick up, you train your eyes to first evaluate which kind of stones you need next, and you train your self to find that stone in a pile. I don’t see exactly what you are training exactly when you wear a straitjacket.
This is a nice summary of the good features of Rust, but I'm failing to see how any of these points are in any way special for a "professional programmer". Doesn't a hobby programmer care about all of these points as well?
In my experience, whether you're getting paid or not correlates quite poorly with the requirements of the project. I've worked on professional code bases where bugs were totally acceptable ("just push a fix when the error comes in"), and I've done open-source projects where I definitely don't want anything to break ("I'd hate to release a broken version").
> The statement Rust is for Professionals does not imply any logical variant thereof. e.g. I am not implying Rust is not for non-professionals. Rather, the subject/thesis merely defines the audience I want to speak to: people who spend a lot of time authoring, maintaining, and supporting software and are invested in its longer-term outcomes.
Well, it looks like you're implying some logical variants, like "Rust is a better language than language X for professionals" or "Language Y is _not_ a language for professionals". I mean, "Language X is for Professionals" is true (by observation) for every single language out there being used professionally.
While I'm a big fan of Rust myself, there are a few points that lack rigour in this article (which are typical of "I love X" articles). Three points that struck me:
- rust-analyzer is good (as in: it's functional, it's advancing, etc.etc.), but it's alpha; it's not a tool that can be considered a mature tool of a mature language. I often encounter issues while working on projects.
- learning Rust is a serious problem IMHO, not only because it's hard in itself, but it's because it's hard to structure a plan to learn it. listing the reference book is indeed a misrepresentation: a complete beginner that reads the whole book will still have significant problems in working on a real project; it's very unclear which step to take after reading it, as real-world Rust programming needs exercise which is not tackled by any book. Things are made worse by a number of garbage books (Packt being very guilty of this) that pretend to teach programming in Rust by slapping a 20-pages chapter on the syntax and basic concepts.
- "for the vast majority of code I author, Rust feels more like Python than C": feelings are subjective, so I can't argue in an absolute sense, but the complexity of programming is very, very far from Python. In scripting languages like Python/Ruby one doesn't need to care about anything: memory allocation (which in itself, has many consequences, including on the program structure), data types, syntactic rigour, exact consistency of the program (in the sense: one can develop a half broken Python app, and it will stull run); all of these things are required in a statically typed language. Golang is probably a language that is closer to Python than C.
> learning Rust is a serious problem IMHO, not only because it's hard in itself, but it's because it's hard to structure a plan to learn it.
I totally agree. One of the issues is that there are so many complex and novel topics that you will run into in your first week of working on a real project, and you have to wrap your head around all of them to some degree to be able to progress. If there is an obvious and clear progression path, I did not discover it.
> the complexity of programming is very, very far from Python
I could not agree more. These languages are deeply philosophically different in my mind.
It is. It's not going to replace Python, and if maintenance is the metric, then "rewrite it in rust" is not the right move. But I do think Rust will gain traction, be a round a long time, and slowly become a complement to existing C/C++ ecosystems through wrapping and binding.
I'm just not sure the other way will materialize. Until Rust can be used to feed back into C/C++ ecosystems and long-standing projects (like the linux kernel), it'll struggle to be the primary ecosystem / language for non-new (e.g., non-trivial) projects.
I skimmed it, but I think what the author is getting at is that rust demands rigour. The kind of rigour required when failure is a problem and this tends to be the kind of code people get paid to write.
I guess the reverse is also true, if you’re writing the kind of code where failure doesn’t matter (e.g. spikes, experimentation, just messing about) perhaps rust isn’t the best choice.
I think it's a little bit of a trap to fall into to believe that since Rust:
1. provides some unique benefits in terms of safety, and
2. is hard to program and requires rigor
that all that rigor is "worth it", and that it makes you a better programmer to put up with it.
Don't get me wrong, Rust's tradeoffs are valuable for some use-cases, but there are many, many use-cases where a GC'd language will work just fine, and it doesn't make you less professional for choosing a higher level tool which you can be more productive in if you don't have performance or memory constraints.
I also think, as the author alludes to, that many programmers get their first exposure to algebraic types and the elimination of NPE's through Rust, and get the false impression that the benefits of these features are somehow related to the additional complexity required by Rust. But these features are not related. Languages like Swift have shown us that you can get many of the benefits of Rust in terms of providing an "if it compiles it works" experience without many of the challenges Rust imposes on the programmer.
Completely, I don’t see rust as a replacement for Scala, Java, Go (and especially) Javascript which tend to be what I use at work. It’s certainly possible, but I don’t think it would add much.
> I skimmed it, but I think what the author is getting at is that rust demands rigour.
C demands rigor, too, but we're not talking about C because C compilers don't hold your hand and show you where your rigor slipped. Which is a sign C demands more rigor than Rust, isn't it? It's a problem with the author's argument: It's better to say that both C and Rust demand rigor, because they both compile to low-overhead executables (lower-overhead than C++, certainly), but Rust has more handrails and warning signs than C, so it's less dangerous.
> You see practices cargo culted across the decades (like the 80 character terminal/line width and null-terminated strings, which can both be traced back to Hollerith punchcards from the late 19th century)
I limit my lines to 80 chars for more practical reasons. I have a wide-screen 43" monitor and restricting content to 80 columns allows me to have the project/navigation pane + 4 vertical splits side by side. Couple of those vertical splits can be split horizontally and I can see/edit, say, 6 open files at once without any switching of windows. Probably sounds like overkill but once you experience it, you know its worth it. Plus my eyes like less horizontal scanning too.
I'm not sure the author knows exactly what cargo cult means.
It seems like the perpetuation of the use of null-terminated strings is more about interoperability with what came before.
And like you suggest, 80 characters is at the limit of what people generally find comfortable reading. (I rely on editors to word-wrap code on-the-fly rather than insert line breaks manually... maybe that's what was meant? That's a tradeoff, though, since some tools don't do word-wrapping or don't do it well.)
Readit News
However, as the manager of a technical team, I would not choose it for professional projects. The learning curve is very steep, and to reap the benefits you have to pay a high cost in terms of accepting additional complexity. I think Rust is a good choice for some professional use-cases, for instance performance-sensitive applications like embedded, or safety-critical applications. But for many applications, like your average webserver for example, I believe you will lose productivity and have a hard time hiring if you choose Rust.
For my team, we chose Go because it is easy to hire and onboard people, the tooling and compatibility story is plenty good enough, and due to the complexity ceiling, there's only so much damage a developer can do in terms of taking the codebase in a bad direction.
Rust is a capable language for a professional setting, but it is also a language ideally suited for people who enjoy indulging in complexity and tricky problem solving, and this is not the right choice for every project or team.
You can read more about the experience here: https://kerkour.com/blog/rust-for-web-development-2-years-la...
The only thing I'm missing is Go's awesome TLS support (with autocert & co).
That being said, I understand your point regarding hiring: a friend of mine totally refuses to learn Rust because the syntax looks not good to him.
I don’t think Tony ever did any coding, but you’re right that it still applies here.
A google search shows complexity has many other enemies: security,reliability, agility, and progress itself.
In most cases I think this is right, use Go and simple tools whenever you can. There are cases where complexity is unavoidable though, like when you’re trying to land a rover in a precise location on Mars, where the sky crane makes sense, but don’t introduce the complexity when it’s unneeded.
So you get sometimes stressful and frustrating writing sessions, coupled with more confidence in the runtime correctness. Also the more expressive type system can allow you to more closely match the domain, which helps when you add new features in the future as you can rule out certain invalid states or interactions.
I often feel you need to know the right conventions to write correct Go programs, where as Rust will just tell you you cannot run it.
I would get things done faster in Go for sure, but the compiled artifact would likely have more issues during runtime.
Prediction is hard. Sometimes I start with something simple, and it ends up growing in scope until it's quite large and complex. Other times I start with something simple, and it stays simple.
So, what's worse, using a complex and/or strict language for something simple, or a simple and less strict language for something that ends up being very large and/or complex?
Interestingly, some people will probably read that last paragraph as my trying to make a point through implication. I suspect different people will assume I'm saying completely opposite things based on their own experience. Really, it's just hard, you get better at making the right choice as you go along, but you'll never always get it right.
Nope, Rust is also not suitable for these tasks since it doesn't have a certified toolchain (e.g. ISO26262 for automotive or DO-178 for aerospace).
> embedded
Current LLVM-based compiler lacks support for some platforms (e.g. Xtensa for some ESP32 MCUs).
It seems in your use case, Java would have been a viable (and potentially superior) alternative to golang.
I even abandoned the learn-by-stackoverflow-search approach to rust and read the first seven or so chapters of the rust book. But even that hasn't helped very much. I know I am just currently in the painful, frustrating stage of learning where nothing really makes sense, and at some future point it will all click, but it really can't be overstated just what a wicked learning curve this language has.
- Use a regex to find a string in some text: use regexes, get a &str
- Escape all the regex reserved characters in that string: Okay this requires mutation but we can't mutate a &str, let's loop over the &str's characters (using the Chars iterator) and push them into a new String with the proper escapes
- The new String we own, so we can easily turn it into a regex and use it to search the original string.
Problems with well-constrained allocation paradigms do really well in rust. Problems with reading/parsing/storing messy data structures from external data just really, really hurt.
I think a big part of the problem is that the ownership analysis layer has the dual crises of being (1) really complicated and too hard to keep in your head as a single model and (2) specified in an ad-hoc way that resists formal rules. So eventually you end up in of those puzzles like you mention where... there's just no answer! No one's been where you have, and the lack of rigor means you end up trying to reverse engineer the compiler front end trying to find the trick that works. And then you give up and write it in Go or Python or whatever.
It is an error to access a place, when an access conflicts with a loan, and the loan is live.
I hope to evolve my understanding so that I can do the right thing at design time to minimize unnecessary clone()s.
This took 2 min: https://play.rust-lang.org/?version=stable&mode=debug&editio...
and I don't recall what's the last time I used the regex crate.
I'm certainly doing all the regex stuff incorrectly, no idea how to match regex-reserved characters, no idea if I'm using the iterator API correctly (its the second example in the regex docs..), etc.
But the idea is simple, search the text for the regex, escape all the reserved characters, use that regex to search for occurrences of the same regex.
I guess that if you want a fully-vectorized, zero-allocation, zero-copy, multi-threaded, gpu... version of this that maxes out the theoretical peak of the hardware available, then you'll probably end up putting a considerable amount of work here.
But otherwise, for someone with literally 30 seconds of experience with the regex crate, it was as straightforward to implement as you mentioned. Just c&p their second example, and just added some glue. This is how I'd implement this in Python, or Java...
EDIT: other responses suggest cloning, but that seems to suggest that one has to explicitly and deliberately think about cloning. I instead just played a game of type golf using functions like `.to_string()` or `.collect` to "clone" stuff behind the scenes. My code is probably horrible, but is the first thing that came to mind.
If you don't really know Rust and in particular understand the borrow checker and how it works (and why it exists), you are going to have a bad time.
Rust in general has a learning curve, but once you do learn it there is a payoff. If Rust code compiles (and if you didn't use 'unsafe'), you can be pretty damn sure it is free of a long list of potential bugs including concurrency bugs, buffer overflows, null pointer dereferences, alignment problems, double-free, use-after-free, stack smashing, most memory leaks, and so on. The runtime cost of that assurance is less in Rust than in any other language I know, and sometimes the safety of Rust actually lets you do things in higher performing ways that would be dangerous to code in C. In C/C++ you have to knit your own straightjacket, and yours may not be as well thought out or efficient as the one the Rust compiler issues you.
I've really started to appreciate Rust's safety. If the code compiles there can still be bugs, but they're going to be higher up at the logic/algorithm level instead of the annoying sorts of bugs that constantly crop up in C/C++.
Honestly the friendliness of the community is a big part of why I'm learning Rust. I found it so much harder to get free help from volunteers with c code issues. Not that I deserve it or anything, but it's really nice and I try to contribute back by writing PRs to improve the docs once I understand something.
Long suggestion: Working with strings in Rust requires that you have a C++ mental model of what strings are and what properties (in the abstract sense of the word) they have. Rust will make sure you can't misuse them, and it will make them as ergonomic as they can be within that C++-like model, but it's a fundamentally different concept from what you have in languages like C# and Java, and if you're trying to look at things from that other perspective, you're going to keep running into walls over and over.
More broadly, when you're using Rust you need to be in the basic mindset of a C++ programmer. From there Rust will make things significantly easier in many ways, but if you don't start with the right mental model, you're going to have a bad time. Strings are probably the most striking case of this because the way they get treated in virtually all higher-level languages is so wildly different from the way they get treated at the low-level.
Just do the first regex search, then escape into a String with regex::escape, then build a regex from the String and search with it.
Of course what you are doing is probably wrong since you should use a string matching crate rather than escaping characters and using a regex matching crate.
Just lol at the idea that you won't run into borrow checker issues when dealing with strings though.
Deleted Comment
I agree with that, but this applied to nearly any language for me. I started doing Python back when 2013, then i learned Go, i started writing better Python code, then i learned C, i started writing better Go code, then i learned Rust, i started writing better code in general. The more you play with other language the more you learn other programming paradigms, it changes the way you thinking about programming completely.
> When you pick up a stone from the pile, it MUST be placed on the wall. You either have to make it fit your intended spot through rotation or another adjustment, or you have to find another place on the wall for it. It CANNOT be placed back on the pile.[2]
The post explains that using this restriction makes you a better masonry overall because you train your self to the exact skills required. I find this a lot better analogy to restrictive programming languages then a straitjacket. When you restrict your self to always place a stone you pick up, you train your eyes to first evaluate which kind of stones you need next, and you train your self to find that stone in a pile. I don’t see exactly what you are training exactly when you wear a straitjacket.
1: https://news.ycombinator.com/item?id=20455860
2: https://news.ycombinator.com/item?id=20469600
In my experience, whether you're getting paid or not correlates quite poorly with the requirements of the project. I've worked on professional code bases where bugs were totally acceptable ("just push a fix when the error comes in"), and I've done open-source projects where I definitely don't want anything to break ("I'd hate to release a broken version").
> The statement Rust is for Professionals does not imply any logical variant thereof. e.g. I am not implying Rust is not for non-professionals. Rather, the subject/thesis merely defines the audience I want to speak to: people who spend a lot of time authoring, maintaining, and supporting software and are invested in its longer-term outcomes.
Well, it looks like you're implying some logical variants, like "Rust is a better language than language X for professionals" or "Language Y is _not_ a language for professionals". I mean, "Language X is for Professionals" is true (by observation) for every single language out there being used professionally.
- rust-analyzer is good (as in: it's functional, it's advancing, etc.etc.), but it's alpha; it's not a tool that can be considered a mature tool of a mature language. I often encounter issues while working on projects.
- learning Rust is a serious problem IMHO, not only because it's hard in itself, but it's because it's hard to structure a plan to learn it. listing the reference book is indeed a misrepresentation: a complete beginner that reads the whole book will still have significant problems in working on a real project; it's very unclear which step to take after reading it, as real-world Rust programming needs exercise which is not tackled by any book. Things are made worse by a number of garbage books (Packt being very guilty of this) that pretend to teach programming in Rust by slapping a 20-pages chapter on the syntax and basic concepts.
- "for the vast majority of code I author, Rust feels more like Python than C": feelings are subjective, so I can't argue in an absolute sense, but the complexity of programming is very, very far from Python. In scripting languages like Python/Ruby one doesn't need to care about anything: memory allocation (which in itself, has many consequences, including on the program structure), data types, syntactic rigour, exact consistency of the program (in the sense: one can develop a half broken Python app, and it will stull run); all of these things are required in a statically typed language. Golang is probably a language that is closer to Python than C.
I totally agree. One of the issues is that there are so many complex and novel topics that you will run into in your first week of working on a real project, and you have to wrap your head around all of them to some degree to be able to progress. If there is an obvious and clear progression path, I did not discover it.
> the complexity of programming is very, very far from Python
I could not agree more. These languages are deeply philosophically different in my mind.
That looks like a very long essay / dissertation just to say 'I love rust'.
I'm just not sure the other way will materialize. Until Rust can be used to feed back into C/C++ ecosystems and long-standing projects (like the linux kernel), it'll struggle to be the primary ecosystem / language for non-new (e.g., non-trivial) projects.
The important and exciting new things are written in C++, not Rust. Rust has no advantages over C++ once you know C++.
I think you nailed it.
I guess the reverse is also true, if you’re writing the kind of code where failure doesn’t matter (e.g. spikes, experimentation, just messing about) perhaps rust isn’t the best choice.
1. provides some unique benefits in terms of safety, and
2. is hard to program and requires rigor
that all that rigor is "worth it", and that it makes you a better programmer to put up with it.
Don't get me wrong, Rust's tradeoffs are valuable for some use-cases, but there are many, many use-cases where a GC'd language will work just fine, and it doesn't make you less professional for choosing a higher level tool which you can be more productive in if you don't have performance or memory constraints.
I also think, as the author alludes to, that many programmers get their first exposure to algebraic types and the elimination of NPE's through Rust, and get the false impression that the benefits of these features are somehow related to the additional complexity required by Rust. But these features are not related. Languages like Swift have shown us that you can get many of the benefits of Rust in terms of providing an "if it compiles it works" experience without many of the challenges Rust imposes on the programmer.
C demands rigor, too, but we're not talking about C because C compilers don't hold your hand and show you where your rigor slipped. Which is a sign C demands more rigor than Rust, isn't it? It's a problem with the author's argument: It's better to say that both C and Rust demand rigor, because they both compile to low-overhead executables (lower-overhead than C++, certainly), but Rust has more handrails and warning signs than C, so it's less dangerous.
As an example, the rigour of strong typing helps set some experiments on the right track.
I limit my lines to 80 chars for more practical reasons. I have a wide-screen 43" monitor and restricting content to 80 columns allows me to have the project/navigation pane + 4 vertical splits side by side. Couple of those vertical splits can be split horizontally and I can see/edit, say, 6 open files at once without any switching of windows. Probably sounds like overkill but once you experience it, you know its worth it. Plus my eyes like less horizontal scanning too.
It seems like the perpetuation of the use of null-terminated strings is more about interoperability with what came before.
And like you suggest, 80 characters is at the limit of what people generally find comfortable reading. (I rely on editors to word-wrap code on-the-fly rather than insert line breaks manually... maybe that's what was meant? That's a tradeoff, though, since some tools don't do word-wrapping or don't do it well.)