12 ms·

Rust is for Professionals

138 points by indygreg2 5y ago

StreamBright 5y ago
> To me, Rust introduced a number of new concepts, like match for control flow, enums as algebraic types, He must be joking.
- TheAdamAndChe 5y ago
  When rephrased as "Rust introduced to me a number of new concepts, like match for control flow, enums as algebraic types," it's much more clear what he means. We all learn somehow.
- oytis 5y ago
  He means Rust introduced these concepts to him, not in general.
- danpalmer 5y ago
  The author does mention a Haskell/Scala like language missing from their list of languages they have written, but then they do include Erlang which I believe has pattern matching as a fairly core construct? This does lead me to doubt how much Erlang they've written, and in turn how much they've written across all of the languages mentioned.
  - StreamBright 5y ago
    Exactly. How can somebody claim to program in Erlang and also claim that Rust introduced pattern matching to them? Erlang has the best pattern matching abilities and it is all around in every single Erlang code I have ever seen.
- deleted 5y ago
  [deleted]
- VBprogrammer 5y ago
  I think you might be misinterpreting that as "Rust introduced these things" rather than "I learned about these things from Rust".
  - ocschwar 5y ago
    Also, Rust introduced the idea of these things in a systems language.
    - EE84M3i 5y ago
      Popularized. Many others did it first. ATS comes to mind.
  - StreamBright 5y ago
    See above.
- masklinn 5y ago
  The author specifically and explicitly pointed out 3 times in 2 paragraph that these were new to them, not to the world at large. In fact, they spelled this out very explicitely in the paragraph following the one you selectively quoted: > Many of the new concepts weren't novel to Rust. But considering I've had exposure to many popular programming languages, the fact many were new to me means these aren't common features in mainstream languages. And… they're right. Other languages cropped up with overlap around the same time (mostly Swift), but sum types, pattern matching, option types, … were not common features, and borrow checking remains rather unique.
  - StreamBright 5y ago
    He also claimed that he programmed in Erlang. How can you program in Erlang without pattern matching?
colesantiago 5y ago
TL;DR? That looks like a very long essay / dissertation just to say 'I love rust'.
- jmull 5y ago
  > a very long essay / dissertation just to say 'I love rust'. I think you nailed it.
- ModernMech 5y ago
  After 14k words I think I've come to the TL;DR at the end: "I am irrationally effusive about Rust."
- void_mint 5y ago
  TL;DR: Author likes Rust. Rust exposed them to new things. The title is totally misleading and irrelevant.
- jvanderbot 5y ago
  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.
  - otabdeveloper4 5y ago
    At this point Rust is not the prmary ecosystem for anything. The important and exciting new things are written in C++, not Rust. Rust has no advantages over C++ once you know C++.
    - neonological 5y ago
      This statement is wrong. Rust has many advantages over C++. Knowing c++ doesn’t make these advantages disappear. It’s like saying you know assembly language and can write 100% bug free code in assembly so C++ has no advantage over it. Realistically, both languages have advantages and disadvantages.
ahelwer 5y ago
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.
- ajross 5y ago
  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.
  - sanxiyn 5y ago
    No, borrow checker's formal rules are rather simple. Here it is: It is an error to access a place, when an access conflicts with a loan, and the loan is live.
ocschwar 5y ago
The title implied that it's not for amateurs, and now that I have some data about Rust and teenagers, I can say it very much IS for teenagers. After one afternoon wrestling with GDB and C code, they're ready to put up wrestling with the borrow checker.
- CodeIsTheEnd 5y ago
  While in many cases that may be the implication, the author clearly states that is not their intention in the first few paragraphs: > 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.
skohan 5y ago
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.
- kzhukov 5y ago
  > safety-critical applications 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).
  - wyldfire 5y ago
    '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.
    - kzhukov 5y ago
      That were just the examples when Rust is not really suitable as a drop-in replacement for C/C++. Of course, if your platform is well-supported by Rust compiler and you don't have to write safety critical applications, then using Rust is just a matter of choice. I don't argue whether it's good or bad language. It's a quite interesting one with its own pros and cons. If it fits you, then it's great, but you should know its limitations.
