Zero to Production in Rust

Map/Filter/Collect/Reduce, all built on generics make code much more readable than their Go counterparts. I can make a frequency map simply by drain and collecting a vec into a hashmap - maybe 4 lines of code.

The density comes from being able to share common functionality behind generic interfaces, so I don’t have to reinvent the wheel for every new project.

I find that most projects I make look the same internally, unless I start pulling some “clever” optimizations like custom allocators or self-referential structs.

In my experience, Rust code is relatively easy to read, even by developers with no Rust experience.

Of course, you can write hard to read code. But that's not typically what comes out of a process of writing production software.

That's not to say that someone with no experience will fully understand the ownership transfer & borrowing that's happening, but that's just stuff you need to do for the compiler. Reading code that already compiles, you can mostly ignore that and focus on the program logic.

Can you expand on “needs a C++ or Scala or Haskell background”? C++ would probably help you appreciate what Rust brings to the table, but I don’t see how any of them fit in when learning to use Rust in practice.

> but there’s no denying that Go is much easier to program than Rust.

Well here I am to deny it. I personally find Go super hard to write anything that is not a few lines of glue code (and in that case I just reach for Node).

Rust made me lazy. It's just so easy to be guided by the compiler and the architecture that emerges naturally is just so beautiful and easy to navigate.

I don't like Rust for its safety guarantees, I just find it pleasurable to write and even better to read. Safety is just a plus.

I'm not saying this is a universal truth though, Rust just fits my mental model. It isn't even a matter of past experience: I code frontend JS for a living (though I've been exposed to all kinds of code throughout the years) and I actually enjoy JS.

I tried really hard to like Go. I just couldn't.

TBH I'm kind of frustrated with Swift's lack of dynamic dispatch options, so things like network models, network service interfaces and testing mocks need to be code generated, while in JVM and Objective-C land, you don't need to do the same.

Swift's Codable is doing code gen under the hood, so it also has a binary size and compile time cost.

Swift also doesn't scale that well with core size like many other languages do, so your compile time is not easily fixable with large thread ripper style workstations.

Do you have similar issues with golang and rust? At least golang was designed to be compiled fast.

I dabbled a bit with Go and now I am trying Rust. I did find programming in Rust a tad difficult than with Go, but as I get used to concepts (borrow checking, Move vs/ copy, lifetimes etc.) I am liking it better than Go. With Go I feel there is an element of deceptive simplicity, which catches up with you as the problem space gets complex. I never became comfortable with doing object oriented programming with Go, which has not been the case with Rust. In addition in Go I find the project setup and settings like GOPATH, GOBIN quite confusing. In contrast Rust has _cargo_ which has less cognitive overload.

I think it would be good if one dabbles a bit with both and pick one which one feels resonance with. That being said probably one need to give a bit longer time for Rust to be comfortable with it.

I'd be interested in hearing what you think is a problem in async Rust.

To write custom futures? Yes, you need to understand Pin and some advanced stuff.

To use? Eh - I just turn on async_std with the Tokio flag and write go-like code with async tasks. No issues thus far.

I switched to rust-analyzer and it made a huge difference. Have you tried it?

With the caveat that you have to use _nightly_ Rocket straight from GitHub (but still stable Rust, which is definitely preferable).

They're working on it but they don't have an actual released version that works on stable Rust. So you'd end up having to pick stable Rust or stable framework, which is not great.

Check out tide. It's still very early days for it, but is in my opinion the easiest to use and I'm betting in the long term will win out as the "express" of the rust world. It has very straightforward routing and middleware semantics which covers the majority of the "base" needs for most web server backends.

We've been using Actix.

We evaluated several frameworks and liked the model that Actix has and also its relative maturity (for example documentation / examples). It has been pretty straightforward to work with - including doing things like custom authentication and REST endpoints that dynamically exist.

For the drama, I guess you are talking about the situation that used to exist where Actix had hundreds of unsafe blocks. That's pretty much resolved now, with perhaps a handful of performance critical unsafe blocks left.

We use hyper + tokio directly, with OpenAPI generated API integration.

A couple of reasons: 1. We like the thread-safety properties that Rust offers 2. We don't have any Go experience

Does Go offer similar guarantees for concurrency?

We initially used it on a small project that had the requirement that the chances of a crash / failure should be very low because it would be used as a remote control process for a wider system. We had good success there and so the company was keen to use it in more places. It's now formally "adopt" on our technology roadmap.

We've actually bootstrapped relatively easily. We have a some developers who have picked it up quite easily, perhaps with some pairing. We run an hour session every week where all the Rust developers get together to share production code and present on Rust topics. The discussion focusing on Rust production code has been particularly helpful.

The languages available today are a vast improvement over what was around 15 years ago. This isn't even all that specific to Rust, even many languages which existed back then have improved massively.

>I would say the biggest barrier is developers not wanting to jump on yet another "this language will solve all your problems, trust me" train.

Never underestimate what a team of overly enthusiastic junior engineers are capable of :-)

