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

171–180 of 195 posts

Re: Zero to Production in Rust

#171

Post by rattray »

jkelleyrtp wrote: post #22
rattray wrote: post #12

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…

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.

My mistake! Replacing RLS with Rust-Analyzer, it now takes 20-30s to incrementally check a trivial change to some core model code (compared to ~90s with RLS), though now rust-analyzer gives me an unrelated error which I assume may be the result of using a different rustup/cargo binary or something – so I'm back to RLS. Oh well. It looks like RLS and Rust-Analyzer are working on unifying their code, so I'm sure this will get better in the not-too-distant future.

Re: Zero to Production in Rust

#173

Post by pqb »

kaoD wrote: post #58
foobarbazetc wrote: post #30

Earlier quoted context omitted.

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…

> but there’s no denying that Go is much easier to program than Rust. 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 guarante…

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

> I tried really hard to like Go. I just couldn't.

I would expect something opposite for most of programmers. Especially, because Rust support in VSCode/JetBrains IDEs was not very good for many years. However, during talks with various people, I have noticed the Go was natural choice for many former Python or Ruby devs, while Node/Java guys had problem with adapting to it.

Personally, when I take a look at the Rust code it feels like some ECMA Script in a compiled world.

Re: Zero to Production in Rust

#174

Post by Xevi »

johnwheeler wrote: post #101
wokwokwok wrote: post #4

Is it cool now to just link to landing pages where you sell things now? Am I missing something? Why the hell are people upvoting a “buy now with discount code” page?

What discount code?

I think it depends on your country. I got a 20% discount, which appears to offset the VAT I have to pay.

> You'll be charged US$62.01, including US$12.40 for VAT in .

Re: Zero to Production in Rust

#175

Post by _Kobo_2207_ »

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…

Both matureness of the ecosystem and developers are a big issue. For typical enterprise apps you just don't need the characteristics of Rust and therefore it doesn't make any sense to pay the penalty for using it. If your focus are business logic related needs (as opposed to best in class performance, no GC, etc.) using Rust is a grave mistake. Just use boring Java or better Go (better tooling, standard lib and scaling) and focus on delivering value to the customer.

Re: Zero to Production in Rust

#176

Post by moldavi »

vvanders wrote: post #170
moldavi wrote: post #164

Earlier quoted context omitted.

To be fair, people coming from other languages lean heavily on Rc/RefCell too, and sometimes (uh oh) unsafe blocks. In both cases, one benefits from input from those experienced in the language. (not saying c/c++ is better than rust, just commenting on the difficulty)

Yeah, but rightly so those are "escape hatches" because you can leak memory with Rc/shared_ptr. With C++ unless you have someone experienced on a team there's a host of "unknown unknowns" that feel like the team is making progress but then having to pay the cost when it blows up and usually when schedule pressure is near the highest point. Same for the build systems, retrofitting LTO is not a fun experience. Rust in…

So it's okay if rust does shared ownership, but not okay for c++?

I'm not attacking rust, btw. We all know c/c++ isn't great. Theres plenty of aspects where rust is better, and plenty where c++ is better.

But we're just talking about difficulty, and in this context it's fair to say rust isn't necessarily better than c/c++.

Re: Zero to Production in Rust

#177

Post by kortex »

phkahler wrote: post #161
deeviant wrote: post #68

Earlier quoted context omitted.

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

>> My experience in my 15 years in software, is that good developers solve problems, not languages or tools. At 15 years I thought the same. At 25 years I have come to really appreciate some tools ability to help. There are a lot of tools that claim to help but don't. Beware of tools that try to manage complexity - what you probably need is to reduce complexity. I'm looking at Eclipse and Matlab in particular, and an…

>>> good developers solve problems, not languages or tools

>> At 25 years I have come to really appreciate some tools ability to help.

I've come to find there is a bidirectional connection between good developers and their tools. Good devs recognize and gravitate towards systems that help them thrive, and away from painful ones. Good tools draw in good devs, and the community gets stronger as a result.