judofyr 5y ago
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.
mnd999 5y ago
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.
- msla 5y ago
  > 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.
- skohan 5y ago
  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.
  - mnd999 5y ago
    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.
noisy_boy 5y ago
> 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.
- jmull 5y ago
  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.)
lmilcin 5y ago
> 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. I think the title is a little bit misleading and paired with the first sentence invites flame, but this one in the middle of article sums it up much better. With some languages you pay some special costs that are only recovered for certain types of applications. For example, programming in C is slow, tedious and bug-prone (as compared to Python) but it is easier to solve some types of problems (like writing system software, controlling memory layout for performance, conserve resources, etc.) For most projects the cost may be too high but if you are one of certain types of projects the pros will outweigh the cons. In general, when programming with strong types you pay for long term maintainability (ability to automatically ascertain correct type of object at any point and extra features that come from it). In Rust you pay even more for even more benefit in controlling the types and ownership of the data which means this environment should be thought as geared even more towards long term maintainability.
deleted 5y ago
[deleted]
pantulis 5y ago
"(...) Rust feels more like Python than C. (...)" This feels like a very powerful assertion. Does the rest of the HN audience agree with this? If this is true, how long did it take?
- skohan 5y ago
  I'm a bit confused by this take. With Rust you're constantly thinking low level details, like which type of reference something is. I would place it closer to C than Python, but closer to C++ than either.
  - estebank 5y ago
    I wouldn't say that thinking about ownership is "low level details". You are (or should?) always having to think about this when building APIs. The difference is that in for example Python you don't have a way to encode that information and enforce it. I would say that the "feeling" of writing on a high-level language comes from a few ergonomic features: - Match ergonomics, so that you have to think about borrowing less in patterns - The compiler providing suggestions for those cases where you must specify them - Type inference - Iterators letting you write fairly functional code Things like having to write &*foo[..] or .as_mut_ref() are indeed "warts" when you don't care about those details, but they happen uncommonly enough that it isn't perceived as an onerous cost.
    - skohan 5y ago
      > You are (or should?) always having to think about [ownership] when building APIs. This isn't strictly true. For instance Swift uses value semantics, which is equivalent to adding an implicit `.copy()` in rust every time most variables are passed around. It obviates a lot of the low-level details, at the cost of performance and control. This is a lot more "python-like" in my opinion, where having to hold these details in your mind is very much against the design priorities of python. Python wants everything to be implicit, to eliminate tedium wherever possible, and for syntax to barely exist. By contrast Rust favors explicitness, demands a lot ceremony, and is very syntax-heavy. These languages are antithetical in so many ways. It's fairly subjective, so I would not try to convince you that Rust is more similar to C than Python, but many of the points you brought up apply to virtually every modern mainstream language. It's hard to imagine why Python would come up as a comparison point for Rust unless C and Python were literally the only other languages you had ever programmed with.
mastrsushi 5y ago
Rust sounds like a pretty promising language. Considering in the future everything will run in garbage collected VMs written in C++ anyway ;)
- oriolid 5y ago
  Nope. In the future it's going to be JavaScript engines all the way down.
  - mastrsushi 5y ago
    How can a js engine self host?
osigurdson 5y ago
Rust is for the true Scotsman.
- osigurdson 5y ago
  PS - I really like Rust.
yagizdegirmenci 5y ago
> Rust Makes You a Better Overall Programmer 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.
- Koshkin 5y ago
  Well, it's like saying that wearing a straightjacket makes you a better person.
  - runarberg 5y ago
    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. 1: https://news.ycombinator.com/item?id=20455860 https://news.ycombinator.com/item?id=20455860 2: https://news.ycombinator.com/item?id=20469600 https://news.ycombinator.com/item?id=20469600
    - Koshkin 5y ago
      > I don’t see Neither do I.
  - kazinator 5y ago
