Live data from Hacker News

Zero to Production in Rust

zero2prod.com

21–30 of 195 posts

Re: Zero to Production in Rust

#21
post #11

Earlier quoted context omitted.

Wouldn't Golang be the TypeScript here as alternative to Rust ?

Why? Golang has a much less advanced type system, comparable runtime performance, a smaller developer community, and a smaller package ecosystem. Plus, if you're building a backend for a webapp, TS allows your engineers to build full-stack features in the same language, avoiding context-switching, code duplication, and other overhead.

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

Re: Zero to Production in Rust

#22
post #12
post #10

Earlier quoted context omitted.

I think "too slow" is "too slow to onboard juniors", not "too slow in terms of performance".

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 Rust was in the…

Make sure you're not using `cargo build` to check your project. `cargo check` (the thing that makes your squiggles red) has never once taken me a minute to complete. RLS (the default LSP for rust uses `cargo build` - definitely switch to Rust-Analyzer (the soon-to-be default). I just ran `cargo check` on my workspace (10 crates, about 5k LoC) and it took 3 seconds.

Re: Zero to Production in Rust

#23
post #12
post #10

Earlier quoted context omitted.

I think "too slow" is "too slow to onboard juniors", not "too slow in terms of performance".

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 Rust was in the…

> you really can't make progress without the compiler's exacting approval, and I'd constantly get distracted while waiting

You can use cargo check for that, which is fast. It's only for running tests or the like that an actual build is required. Rust also has IDE integration via rust-analyzer, so the error-marking "squiggles" can be recomputed incrementally.

Re: Zero to Production in Rust

#24

So I've just tinkered around a bit in Rust, and I'm not intimately familiar with the language. My experience has been pretty good, but I don't see how it's a good fit for the web domain. At least not the enterprisey, CRUD, business apps I'm used to building. I'd be curious to hear from people who have been using Rust for their web backends, though. Beyond the classic selling points of speed and safety, what benefits…

We are building openapi-based stuff in Rust at Oxide, and my coworkers gave a talk on the hows and whys: https://www.youtube.com/watch?v=EmSjZbSzA3A

One thing I hear from people more broadly is that Rust’s lower resource usage, in today’s cloud based environments, translates directly to bottom-line savings. It’s not so much speed directly as it is less CPU and memory utilization, letting you do more with less. That matters when you’re paying for what you use.

Re: Zero to Production in Rust

#25

So I've just tinkered around a bit in Rust, and I'm not intimately familiar with the language. My experience has been pretty good, but I don't see how it's a good fit for the web domain. At least not the enterprisey, CRUD, business apps I'm used to building. I'd be curious to hear from people who have been using Rust for their web backends, though. Beyond the classic selling points of speed and safety, what benefits…

The DB space for Rust is a bit young, though there are several good projects like sqlx making it much more pleasant. Rust shares many of the benefits of Go: - statically linked binaries for ease of deployment - good concurrency - builtin testing framework But it's a much sharper tool than Go: - Really great error handling with Result/Option and the ? marker - Like, really really good error handling, esp compared to G…

> When I compare my Rust and Go code, the Rust code ends up being much smaller (LoC) and much more dense/terse.

Yes, but is it more readable too? The obfuscated C contest also tends to produce a lot of dense/terse code, but you probably wouldn't want to use that in a production system...

Re: Zero to Production in Rust

#27
post #12
post #10

Earlier quoted context omitted.

I think "too slow" is "too slow to onboard juniors", not "too slow in terms of performance".

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 Rust was in the…

Ironically, I recently received an ADHD diagnosis…

Re: Zero to Production in Rust

#28
post #25

Earlier quoted context omitted.

The DB space for Rust is a bit young, though there are several good projects like sqlx making it much more pleasant. Rust shares many of the benefits of Go: - statically linked binaries for ease of deployment - good concurrency - builtin testing framework But it's a much sharper tool than Go: - Really great error handling with Result/Option and the ? marker - Like, really really good error handling, esp compared to G…

> When I compare my Rust and Go code, the Rust code ends up being much smaller (LoC) and much more dense/terse. Yes, but is it more readable too? The obfuscated C contest also tends to produce a lot of dense/terse code, but you probably wouldn't want to use that in a production system...

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.

Re: Zero to Production in Rust

#29
post #2

This looks really great. £35 Individual, £100 Team, £600 Company, seems like fair/straightforward pricing for a team that has members who know some Rust but haven't built out a production API with it yet. I wish every tech stack had a book like this, and I think it'll be particularly valuable for an exciting new language with a learning curve like Rust. I will note, though, that I'm currently consulting on a team tha…

at my startup, we built a graphql server in elixir and its been great. very easy to onboard contractors and the language is very straightforward. https://absinthe-graphql.org/

The performance has been excellent compared to similar offerings in django and rails while having better dev productivity than the equivalent nodejs libraries.

Re: Zero to Production in Rust

#30

So I've just tinkered around a bit in Rust, and I'm not intimately familiar with the language. My experience has been pretty good, but I don't see how it's a good fit for the web domain. At least not the enterprisey, CRUD, business apps I'm used to building. I'd be curious to hear from people who have been using Rust for their web backends, though. Beyond the classic selling points of speed and safety, what benefits…

The DB space for Rust is a bit young, though there are several good projects like sqlx making it much more pleasant. Rust shares many of the benefits of Go: - statically linked binaries for ease of deployment - good concurrency - builtin testing framework But it's a much sharper tool than Go: - Really great error handling with Result/Option and the ? marker - Like, really really good error handling, esp compared to G…

I personally prefer Rust to Go for things that have hard resource requirements/limits, but there’s no denying that Go is much easier to program than Rust.

You don’t need to know much more than Python/Ruby to get something done in Go, whereas Rust needs a C++ or Scala or Haskell or whatever background.

Rust places too much mental workload on a programmer to make the compiler happy.

The Go compiler is much more human friendly.

Swift is a nice mix of all worlds, IMHO. Would be nice to see that get more server-side use.

At our Scala-centric company, Go gets used a lot more for one off tasks and microservices.

We rebuilt one Go service in Rust just to get familiar with it and no one has written more Rust since.

Post reply on HN