Right, it’s not like Rust has already influenced improvements in other languages and package managers. Definitely a fad

Languages and tools have helped people write better software over the years, no?

I really like Tony Hoare's quote on this topic:

    ... a programming language designer should be responsible for the mistakes that are made by the programmers using the language.
    [...]
    It's very easy to persuade the customers of your language that everything that goes wrong is their fault and not yours. I rejected that...

http://blog.mattcallanan.net/2010/09/tony-hoare-billion-doll...

If anyone is unfamiliar with Tony Hoare he's the creator of quicksort, Hoare Logic, CSP, worked on Algol, created null, holds a turing award, and much more.

>> My experience in my 15 years in software, is that good developers solve problems, not languages or tools.

At 15 years I thought the same. At 25 years I have come to really appreciate some tools ability to help.

There are a lot of tools that claim to help but don't. Beware of tools that try to manage complexity - what you probably need is to reduce complexity. I'm looking at Eclipse and Matlab in particular, and anything similar (think enterprise software).

Git - awesome. Using it on 1-man projects too.

Sanitizers for C++ I've seen these identify bugs that hadn't manifested visibly yet.

Rust - well I want to write more because it doesnt require additional tooling to write correct code. Remember reducing complexity.

> In 2021 what web development stack is making you write threaded code?

Go? I've had thread related bugs in go related to serving our UI.

Generally any reasonably efficient stack where you need to pull on more than 1 CPUs worth of resources to quickly serve a request. And most stacks where you need to make multiple requests to other services simultaneously to quickly serve the original request.

My very first production Rails app involved a C extension to do some heavy processing. Not all web applications are a thin UI over a database table (not that there’s anything wrong with that, mind you…)

The framework might not make you but that doesn’t mean your code won’t need such things.

> In 2021 what web development stack is making you write threaded code?

Go uses "green" (user-level) threads.

>> you’re slower than a dev team working in a traditional language (java, go, python, …)

If anything my experience is that it's quite productive to work in Rust. For example, compared to Python (which you mention) we catch bugs earlier (with the compiler) rather than later (system test) and so development is faster. Shift left.

It's particularly important for races because they are some of the most difficult bugs to find and fix.

> Except you have a self-inflicted problem - you’re slower than a dev team working in a traditional language (java, go, python, …) and you can’t easily hire talent.

I'm radically more productive with Rust vs Python (having been using both for >5 years). Our codebase is split between the two and I'm working to move virtually all Python code to Rust because it's become such a burden.

* IDE experience is considerably worse in Python due to lack of types (we use type hints aggressively, but that only helps so much and not at all for 3rd party libs).

* Working with JSON is considerably worse in Python in my experience.

* Package management and building is considerably worse in Python. It's still difficult to manage a many-package project and get what Rust provides by default, like workspaces, cryptographic lockfiles, etc.

* Error handling and other patterns in Rust make it far easier to write in a robust way or otherwise correct in the future. Rust is far more resilient to errors during refactoring - I'm very afraid to touch some of our Python code, by contrast.

* Mypy is nowhere near as good as rustc. Mypy errors are traditional "expected blah got blah", or sometimes "expected List[T] got List[<nothing>]" and other unhelpful errors. Rust errors are almost always expressive and helpful - often telling you exactly how to fix your code (to an insane extent - like using a heuristic to tell you where you probably forgot a curly brace).