Koshkin 5y ago
Depends on the meaning of the word 'professionals.' Most of those who earn their living by coding (which is whom I would call professionals), use JavaScript, C++, Java, or C# - and, I'm afraid, will continue to do so for many years to come.
zabzonk 5y ago
Could equally well say "C++ is for professionals", or "Java is for professionals" and so on ad nauseam, with pretty much the same specious justifications.
pizza234 5y ago
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.
- skohan 5y ago
  > 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.
snake_case 5y ago
A few years back I chose Rust as the language I was going to build side projects with. I started out building a wasm A* pathfinding demo [1] to get a better hang of it. A little bit later I wrote a CLI task runner [2] which is defined by a simple markdown file. I find Rust to be perfectly aligned with the goals of a CLI utility: single deployable binary and very low startup cost. Most recently I launched a side project [3] (a jigsaw puzzle website) using Rust as my backend API service. I've been slowly building up a server framework over the years and finally was able to put it to use! Yes, it took me much longer to ship something in Rust versus other languages I'm more familiar with. But after learning Rust for a few years now, it doesn't take me much more time to build a feature than it would in another language. Early on, I ran into a lot of borrower issues and got stuck many times. But after I got over those problems, I realized that for any future hurdles I would face, I just needed to keep pushing and eventually I would find a solution. I have found that with game development or heavily stateful apps, I tend to run into borrower issues more often. But for an API service with a simple input and output, I almost never run into borrower issues. [1]: https://github.com/jakedeichert/wasm-astar https://github.com/jakedeichert/wasm-astar [2]: https://github.com/jakedeichert/mask https://github.com/jakedeichert/mask [3]: https://puzzlepanda.com https://puzzlepanda.com
geodel 5y ago
The way I see is Rust for people who love to write about writing code quite a bit more than writing code itself.
f154hfds 5y ago
I have to concur with the author on Rust. I remember when I read the book a few years ago I had just spent several years doing professional development in C++ and Python, and had recently discovered the GIL much to my dismay. After reading the Book I felt like I stepped through some proverbial door and could never go back. The features by themselves aren't really that remarkable but all of them together in one package - every time I use Python or C++ now I want Rust syntax, tooling, etc. Now, my biggest critique - because of Rust's emphasis on static dispatch and monomorphization (good decisions all around if you ask me), plus the fact that lifetimes provide their own type dimension - I find that open source projects can have absolutely monstrous types, impossible to reason about. It's tough because I prefer the WYSIWYG templating Rust offers over C++ duck typing any day but many of these crates' types are too complex. In fairness, most of the most egregious cases were due to the lack of const generics and those cases are quickly improving. As an example, I've been playing around with websockets recently and ran into this type: https://docs.rs/websocket/0.26.2/websocket/server/upgrade/struct.WsUpgrade.html https://docs.rs/websocket/0.26.2/websocket/server/upgrade/st... Note 4 different impls, each with its own generic requirements! I'm sure each case makes sense somehow, but it sure complicates my life when I want to use a function and find it isn't implemented for _my_ WsUpgrade.
hderms 5y ago
Anyone who has a bunch of rust experience: does writing things like mutable tries, or other data structures with complex ownership semantics ever become truly natural? I find rust really straightforward to write when the ownership is straightforward, but I find myself out of my depth in a lot of cases.
valand 5y ago
Even learning Rust on the surface already change a lot on how you perceive errors, type-based error, thread-safety, expression-oriented code and lifetime. I write typescript for work. I have adapted some concepts such as the encoding invariants into type (using a proven library such as fp-ts and io-ts) and using return over throw for error handling has been yielding better and scalable code. Not to mention Rust's types for managing concurrency and shared objects, like Rc, Arc, Mutex, that drive the architecture of your software. I have been doing a similar thing in my projects in other language and the impact has been very positive Edit: typo

