Zero to Production in Rust • Hacker News Board

Re: Zero to Production in Rust

#161

Post by phkahler » Sat, Jun 05, 2021, 8:46 PM UTC

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.

>> 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 anything similar (think enterprise software).

Git - awesome. Using it on 1-man projects too.

Sanitizers for C++ I've seen these identify bugs that hadn't manifested visibly yet.

Rust - well I want to write more because it doesnt require additional tooling to write correct code. Remember reducing complexity.

Re: Zero to Production in Rust

#162

Post by PragmaticPulp » Sat, Jun 05, 2021, 8:52 PM UTC

GiorgioG wrote: post #103

I bought this book a couple of months ago - I think it’s well put together and practical as someone familiar with backend development (.NET) looking to learn how to do it in Rust. Yes there’s free resources to learn anything, but most online tutorials are not in-depth. It’s up to you if prefer to piece together your knowledge from various sources or if you want to take a deep dive. There is no single right way to do…

For what it's worth, I've been pleasantly surprised at the amount of free and open-source material supporting Rust development. There are several books covering Rust web apps (including this one) but frankly I never felt limited by the freely available materials.

Re: Zero to Production in Rust

#163

Post by throwawaySlu » Sat, Jun 05, 2021, 8:52 PM UTC

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…

I’m at a company where we have tons of Java services. Services scale out horizontally, are fronted with load balancers, and there’s some minimal JVM tuning. Some services have thread pools dedicated to making calls to other services. Aside from that, there isn’t that much multi threaded code that we’ve had to write. Throttling is in use as well.

I see a big Rust benefit when you’re writing systems level code or you’re writing once and use the code as a library on Android and iOS.

But what type of logic are you writing in your services that requires Rust’s safety guarantees? Or is it that you’ve found you can respond to the same performance metrics (total requests per second) with fewer hosts because there’s no JVM or garbage collection overhead?

Re: Zero to Production in Rust

#164

Post by moldavi » Sat, Jun 05, 2021, 9:00 PM UTC

vvanders wrote: post #159

verdagon wrote: post #144

Earlier quoted context omitted.

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

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)

Re: Zero to Production in Rust

#165

Post by onelastjob » Sat, Jun 05, 2021, 9:01 PM UTC

I'm currently looking for Rust devs that are interested in joining a side project that uses Rust for the back-end of a web app. The project involves working with Solana (a smart contract cryptocurrency coded in Rust). If interested, email me at rusted[at]fastmail[dot]com

Re: Zero to Production in Rust

#166

Post by tracer4201 » Sat, Jun 05, 2021, 9:02 PM UTC

tayo42 wrote: post #106

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…

Rust is really hard to learn though. the compiler errors are hard to read and understand, it's an extremely syntax heavy language. I used to work with someone who regularly contributed to rust, I had some errors on a project that confused him too. The only other times I needed to a book to learn a language was Scala and haskell, both hard to learn languages.

Picking up Rust is not the same as picking up Python or even Java, in my opinion.

I started learning Rust and C++ at the same time, coming from a world of Java, Python, and Ruby.

If I need to solve a problem in C++, I would much rather write Rust because the compiler actively screams at you when you do bad things.

And in my opinion, the challenging part is learning what those bad things are. In other languages, the compiler doesn’t care. You immediately see your program crash or things fail in subtle, hard to reproduce ways later in production. Rust changes that model.

I disagree with you on the documentation. I think the Rust documentation is superb. I have yet to see any language give nearly as meaningful information when your code fails to compile. Secondly, Rust front loads and throws issues immediately in your face, as opposed to having you discover problems in your code at runtime. I don’t think that makes Rust difficult - it’s forcing you to think about your choices. And particularly it’s making you think about concepts that perhaps you completely overlooked in other languages - thinking about stack vs heap allocation, moving semantics, shared ownership, etc.

If you want to quickly prototype something, Rust isn’t the best language IMO. But if I have a choice between C++ and Rust, I’d go with Rust anyday. If I was starting a new project from scratch and it was more of a web service, I might go with another language over Rust only because I’m more of an expert in Java, Python, etc. and it’s easier to hire developers for those languages than Rust.

