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.

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.

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

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.

TL;DR?

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

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.

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

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.

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

[2]: https://github.com/jakedeichert/mask

[3]: https://puzzlepanda.com

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

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

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

"(...) 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?

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.

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.

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.

Rust is for the true Scotsman.

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

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

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

He must be joking.

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

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

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.

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.

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.

Yes, lots of up front things that pay off after your code base gets larger and/or you ship.

Sure! So I'm trying to implement this feature: https://github.com/tree-sitter/tree-sitter/issues/982#issuec...

And here's my branch (you can see the latest commits to see the file I'm modifying): https://github.com/ahelwer/tree-sitter/tree/testfile-separat...

I haven't had a chance to go through and add clones everywhere, and will be away at a PT appointment for the next hour or so, but would appreciate any pointers you can give.

  diff --git a/cli/src/test.rs b/cli/src/test.rs
  index ac4807bf..8b9882ab 100644
  --- a/cli/src/test.rs
  +++ b/cli/src/test.rs
  @@ -410,16 +410,17 @@ fn parse_test_content(name: String, content: String, file_path: Option<PathBuf>)
           .map(|b| String::from_utf8_lossy(b).to_string())
           .map(|s| escape_reserved_regex_chars(&s));
       
  -    let suffixHeaderPattern : Option<String> = suffix
  +    let suffixHeaderPattern : Option<String> = suffix.as_ref()
           .map(|s| String::from(r"^===+") + &s + r"\r?\n([^=]*)\r?\n===+" + &s + r"\r?\n");
       
  -    let suffixDividerPattern: Option<String> = suffix
  +    let suffixDividerPattern: Option<String> = suffix.as_ref()
           .map(|s| String::from(r"^---+") + &s + r"\r?\n");
   
  -    let headerRegex = suffixHeaderPattern
  -        .and_then(|s| ByteRegexBuilder::new(&s[..]).multi_line(true).build().ok())
  -        .as_ref()
  -        .unwrap_or(&HEADER_REGEX);
  +    let headerRegexFromSuffixHeaderPattern = suffixHeaderPattern.as_ref()
  +        .and_then(|s| ByteRegexBuilder::new(&s[..]).multi_line(true).build().ok());
  +
  +    let headerRegex = headerRegexFromSuffixHeaderPattern
  +        .as_ref().unwrap_or(&HEADER_REGEX);
   
       // Identify all of the test descriptions using the `======` headers.
       for (header_start, header_end) in headerRegex

    error[E0382]: use of moved value: `suffix`
       --> cli/src/test.rs:416:48
        |
    406 |     let suffix = FIRST_HEADER_REGEX
        |         ------ move occurs because `suffix` has type `std::option::Option<std::string::String>`, which does not implement the `Copy` trait
    ...
    414 |         .map(|s| String::from(r"^===+") + &s + r"\r?\n([^=]*)\r?\n===+" + &s + r"\r?\n");
        |          ------------------------------------------------------------------------------- `suffix` moved due to this method call
    415 |
    416 |     let suffixDividerPattern: Option<String> = suffix
        |                                                ^^^^^^ value used here after move
        |
    note: this function consumes the receiver `self` by taking ownership of it, which moves `suffix`
       --> /Users/ekuber/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/library/core/src/option.rs:451:38
        |
    451 |     pub fn map<U, F: FnOnce(T) -> U>(self, f: F) -> Option<U> {
        |                                      ^^^^
    
    error[E0716]: temporary value dropped while borrowed
       --> cli/src/test.rs:419:23
        |
    419 |       let headerRegex = suffixHeaderPattern
        |  _______________________^
    420 | |         .and_then(|s| ByteRegexBuilder::new(&s[..]).multi_line(true).build().ok())
        | |__________________________________________________________________________________^ creates a temporary which is freed while still in use
    421 |           .as_ref()
    422 |           .unwrap_or(&HEADER_REGEX);
        |                                    - temporary value is freed at the end of this statement
    ...
    425 |       for (header_start, header_end) in headerRegex
        |                                         ----------- borrow later used here
        |
        = note: consider using a `let` binding to create a longer lived value

    let suffixHeaderPattern: Option<String> = suffix
        .as_ref()
        .map(...);

    let headerRegex = suffixHeaderPattern
        .as_ref()
        .and_then(|s| ByteRegexBuilder::new(s).multi_line(true).build().ok())
        .unwrap_or(HEADER_REGEX.clone());

    error[E0308]: mismatched types
      --> src/main.rs:10:22
       |
    10 |         .map(|s| bar(s));
       |          ---         ^ expected `&Struct`, found struct `Struct`
       |          |
       |          help: consider using `as_ref` instead: `as_ref().map`

I have to agree that at the beginning those unfortunate names (Arc, Cow) confused me more than they should, given that I know perfectly well what Copy on Write and reference count means.

If only it was spelled CoW and ARC I would very quickly grasp it (probably).

But it's an extremely minor inconvenience and arguably makes the whole thing very memorable