Mypy is impossible to use with the strictest settings. Lack of recursive types makes working with JSON blobs impossible, makes it impossible to do circular generics (you can't do what Rust does with From/Into as far as I know because of this).

And then there's shit like circular imports being a runtime error, and other little papercuts in the language that are just littered everywhere.

I actually really like Python a lot, despite all of this, but I'll never choose it for web services again.

And hiring hasn't been a problem at all at my company, nor was it at Dropbox where I worked previously

Most people are happy to teach themselves the basics through some reading of https://doc.rust-lang.org/book/ then a mixture of pairing, code walkthroughs and short presentations.

We will also run a training course next month just based on the Rust book plus some workshop examples.

Please file bugs for hard to understand error messages! We treat them as such. We’d rather have too many reports than not enough.

Picking up Rust is not the same as picking up Python or even Java, in my opinion.

I started learning Rust and C++ at the same time, coming from a world of Java, Python, and Ruby.

If I need to solve a problem in C++, I would much rather write Rust because the compiler actively screams at you when you do bad things.

And in my opinion, the challenging part is learning what those bad things are. In other languages, the compiler doesn’t care. You immediately see your program crash or things fail in subtle, hard to reproduce ways later in production. Rust changes that model.

I disagree with you on the documentation. I think the Rust documentation is superb. I have yet to see any language give nearly as meaningful information when your code fails to compile. Secondly, Rust front loads and throws issues immediately in your face, as opposed to having you discover problems in your code at runtime. I don’t think that makes Rust difficult - it’s forcing you to think about your choices. And particularly it’s making you think about concepts that perhaps you completely overlooked in other languages - thinking about stack vs heap allocation, moving semantics, shared ownership, etc.

If you want to quickly prototype something, Rust isn’t the best language IMO. But if I have a choice between C++ and Rust, I’d go with Rust anyday. If I was starting a new project from scratch and it was more of a web service, I might go with another language over Rust only because I’m more of an expert in Java, Python, etc. and it’s easier to hire developers for those languages than Rust.

But I’m biased. Rust has a special place in my heart. It’s the first language I’ve learned in many years where I felt some sense of accomplishment and did not at all feel like “Oh great, another tool that fundamentally doesn’t add value.”

For my use cases involving Java and iOS interoperability in a multi threaded environment, nothing else came even close.

We can probably all agree that about half of C++ needs to be eliminated or redesigned.

We probably can't agree on which half. :-)

> Rust does have a lot of complicated stuff, but almost all of it secretly turns up if you wanted to be good at C++ too.

This is mostly true. As FP and Rust have shown us, if you can treat an input data set as immutable, while building up the result data, you have a much easier time. I bring those patterns into my C++, which speaks to your point.

I'd offer one exception though: mutability xor aliasability on a per-object basis is something I wouldn't take to my C++ code. It may be the core of Rust, and it's a neat tradeoff that enables some of its other benefits, but the indirect complexity cost is too high, IME.

> Oh there is just no way it's harder to learn than C++.

I think the jury's still out on this one.

C++ has complexity, but has the benefit of a gradual learning curve. You can start with C, slowly add `virtual`, then add templates, then add the STL.

Rust has just as much complexity, and forces it all on you at once. Because of that, it is harder to learn.

Some people say Rust's rules are intuitive. I have to disagree. These years of working with Rust and teaching Rust to others have made it clear to me: though the basic concepts are simple, the architectural implications and workarounds are not.

I'm not saying C++ or Rust is better. But C++ is slightly easier to learn, IMO.

I commonly hear "But it's hard to learn how to use C++ safely!" and I generally agree with that. ASan has made things much easier in that regard, but C++ will probably never catch up enough for some use cases.

> There is a sub-tribe within C++ that wants a simpler "subset of the superset". They believe C++ could be made into a healthy modern language which is practical to teach as a first language to students and still has excellent performance and hardware compatibility.

Yes. There is a "c++" which is simple, consistent, and fairly easy to use, but it's buried in the cruft of decades.

The biggest complaint about Rust's "hardness" is ownership and move/borrow mechanics. Modern C++ has std::move, ownership, and lifetime considerations.

Add to that smart pointers, initialization, a bloatastic std lib, an even more bloatastic pseudo-std lib that you need if you have to interop with anything older than 14 (boost), umpteen different build systems, compilers, toolchains, and all that on top of almost-not-quite-C-superset, and you have a massive surface area.

On another HN thread, someone commented that developers took 3x longer to get to speed in a Rust codebase than C++. I say no way, Jose. I was committing PRs in Rust within a few months. I still don't feel comfortable in C++ of any serious complexity. That's with 2 years of C experience, 1 yr of intensive C++, and like, a few months of rust.

This "flavor of the month" language was released 10 years ago and has been the most loved programming language in surveys for several years now. It is also the language of the fastest backend web framework.

I don't think rolling one's eyes is the appropriate reaction when someone pushes for it. Depending on your requirements, there are definitely cases when rust is the best choice for a web backend. Especially when moving fast and breaking things is not an option, such as in the author's case.

I accept all your points, but comparable runtime performance? That's the only reason that people away from node/ruby/python towards gaoling.

Correct – it took about 6 months for people to become fully productive in Rust, which matches what I've heard elsewhere.

Though I will note that the Rust compilation times were also far more painful than I'd expected – even the tiny (~5k sloc) app at hand would take what felt like a minute to recompute the red squigglies in my editor.

TS felt slow if it took 5-15sec, and Sorbet (for Ruby) was usually <3sec IIRC, so a minute+ was pretty bad.

Rust was in the realm of "just don't use this language if you have ADHD" since you really can't make progress without the compiler's exacting approval, and I'd constantly get distracted while waiting.

It would be interesting to know where the difficulty was in training juniors to write comparatively simple code in Rust. Was it all about fighting the borrowck, or was there more to it?

HN pretty much originally existed as way to advertise ycombinator. Entrepreneurs make up a huge HN demographic. Marketing, sales, and advertising is a regular topic. “Show HN” is a special tag for certain kinds of marketing to HN users. Doesn’t seem out of place to me, to be honest.