But I’m biased. Rust has a special place in my heart. It’s the first language I’ve learned in many years where I felt some sense of accomplishment and did not at all feel like “Oh great, another tool that fundamentally doesn’t add value.”

For my use cases involving Java and iOS interoperability in a multi threaded environment, nothing else came even close.

Re: Zero to Production in Rust

#167

Post by kortex » Sat, Jun 05, 2021, 9:05 PM UTC

vvanders wrote: post #155

kortex wrote: post #150

Earlier quoted context omitted.

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

Yeah this is exactly the kind of thing I mean. I worked at the company that makes CMake and I'd go to coworkers with questions like that...I forget exactly what I asked but it was something involving RVO and copy elision of a lambda/ anonymous function, and they had to ask around until we found a greybeard who knew the correct application of && and some other stuff. This wasn't even some heavy deep stuff, it was like a pubsub callback in ROS.

I had some really mission critical camera driver stuff I was working on and just never felt secure that there was a massive bug lurking, despite code review, Valgrind and testing. But on that same project, I had enough confidence to write a small daemon in Rust, with like...maybe 60h total experience in the language. Huge peace of mind knowing the code does what I expect it to do.

Re: Zero to Production in Rust

#168

Post by throwamon » Sat, Jun 05, 2021, 9:07 PM UTC

steveklabnik wrote: post #135

throwamon wrote: post #109

Earlier quoted context omitted.

Everyone and their mother is receiving an ADHD diagnosis nowadays. Call me a conspiracist, but I believe this is just one more case of deliberate overfitting by Big Pharma, coupled with the consequences of technology on our attention spans and other characteristics of our cognition and behavior. As someone that might be similarly diagnosed for the same reasons, your comment does make me more optimistic of achieving s…

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.

Re: Zero to Production in Rust

#169

Post by pqb » Sat, Jun 05, 2021, 9:08 PM UTC

jkelleyrtp wrote: post #13

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…

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…

Your reply has piqued my attention, because as a person who develops in Go (and in other programming languages) I cannot put any > or I won't try to play as a Go devil advocate, because I don't feel good enough today to start such discussion.

What is the worst thing I have experienced in Rust? Lack of good packages, especially if we speak about cloud stuff (rusoto and google-api-rs). Human resources put from cloud providers are very scarce. As longer I dived into the Rust the more I felt I am alone freak, because I had to work more hours to achieve the same result as in Go, PHP, Kotlin, TypeScript, C#. My use case of Rust was a GraphQL gateway (gRPC+HTTP) and after few weeks of idea verification the project was dropped. Mostly because instead of developing business logic the team was focused to implement own libraries for Google Cloud and other SaaS offerings on their own. Ridiculous, but Mozilla devs [0] went the same way by taking the whole job on their shoulders and they were generating subsets of APIs, because they cannot find any good, official libraries. It is frustrating and time consuming making Rust completely no-go for many teams.

> I've worked a decent amount with Go, but I'm also frustrated with the size of projects balloon. When I compare my Rust and Go code, the Rust code ends up being much smaller (LoC) and much more dense/terse.

I can exactly the same about the Rust. I think it was not the problem with tool but with something between chair and keyboard. I had a pleasure to see and refactor very bad Go code and actual ballooning was never a case if you have applied Clean / Solid architecture. The "ballooning" was actual something nice, because anyone in the team could pick the repository and take care of implementing new business logic.

The number of lines of code is quite bad metric for Golang, because famous "if err != nil" takes a nasty 3 lines, while in many languages you can write it using single liner. In my humble experience, the number of lines of most Go web apps can be often compared to TypeScript apps. Also many web apps that I have developed usually had hefty 2-5k LoC and it is not bad result if we consider C# or Java web apps.

> - Powerful hygienic and non-hygienic macros

Yeah, having marcros in Rust is a gem.

> - Builtin benchmarking

Same as in Go. See testing.B.

