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

81–90 of 195 posts

Re: Zero to Production in Rust

#81

Post by zozbot234 »

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.

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.

Re: Zero to Production in Rust

#82

Post by gpm »

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…

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

Re: Zero to Production in Rust

#83

Post by zozbot234 »

ibraheemdev wrote: post #64
cjg wrote: post #50

Earlier quoted context omitted.

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

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.

Re: Zero to Production in Rust

#84

Post by ibraheemdev »

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.

> Also, I think str vs. String is usually confusing at first, regardless of your background.

Yes, of course. Rust has some new concepts that will be confusing at first, regardless of your background. You still have to understand Rust's destructors to understand that example. I didn't mean to say that it is impossible for Rubyists to learn Rust, or that C++ devs would understand Rust immediately.

Perhaps a better example:

    fn foo() -> &usize {
        let x = 50;
        &x
    }

Re: Zero to Production in Rust

#85

Post by lstamour »

Xevi wrote: post #60
cjg wrote: post #34

Earlier quoted context omitted.

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

I'm not the one you responded to, and I haven't used Rust much myself, but one of the issues I've seen raised several times is that its async ecosystem is fractured. You have to select an async stack, and sometimes different libraries and frameworks use competing stacks, causing problems. It's not like JavaScript or Go where everything is just built into the language afaik.

There’s been a decent amount of standardization on top of Tokio’s implementation of async (green threads). If a library didn’t support it at first, they probably now do using features in your project.toml requirements.[1][2] That said, I agree the standard library isn’t the size or utility of Go’s nor is the ecosystem as wide as Go or npm.

Personally, I’m looking forward to the next few years when more and more companies reveal what patterns they use with Rust development. I think Rust is missing the kind of boost that Rails gave Ruby, for example, or that TypeScript and React gave Node/SSR. Or that Pandas gave Python.

1. https://doc.rust-lang.org/cargo/reference/specifying-depende...

2. https://doc.rust-lang.org/cargo/reference/features.html#depe...

Re: Zero to Production in Rust

#86

Post by Animats »

Ad for a £35 book.

"Zero To Production will focus on the challenges of writing Cloud-native applications in a team of four or five engineers with different levels of experience and proficiency."

It's useful for that. It's not about how to program in Rust. It's about how to set up a production web application in Rust. This is more of a tooling problem.

Re: Zero to Production in Rust

#87

Post by steveklabnik »

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…

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.

Re: Zero to Production in Rust

#88

Post by drclau »

cjg wrote: post #31
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…

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?

Re: Zero to Production in Rust

#89

Post by zozbot234 »

pdpi wrote: post #72
cjg wrote: post #59

Earlier quoted context omitted.

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?

Go doesn’t offer the same sort of guarantees as Rust does, but the goroutine/channel model nudges you towards a safe style

Go is memory safe for purely sequential code. It's not memory safe to share memory-write access among multiple Go threads. Using CSP idioms only, via Go channels, can preserve memory safety, but is prone to more general race conditions.

Re: Zero to Production in Rust

#90

Post by raspo »

I just read through the email newsletter sample chapter, this seems really well done so far!

I really appreciate how the author keeps a pragmatic approach, by copy-pasting code snippets found on the libraries docs and, at the same time, goes into details and explains every little line of code, without overwhelming the reader.

Just a quick (design) feedback: I personally felt like those blue boxes used for pull quotes draw a little too much attention. I wasn’t sure “how” I was supposed to read them at first: is this a “quick tip” box? is this something important I should pay extra attention to?

Post reply on HN