Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zero to Production in Rust

zero2prod.com

Post reply on HN
Print view View original

121–130 of 195 posts

Re: Zero to Production in Rust

#121

Post by staticassertion »

cjpearson wrote: post #3

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…

Rust makes working with data easy. 'serde' is insanely good, so right off the bat if you're messing with formats like JSON you're going to have a best in class library.

Concurrency is pretty trivial as well with async/await and tokio.

Really good libraries like tracing, tonic, etc.

Plus the tooling is really strong. Package management and building is easy, static bins, etc.

I run a company that uses Rust and hiring isn't hard - it's an advantage. We get really great people who are looking for a place that uses Rust. Or we just train people up - it's not a very hard language.

Re: Zero to Production in Rust

#122

Post by pjmlp »

phibz wrote: post #116
cjpearson wrote: post #3

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…

I implemented a simple blog and resume personal web site using rust. I did it mostly as an exercise. I tried just jumping in and had a lot of trouble. I needed to go back and read the rust book. What I found was relatable to what I knew from Scala and C++ but definitely took some effort to learn compared to something like golang which I picked up in a week. I built using actix 1.x, serde, chrono, rusqlite. I original…

Coding a web app with C++ Builder is like dragging stuff into forms, VB style.

Re: Zero to Production in Rust

#123

Post by tialaramex »

Cyph0n wrote: post #78
ibraheemdev wrote: post #71

Earlier quoted context omitted.

Not the OP, but I agree. Also, coming to Rust from a higher level language is very hard. Beginners who do so cannot understand why something like this: fn foo() -> &str { &String::from("foo") } Does not work. Whereas coming from C or C++, you will appreciate the safety guarantees the borrow checker is giving you. Learning Rust coming from an OO background is also hard, as you have to adapt to the more functional appr…

That makes more sense - it's definitely true that knowing a lower-level language and a functional language gives you a leg up when learning Rust. As for your example, even C and C++ devs would squint a bit at why that code doesn't compile: you're allocating a string on the heap, so why can't you return a pointer to it? Also, I think str vs. String is usually confusing at first, regardless of your background.

I think analogous C++ code is a bug, the text might be a heap allocation (SSO may stash it inside the object) but surely the string object is local and lives on the stack. When the function returns that local object no longer exists and the reference to it is now dangling ?

I would say that the relationship between str and String was what most surprised me. I at first assumed the underlying primitive would be String since str is what you get when you borrow from a String, but it isn't. str is a built-in, whereas String is just a type defined in the (optional, this is a systems language) standard library.

If your environment can't afford memory allocation, you can't have Strings but you can use str just fine, that's a built-in. Since you lack allocators obviously you won't be going around minting new strings but str is perfectly fine for stuff like substring operations or comparisons.

Re: Zero to Production in Rust

#124

Post by kabdib »

tialaramex wrote: post #110
cjg wrote: post #31

Earlier 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…

> I don't think it's any harder to master than some other major languages such as C++ or Java Oh there is just no way it's harder to learn than C++. C++ has the problem that it's all of C (almost everything from C is still in there) plus all the stuff bolted on to achieve C-with-classes when OOP was the new hotness in the 1980s plus then several further evolutions to add major new features, not always in a very consi…

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

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

Re: Zero to Production in Rust

#125

Post by staticassertion »

deeviant wrote: post #68
cjg wrote: post #31

Earlier 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…

> The biggest barrier to adoption, in my opinion, is that people are scared of learning Rust because it has a reputation as being difficult. 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. My experience in my 15 years in software, is that good developers solve problems, not languages or tools.

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.

Re: Zero to Production in Rust

#126

Post by iudqnolq »

pjmlp wrote: post #115
Ar-Curunir wrote: post #98

Earlier quoted context omitted.

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

Making other languages take affine times more seriously, I agree. Package managers, which ones? Perl was the very first, almost every language has their own, and even the growing C++ ones are able to use binary libraries on their package managers.

Rust's package manager has many great features, but it went the other way around. Mozilla hired one of the authors of rubygems and yarn to re-implement their better ideas.

Re: Zero to Production in Rust

#127

Post by staticassertion »

pjmlp wrote: post #115
Ar-Curunir wrote: post #98

Earlier quoted context omitted.

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

Making other languages take affine times more seriously, I agree. Package managers, which ones? Perl was the very first, almost every language has their own, and even the growing C++ ones are able to use binary libraries on their package managers.

> Package managers, which ones?

Python's Poetry comes to mind.

Re: Zero to Production in Rust

#128

Post by iudqnolq »

zozbot234 wrote: post #83
ibraheemdev wrote: post #64

Earlier quoted context omitted.

Yes, Actix today is much different than Actix from a couple years ago. All the unsafe, save a necessary few has been removed, and the architecture switched from an actor model, to a finagle/tower inspired service model.

> and the architecture switched from an actor model, to a finagle/tower inspired service model Then they really should think about changing their name, seeing as actix the broader low-level framework is supposed to be all about Actors.

Actix the actor framework is essentially dead at this point, I expect eventually it'll be the other way around: "you should change the name of your actor framework, it's confusing given the name of the web framework"

Re: Zero to Production in Rust

#129

Post by steveklabnik »

iudqnolq wrote: post #126
pjmlp wrote: post #115

Earlier quoted context omitted.

Making other languages take affine times more seriously, I agree. Package managers, which ones? Perl was the very first, almost every language has their own, and even the growing C++ ones are able to use binary libraries on their package managers.

Rust's package manager has many great features, but it went the other way around. Mozilla hired one of the authors of rubygems and yarn to re-implement their better ideas.

This is true, but so is the grandparent. Poetry, for example, cites Cargo as an inspiration. build2 describes itself as something "that aims to approximate Rust Cargo's convenience for developing and packaging C/C++ projects." I believe Go's "dep" was Cargo inspired as well, though that didn't work out.

Re: Zero to Production in Rust

#130

Post by staticassertion »

CraigJPerry wrote: post #80
cjg wrote: post #31

Earlier 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…

>> backend web development >> thread-safety In 2021 what web development stack is making you write threaded code? >> correctness that matters The compilers guarantee end at the edge of your processes address space. You still have the same big problems as everyone else: 1. Are you building the right thing? 2. Does everyone understand the domain adequately to do their job? 3. … 101. Do i have a race condition Except yo…

> 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[]" 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

Post reply on HN