138 points by indygreg2 5y ago

> To me, Rust introduced a number of new concepts, like match for control flow, enums as algebraic types, He must be joking.

TheAdamAndChe 5y ago
When rephrased as "Rust introduced to me a number of new concepts, like match for control flow, enums as algebraic types," it's much more clear what he means. We all learn somehow.
oytis 5y ago
He means Rust introduced these concepts to him, not in general.
danpalmer 5y ago
The author does mention a Haskell/Scala like language missing from their list of languages they have written, but then they do include Erlang which I believe has pattern matching as a fairly core construct? This does lead me to doubt how much Erlang they've written, and in turn how much they've written across all of the languages mentioned.
- StreamBright 5y ago
  Exactly. How can somebody claim to program in Erlang and also claim that Rust introduced pattern matching to them? Erlang has the best pattern matching abilities and it is all around in every single Erlang code I have ever seen.
deleted 5y ago
[deleted]
VBprogrammer 5y ago
I think you might be misinterpreting that as "Rust introduced these things" rather than "I learned about these things from Rust".
- ocschwar 5y ago
  Also, Rust introduced the idea of these things in a systems language.
  - EE84M3i 5y ago
    Popularized. Many others did it first. ATS comes to mind.
- StreamBright 5y ago
  See above.
masklinn 5y ago
The author specifically and explicitly pointed out 3 times in 2 paragraph that these were new to them, not to the world at large. In fact, they spelled this out very explicitely in the paragraph following the one you selectively quoted: > Many of the new concepts weren't novel to Rust. But considering I've had exposure to many popular programming languages, the fact many were new to me means these aren't common features in mainstream languages. And… they're right. Other languages cropped up with overlap around the same time (mostly Swift), but sum types, pattern matching, option types, … were not common features, and borrow checking remains rather unique.
- StreamBright 5y ago
  He also claimed that he programmed in Erlang. How can you program in Erlang without pattern matching?

colesantiago 5y ago

TL;DR? That looks like a very long essay / dissertation just to say 'I love rust'.

jmull 5y ago
> a very long essay / dissertation just to say 'I love rust'. I think you nailed it.
ModernMech 5y ago
After 14k words I think I've come to the TL;DR at the end: "I am irrationally effusive about Rust."
void_mint 5y ago
TL;DR: Author likes Rust. Rust exposed them to new things. The title is totally misleading and irrelevant.
jvanderbot 5y ago
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.
- otabdeveloper4 5y ago
  At this point Rust is not the prmary ecosystem for anything. The important and exciting new things are written in C++, not Rust. Rust has no advantages over C++ once you know C++.
  - neonological 5y ago
    This statement is wrong. Rust has many advantages over C++. Knowing c++ doesn’t make these advantages disappear. It’s like saying you know assembly language and can write 100% bug free code in assembly so C++ has no advantage over it. Realistically, both languages have advantages and disadvantages.

ahelwer 5y ago

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.

ajross 5y ago
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.
- sanxiyn 5y ago
  No, borrow checker's formal rules are rather simple. Here it is: It is an error to access a place, when an access conflicts with a loan, and the loan is live.

ocschwar 5y ago

The title implied that it's not for amateurs, and now that I have some data about Rust and teenagers, I can say it very much IS for teenagers. After one afternoon wrestling with GDB and C code, they're ready to put up wrestling with the borrow checker.

CodeIsTheEnd 5y ago
While in many cases that may be the implication, the author clearly states that is not their intention in the first few paragraphs: > 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.

skohan 5y ago

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.

kzhukov 5y ago
> safety-critical applications 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).
- wyldfire 5y ago
  '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.
  - kzhukov 5y ago
    That were just the examples when Rust is not really suitable as a drop-in replacement for C/C++. Of course, if your platform is well-supported by Rust compiler and you don't have to write safety critical applications, then using Rust is just a matter of choice. I don't argue whether it's good or bad language. It's a quite interesting one with its own pros and cons. If it fits you, then it's great, but you should know its limitations.