IMHO, One hallmark of less-than-stellar devs is a tendency to stick with tools they are familiar with, because "it works." Great devs could get by with a magnetized needle and a steady hand, but they know there is better out there.

Re: Zero to Production in Rust

#178

Post by pqb »

sateesh wrote: post #77
foobarbazetc wrote: post #30

Earlier quoted context omitted.

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…

I dabbled a bit with Go and now I am trying Rust. I did find programming in Rust a tad difficult than with Go, but as I get used to concepts (borrow checking, Move vs/ copy, lifetimes etc.) I am liking it better than Go. With Go I feel there is an element of deceptive simplicity, which catches up with you as the problem space gets complex. I never became comfortable with doing object oriented programming with Go, whi…

> I never became comfortable with doing object oriented programming with Go, which has not been the case with Rust.

Ouch, OOP in Go is just asking for a trouble. "Inheritance" by embedding anonymous struct/interface should be rarely used. Playing with a magic dependency injection, reflection mocking often do not leads to anything good too.

> In addition in Go I find the project setup and settings like GOPATH, GOBIN quite confusing.

I guess you work on Linux :) Yeah, it is weird, I am glad they have improved that flow by guessing empty GOPATH will be equal to $USER/go/ directory. GOBIN is actually not needed, only if you have used dep dependency manager, which for many years is deprecated.

Re: Zero to Production in Rust

#179

Post by steveklabnik »

throwamon wrote: post #168
steveklabnik wrote: post #135

Earlier quoted context omitted.

Believe whatever you want, I am just glad that some things are starting to get better for me. I didn't need big pharma to tell me that stuff was bad, I struggled to even get help for far too long, and stigma around over-diagnosis certainly prolonged my problems here.

I'm sorry if I sounded like I was trying to invalidate your diagnosis. I'm sure ADHD is a real issue many people face their entire lives without receiving proper information or care and of course it's better to find out as early as possible. I realize now your comment wasn't the proper place for me to rant about this. I'm happy for you.

It's all good. It's a really, really tricky topic, for sure.

Re: Zero to Production in Rust

#180

Post by vvanders »

moldavi wrote: post #176
vvanders wrote: post #170

Earlier quoted context omitted.

Yeah, but rightly so those are "escape hatches" because you can leak memory with Rc/shared_ptr. With C++ unless you have someone experienced on a team there's a host of "unknown unknowns" that feel like the team is making progress but then having to pay the cost when it blows up and usually when schedule pressure is near the highest point. Same for the build systems, retrofitting LTO is not a fun experience. Rust in…

So it's okay if rust does shared ownership, but not okay for c++? I'm not attacking rust, btw. We all know c/c++ isn't great. Theres plenty of aspects where rust is better, and plenty where c++ is better. But we're just talking about difficulty, and in this context it's fair to say rust isn't necessarily better than c/c++.

Shared ownership is code smell to me regardless of the language, I think Rust just makes it a bit more high friction.

Language difficulty I'm having trouble seeing how C++ isn't harder there. You have decades of features, lots of gotchas that I could rattle off and a bunch of implicit behavior that you only learn about when it blows up at runtime(if your lucky). Heck, I've seen heap corruptions stay latent in codebases for 6+ months only to have a new field added that causes them to cascade into a failure that took 3 weeks to debug across 2 different teams. I've still seen modern compilers not catch basic use after free scenarios in code today.

I won't disagree that you can get code to compile quicker in C++ but if your goal is feature velocity you're better served by a high level language. If your goal is stability, performance and memory which is the domain of systems programming then I think C++ has a bunch of hidden failure modes that Rust frontloads in an elegant way.

There are projects where you'd pick C++ for portability on platforms LLVM doesn't support or momentum with existing codebases but if I had to pick between the two my personal bias is towards Rust for all the reasons above.

Post reply on HN