Earlier quoted context omitted.
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…
By the same author, nay help: https://www.lpalmieri.com/posts/fast-rust-docker-builds/
Zero to Production in Rust
51–60 of 195 posts
Re: Zero to Production in Rust
#52I'm pretty interested in learning rust to build APIs, but I'm already productive with Java and Node/Typescript and wonder if it would be worth it, aside from being interesting. Anyone up for giving me an elevator pitch that it would be? Or, also interested in confirmation that it wouldn't!
Re: Zero to Production in Rust
#53Earlier quoted context omitted.
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.
Plus it’s a binary I can drop anywhere, will always be backwards compatible, no updated dependency is going to break it, I’m a fan of Go.
Re: Zero to Production in Rust
#54I'm pretty interested in learning rust to build APIs, but I'm already productive with Java and Node/Typescript and wonder if it would be worth it, aside from being interesting. Anyone up for giving me an elevator pitch that it would be? Or, also interested in confirmation that it wouldn't!
* exhaustive pattern matching
* Result and Option types
* builtin first class unit testing ability
* builtin first class documentation ability
The enforced exhaustive pattern matching tells you “hey you didn’t cover all cases.” Result and Option types make error handling explicit and ergonomic—the notion that each function can either succeed or fail is supported at the language level (in other languages, it’s up to you to ensure you’ve covered all cases and have thought about what “success” and “failure” mean for each function.
Testing is “built right into the language,” it’s frictionless. It’s super easy to write unit tests. You don’t have to canvass and vet a ton of testing frameworks to get going.
Documentation is easy, fun, and quick to write. So, now combine all the above with the culture of detailed documentation Rust has and now you’re really thinking through your codebase—you can use writing docs to tighten up the interfaces, seamlessly transition to writing a test that enforces some invariant, leverage “compiler driven development” to rinse and repeat this process.
The strongest reason to use Rust is that you’ve detailed the requirements for a piece of code and determine Rust is a better fit than LangX. A weaker, but still valuable reason to use Rust is to experience the discipline and idioms Rust enforces/enables and then take that experience back to your native language (I.e. exhaustive matching, which of used in certain ways can be a kind of “proof by cases” that your code does exactly what you expect, then you can easily inspect what you expect via tests).
Re: Zero to Production in Rust
#55Earlier quoted context omitted.
We are using Rust for backend web development and other things. For us, the safety is the critical reason to choose Rust - particularly the thread-safety. Also the relatively small memory footprint compared to something like Java. Performance hasn't driven our decision at all - the number of requests per second is very low. It's correctness that matters. We are a bit unusual because customers have locally deployed se…
Training internally makes a lot of sense, but it's also a huge hurdle and expense if your developers don't already have rust experience. What was the process of proposing rust and getting buy-in like?
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.
Re: Zero to Production in Rust
#56Earlier quoted context omitted.
Hopefully we can have some conversation about the ecosystem and state of rust for backend webapps.
You can link to any kind of meaningful content to do with rust and do that. This is using HN as an ad platform.
Re: Zero to Production in Rust
#57Earlier quoted context omitted.
> 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...
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 cod…
Especially for someone unfamiliar with rust, it can be hard to really know why someone is using self, &self, or &mut self. Yet the code reads the same.
That's the funny thing about rust.
Re: Zero to Production in Rust
#58Earlier 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…
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 f…
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.
Re: Zero to Production in Rust
#59Earlier quoted context omitted.
We are using Rust for backend web development and other things. For us, the safety is the critical reason to choose Rust - particularly the thread-safety. Also the relatively small memory footprint compared to something like Java. Performance hasn't driven our decision at all - the number of requests per second is very low. It's correctness that matters. We are a bit unusual because customers have locally deployed se…
Any reason to choose Rust over Go in your case?
Does Go offer similar guarantees for concurrency?
Re: Zero to Production in Rust
#60Earlier quoted context omitted.
"good concurrency" Async rust is very messy and a pretty big issue atm. The tooling on the IDE side is subpar compared to Go.
I'd be interested in hearing what you think is a problem in async Rust.
It's not like JavaScript or Go where everything is just built into the language afaik.