It is weird you have pointed out

> - Builtin documentation

Same as in Go. See godoc.

> - FFI with Swift, C, C++, Node, etc to share code everywhere.

I rarely see the case for FFI in web app - I don't imagine even using it like that. It was common case for chart, TeX document or other web to image rendering to embed some library. I think it is a bad approach and the best currently is just run that code as separate binary, because it helps in maintainability of a third party dependency and your devops teams will love that decision.

As a person who rewrote the rxi/lite [1] to Rust I can only say I am terrified how many times I had to sacrifice having unsafe calls to just use some C code in my Rust application.

> - Crates.io is like NPM - really discoverable and easy to upload (with its goods and bads)

Personally, I feel Go/Deno/Docker flow of the installing dependencies is more convenient. I don't project names that do not sound what they provide. Naming thing is bad and I often see many developers are scratching head to find some unique name, so it could be easier findable in NPM or other repository. They are wasting time at looking for something short and funny and not something that is easily discoverable.

For many years, my only way of looking for dependency is GitHub. It helps to verify and investigate the quality of the code before adopting it in the application. It sometimes also results in contributing back to the project, because I already know where the project is located.

> - Really good project management through modules/Cargo.toml

It is really complex I'd say. But Cargo.rs would be nice to have :P

> - Generics make Map/Reduce/Filter really easy and readable

Matter of time in Go. :)

> - Serde is fantastic at automatically serializing/deserializing datastructures

Oh, that's true. Go has numerous serializers (for only JSON there are about 20+ nice looking implementations) and it is still interesting to see new ones, especially because they bring many non-obvious optimizations. Kotlin serializer is also top notch thingy. I recommend to use protobufs types in Go - even for domain models. It is interesting how with Go2 can improve the situation.

> - Very pleasant logging and tracing

The log package is nice, together with macro log! is really pleasant to look at it how concise it is to fill some context parameters around the message. I think it is like Logrus in Go, except the syntax it has the same features. There is also Zap package that sacrifices readability for performance. There is no problem to embed number of line of code, calling function in Go logs either.

Tracing? Yep, it feels the same for both languages I think. I had used OpenTracing (Jaeger) and I hardly can say I miss something from one or other language. Maybe some macro/annotation wrapper that will be added on compile time? However, I rarely see any use case right now for complicating such thing like tracing.

> - Like, really really good error handling, esp compared to Go

Hey, it is not that bad! :D But well, as long as you use Goland you don't care about the if-err-non-nil.

If you switch for few days to Java-world you will be like in hell after developing in Go, because the error-over-exception flow is really helpful to provide code that does not have any kind of error and you, as a developer, can guess what happens in specific line without any println("1") or debugger. Monads are nice but I will not trade current if-err for them.

> - builtin testing framework

AFAIK all modern programming languages includes some testing framework: Kotlin (kotlin.test), Zig (std.test), Elixir (ExUnit) etc. I am glad both Rust and Go joined that club.

> If you're looking into using Rust for web, I recommend https://github.com/http-rs/tide - it's the most pleasant web framework I've ever used.

It is interesting, but I think even today there is nothing that I could label as a "framework" in Go world. You wisely choose the best packages matching your needs. The situation has improved with many libraries providing a GraphQL endpoint.

> I've worked a decent amount with Go

Reading your post, made me think you don't have good Go experience and it sounded bad IMHO. I guess you had nobody proficient enough in production-ready Go apps to evangelize it within the team or there was no reason to use Go (yep, it is not a perfect tool). ;)

[0]: https://github.com/mozilla-services/syncstorage-rs

[1]: https://github.com/rxi/lite

Re: Zero to Production in Rust

#170

Post by vvanders » Sat, Jun 05, 2021, 9:09 PM UTC

moldavi wrote: post #164

vvanders wrote: post #159

Earlier quoted context omitted.

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

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 contrast calls out many of those things upfront, I've found those guardrails prompt conversations in tradeoffs and conscious choices(to say use Rc/RefCell) you'd be making anyway in C++.