judofyr 5y ago

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.

mnd999 5y ago

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.

msla 5y ago
> 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.
skohan 5y ago
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.
- mnd999 5y ago
  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.

noisy_boy 5y ago

> 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.

jmull 5y ago
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.)

lmilcin 5y ago

> 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. I think the title is a little bit misleading and paired with the first sentence invites flame, but this one in the middle of article sums it up much better. With some languages you pay some special costs that are only recovered for certain types of applications. For example, programming in C is slow, tedious and bug-prone (as compared to Python) but it is easier to solve some types of problems (like writing system software, controlling memory layout for performance, conserve resources, etc.) For most projects the cost may be too high but if you are one of certain types of projects the pros will outweigh the cons. In general, when programming with strong types you pay for long term maintainability (ability to automatically ascertain correct type of object at any point and extra features that come from it). In Rust you pay even more for even more benefit in controlling the types and ownership of the data which means this environment should be thought as geared even more towards long term maintainability.

deleted 5y ago

[deleted]

pantulis 5y ago

"(...) Rust feels more like Python than C. (...)" This feels like a very powerful assertion. Does the rest of the HN audience agree with this? If this is true, how long did it take?

skohan 5y ago
I'm a bit confused by this take. With Rust you're constantly thinking low level details, like which type of reference something is. I would place it closer to C than Python, but closer to C++ than either.
- estebank 5y ago
  I wouldn't say that thinking about ownership is "low level details". You are (or should?) always having to think about this when building APIs. The difference is that in for example Python you don't have a way to encode that information and enforce it. I would say that the "feeling" of writing on a high-level language comes from a few ergonomic features: - Match ergonomics, so that you have to think about borrowing less in patterns - The compiler providing suggestions for those cases where you must specify them - Type inference - Iterators letting you write fairly functional code Things like having to write &*foo[..] or .as_mut_ref() are indeed "warts" when you don't care about those details, but they happen uncommonly enough that it isn't perceived as an onerous cost.
  - skohan 5y ago
    > You are (or should?) always having to think about [ownership] when building APIs. This isn't strictly true. For instance Swift uses value semantics, which is equivalent to adding an implicit `.copy()` in rust every time most variables are passed around. It obviates a lot of the low-level details, at the cost of performance and control. This is a lot more "python-like" in my opinion, where having to hold these details in your mind is very much against the design priorities of python. Python wants everything to be implicit, to eliminate tedium wherever possible, and for syntax to barely exist. By contrast Rust favors explicitness, demands a lot ceremony, and is very syntax-heavy. These languages are antithetical in so many ways. It's fairly subjective, so I would not try to convince you that Rust is more similar to C than Python, but many of the points you brought up apply to virtually every modern mainstream language. It's hard to imagine why Python would come up as a comparison point for Rust unless C and Python were literally the only other languages you had ever programmed with.

mastrsushi 5y ago

Rust sounds like a pretty promising language. Considering in the future everything will run in garbage collected VMs written in C++ anyway ;)

oriolid 5y ago
Nope. In the future it's going to be JavaScript engines all the way down.
- mastrsushi 5y ago
  How can a js engine self host?

osigurdson 5y ago

Rust is for the true Scotsman.

osigurdson 5y ago
PS - I really like Rust.

yagizdegirmenci 5y ago

> Rust Makes You a Better Overall Programmer 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.

Koshkin 5y ago
Well, it's like saying that wearing a straightjacket makes you a better person.
- runarberg 5y ago
  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. 1: https://news.ycombinator.com/item?id=20455860 https://news.ycombinator.com/item?id=20455860 2: https://news.ycombinator.com/item?id=20469600 https://news.ycombinator.com/item?id=20469600
  - Koshkin 5y ago
    > I don’t see Neither do I.
