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

151–160 of 195 posts

Re: Zero to Production in Rust

#151

Post by verdagon »

zozbot234 wrote: post #149
verdagon wrote: post #148

Earlier quoted context omitted.

Agreed! While it's not considered "idiomatic" Rust (from all my conversations on the Rust discords), I think that interior mutability is a totally fine thing to reach for in certain cases, at the upper levels of one's architecture. But then, once your code has RefCell everywhere, you're incurring runtime overhead, at which point one might as well switch to a language that makes those tradeoffs easier to wield. This'l…

> But then, once your code has RefCell everywhere, you're incurring runtime overhead The runtime overhead is quite trivial (a single word per object IIRC, which is accessed w/ simple increments/decrements/checks as needed) and work is ongoing on abstractions that don't incur any hidden overhead (called 'GhostCell').

The runtime overhead of RefCell is usually accompanied by some other runtime overhead. To be reachable from multiple places, it usually needs to be stored in some relatively central location.

If it's a rather short-lived object and we don't need to reuse its location, it can be in a Vec, which involves bounds checking and O(logN) calls to malloc, which is not amortized. Sometimes we can put short-lived objects in an arena, which is the best option, but they are very memory hungry, which has its own costs.

If it's longer lived, we can use a Vec with indices or a type-pool, but we risk use-after-"release", which can be a privacy risk and defeats some of the nice "sanity" properties of Rust code (this is still a good option in some cases, IMO).

If it's longer lived, and we don't want those drawbacks, we have to fall back on something like Rc or generational indices, which both have their runtime costs.

IME, only a very specific kind of use case can avoid any of this runtime overhead. When you get to the more complex use cases, especially with lots of unavoidable state, these overheads appear more and more, and make the whole situation a little less clear-cut.

(This was a rather hand-wavy explanation, I can make it more accurate if you'd like)

Re: Zero to Production in Rust

#152

Post by richardwhiuk »

brundolf wrote: post #37
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…

What web framework do you use? This to me seems like the part that's least-baked at this stage. Iron doesn't support async if I recall correctly, actix supposedly has a complicated mental model and was mired in drama last I checked, and Rocket looks promising but is still in the somewhat-early stages.

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

Re: Zero to Production in Rust

#153

Post by alpaca128 »

rattray wrote: 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…

> TypeScript is probably a more appropriate choice for most situations – still a rich, powerful type system, great performance, and much faster compilation times

Compared to Rust's normal debug builds Typescript does not have any noteworthy compilation speed advantage in my experience. In fact I find incremental Rust builds very similar if not faster in some cases (of course there are extreme exceptions both ways; I've used a library that added 40 seconds to every Rust build, but also frameworks that didn't make a noticeable difference after the first build). Meanwhile the quality of TypeScript error messages is much worse. Also sometimes debugging gets confusing because TypeScript has a couple blind spots and in the end it still turns into JS with all its quirks. I find Rust's type checker significantly more precise and comprehensive. On the other hand TypeScript doesn't (need to) care about things like pointer ownership, so often there's much less to worry about.

Re: Zero to Production in Rust

#154

Post by steveklabnik »

vips7L wrote: post #141
steveklabnik wrote: post #87

Earlier quoted context omitted.

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.

Isn't that just self inflicted though? You probably wouldn't have had to write C/threaded code if you chose a faster runtime like C#/Java/Go/Kotlin/Scala instead of ruby.

At the time, Go/Kotlin didn't exist, Scala wasn't established, C# was Windows only, and Java and the JVM more generally were a thing that everyone was running to Ruby and Rails from for lots of reasons. Probably wouldn't have gotten the thing out the door if I had to do it in Java.

Re: Zero to Production in Rust

#155

Post by vvanders »

kortex wrote: post #150
tialaramex wrote: post #110

Earlier quoted context omitted.

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

> 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 "h…

Having written C++ in one way or another over the last 2 decades I still get burned by that surface area.

Last week it was a combination of forgetting the exact specifics of RVO hitting the implicit copy constructor that was causing things to go sideways. The number of implicit behaviors are pretty wide and things like move semantics still feel pretty brittle.

Re: Zero to Production in Rust

#156

Post by cjg »

drclau wrote: post #88
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…

Can you share details on what material you used for the internal training?

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.

Re: Zero to Production in Rust

#158

Post by phkahler »

kabdib wrote: post #124
tialaramex wrote: post #110

Earlier quoted context omitted.

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

That's what Rust is.

No, not literally.

Re: Zero to Production in Rust

#159

Post by vvanders »

verdagon wrote: post #144
tialaramex wrote: post #110

Earlier quoted context omitted.

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

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

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

Having seen teams go Java -> C++ and other teams go C -> C++ I don't really think that's the case. The former leans on shared_ptr everywhere, the latter ends up hitting footguns with implicit behavior around move semantics, RAII(seen more than a few use after free here) and the like.

ASAN and other tools help, but assume they are run regularly and kept to a level of rigor I haven't always seen in codebases.

Re: Zero to Production in Rust

#160

Post by genuine_smiles »

alpaca128 wrote: post #153
rattray wrote: 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…

> TypeScript is probably a more appropriate choice for most situations – still a rich, powerful type system, great performance, and much faster compilation times Compared to Rust's normal debug builds Typescript does not have any noteworthy compilation speed advantage in my experience. In fact I find incremental Rust builds very similar if not faster in some cases (of course there are extreme exceptions both ways; I'…

We can cheat Typescript builds by using a different tool to strip the types, and generate type errors on a different thread. The type errors can be terribly slow, and the build times quite fast.
Post reply on HN