- kazinator 5y ago

Koshkin 5y ago

Depends on the meaning of the word 'professionals.' Most of those who earn their living by coding (which is whom I would call professionals), use JavaScript, C++, Java, or C# - and, I'm afraid, will continue to do so for many years to come.

zabzonk 5y ago

Could equally well say "C++ is for professionals", or "Java is for professionals" and so on ad nauseam, with pretty much the same specious justifications.

pizza234 5y ago

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.

skohan 5y ago
> 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.

snake_case 5y ago

A few years back I chose Rust as the language I was going to build side projects with. I started out building a wasm A* pathfinding demo [1] to get a better hang of it. A little bit later I wrote a CLI task runner [2] which is defined by a simple markdown file. I find Rust to be perfectly aligned with the goals of a CLI utility: single deployable binary and very low startup cost. Most recently I launched a side project [3] (a jigsaw puzzle website) using Rust as my backend API service. I've been slowly building up a server framework over the years and finally was able to put it to use! Yes, it took me much longer to ship something in Rust versus other languages I'm more familiar with. But after learning Rust for a few years now, it doesn't take me much more time to build a feature than it would in another language. Early on, I ran into a lot of borrower issues and got stuck many times. But after I got over those problems, I realized that for any future hurdles I would face, I just needed to keep pushing and eventually I would find a solution. I have found that with game development or heavily stateful apps, I tend to run into borrower issues more often. But for an API service with a simple input and output, I almost never run into borrower issues. [1]: https://github.com/jakedeichert/wasm-astar https://github.com/jakedeichert/wasm-astar [2]: https://github.com/jakedeichert/mask https://github.com/jakedeichert/mask [3]: https://puzzlepanda.com https://puzzlepanda.com

geodel 5y ago

The way I see is Rust for people who love to write about writing code quite a bit more than writing code itself.

f154hfds 5y ago

I have to concur with the author on Rust. I remember when I read the book a few years ago I had just spent several years doing professional development in C++ and Python, and had recently discovered the GIL much to my dismay. After reading the Book I felt like I stepped through some proverbial door and could never go back. The features by themselves aren't really that remarkable but all of them together in one package - every time I use Python or C++ now I want Rust syntax, tooling, etc. Now, my biggest critique - because of Rust's emphasis on static dispatch and monomorphization (good decisions all around if you ask me), plus the fact that lifetimes provide their own type dimension - I find that open source projects can have absolutely monstrous types, impossible to reason about. It's tough because I prefer the WYSIWYG templating Rust offers over C++ duck typing any day but many of these crates' types are too complex. In fairness, most of the most egregious cases were due to the lack of const generics and those cases are quickly improving. As an example, I've been playing around with websockets recently and ran into this type: https://docs.rs/websocket/0.26.2/websocket/server/upgrade/struct.WsUpgrade.html https://docs.rs/websocket/0.26.2/websocket/server/upgrade/st... Note 4 different impls, each with its own generic requirements! I'm sure each case makes sense somehow, but it sure complicates my life when I want to use a function and find it isn't implemented for _my_ WsUpgrade.

hderms 5y ago

Anyone who has a bunch of rust experience: does writing things like mutable tries, or other data structures with complex ownership semantics ever become truly natural? I find rust really straightforward to write when the ownership is straightforward, but I find myself out of my depth in a lot of cases.

valand 5y ago

Even learning Rust on the surface already change a lot on how you perceive errors, type-based error, thread-safety, expression-oriented code and lifetime. I write typescript for work. I have adapted some concepts such as the encoding invariants into type (using a proven library such as fp-ts and io-ts) and using return over throw for error handling has been yielding better and scalable code. Not to mention Rust's types for managing concurrency and shared objects, like Rc, Arc, Mutex, that drive the architecture of your software. I have been doing a similar thing in my projects in other language and the impact has been very positive Edit: typo