Zero to Production in Rust • Hacker News Board

Re: Zero to Production in Rust

#131

Post by monoideism » Sat, Jun 05, 2021, 7:00 PM UTC

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.

Among package manager + build tool devs I know, cargo is considered by most I know (maybe 2-3) to be best-of-class.

In terms of influences, here's an OCaml attempt to replicate cargo (I wish them well): https://github.com/OCamlPro/drom

Klabnik also mentioned Python's poetry below. Yarn as well, since Yehuda Katz was involved.

Note: I seem to recall you're an Ada dev, so I should mention that as far as build tools go, I've always really appreciated gprbuild, which is far superior to other build tools of its vintage. If it had a built-in package manager like cargo, it could compete with cargo.

Re: Zero to Production in Rust

#132

Post by EugeneOZ » Sat, Jun 05, 2021, 7:01 PM UTC

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’ve been using Rust for 5 years for REST API and the most important thing is the safety of refactoring. Not memory safety, not speed, but errors handling and safety of refactoring are key features for web backend. Also, things like Cargo and ootb testing framework - are quite valuable.

Re: Zero to Production in Rust

#133

Post by nicoburns » Sat, Jun 05, 2021, 7:02 PM UTC

novok wrote: post #70

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…

TBH I'm kind of frustrated with Swift's lack of dynamic dispatch options, so things like network models, network service interfaces and testing mocks need to be code generated, while in JVM and Objective-C land, you don't need to do the same. Swift's Codable is doing code gen under the hood, so it also has a binary size and compile time cost. Swift also doesn't scale that well with core size like many other languages…

Rust has similar issues with dynamic dispatch (but you're probably better off avoiding mocking anyway). I believe there are libraries to use conditional compilation to switch in mocks for test builds if you really want them.

Compile times are definitely a pain point in Rust, but from what I've heard the Rust compiler is pretty good at scaling to multiple cores (my machine only has 2, so personally that doesn't help much).

Re: Zero to Production in Rust

#134

Post by nicoburns » Sat, Jun 05, 2021, 7:04 PM UTC

ibraheemdev wrote: post #71

Cyph0n wrote: post #47

Earlier quoted context omitted.

Can you expand on “needs a C++ or Scala or Haskell background”? C++ would probably help you appreciate what Rust brings to the table, but I don’t see how any of them fit in when learning to use Rust in practice.

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…

There's definitely content to be learnt. But I'm not sure I'd say it's very hard. I came from JavaScript, and I found that the Rust Book was very good at explaining these kind of issues, so even though they were new to me they didn't cause too many problems.

Re: Zero to Production in Rust

#135

Post by steveklabnik » Sat, Jun 05, 2021, 7:07 PM UTC

throwamon wrote: post #109

steveklabnik wrote: post #27

Earlier quoted context omitted.

Ironically, I recently received an ADHD diagnosis…

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.

Re: Zero to Production in Rust

#136

Post by monoideism » Sat, Jun 05, 2021, 7:08 PM UTC

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.

Yarn came after cargo was started, I'm fairly sure.

Re: Zero to Production in Rust

#137

Post by pjmlp » Sat, Jun 05, 2021, 7:10 PM UTC

monoideism wrote: post #131

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.

Among package manager + build tool devs I know, cargo is considered by most I know (maybe 2-3) to be best-of-class. In terms of influences, here's an OCaml attempt to replicate cargo (I wish them well): https://github.com/OCamlPro/drom Klabnik also mentioned Python's poetry below. Yarn as well, since Yehuda Katz was involved. Note: I seem to recall you're an Ada dev, so I should mention that as far as build tools go,…

So good that Google is not using it on Android, nor Fuchsia.

I like Ada, but no not an Ada dev, rather JVM/.NET/C++, I rather go polyglot.

And in this regard, while cargo is nice, I don't see how it is better than Maven (I don't suffer XML allergy), NuGET, vcpkg/conan, specially because it only does source packages with npm like levels of dependencies.

Re: Zero to Production in Rust

#138

Post by monoideism » Sat, Jun 05, 2021, 7:14 PM UTC

pjmlp wrote: post #137

monoideism wrote: post #131

Earlier quoted context omitted.

Among package manager + build tool devs I know, cargo is considered by most I know (maybe 2-3) to be best-of-class. In terms of influences, here's an OCaml attempt to replicate cargo (I wish them well): https://github.com/OCamlPro/drom Klabnik also mentioned Python's poetry below. Yarn as well, since Yehuda Katz was involved. Note: I seem to recall you're an Ada dev, so I should mention that as far as build tools go,…

So good that Google is not using it on Android, nor Fuchsia. I like Ada, but no not an Ada dev, rather JVM/.NET/C++, I rather go polyglot. And in this regard, while cargo is nice, I don't see how it is better than Maven (I don't suffer XML allergy), NuGET, vcpkg/conan, specially because it only does source packages with npm like levels of dependencies.

Yeah, I almost changed that "Ada dev" since as a polyglot dev, I figured you'd correct me. What I meant was that you had significant Ada experience (or I'm confusing you w/someone else).

Anyway, yeah, Maven is very good and competes with cargo, as well. I agree.

Nuget? Absolutely not, based on my previously undefined rubric. Unlike Maven and cargo, it's just a package manager unless it's recently been expanded (I'm not much of a Windows guy, so not sure). With some pretty crappy defaults as of a year or two ago. No idea about vcpkg or conan.

(I probably should have specified that I'm comparing among package manager that include build tools - or vice versa).

Edit: I suspect cargo will get around to binary packages at some point, as soon as that limitation is resolved in rustc using something like TUF. cargo has not been around nearly as long as Maven.

Re: Zero to Production in Rust

#139

Post by timeon » Sat, Jun 05, 2021, 7:15 PM UTC

Thaxll wrote: post #113

cjg wrote: post #33

Earlier quoted context omitted.

In my experience, Rust code is relatively easy to read, even by developers with no Rust experience. Of course, you can write hard to read code. But that's not typically what comes out of a process of writing production software. That's not to say that someone with no experience will fully understand the ownership transfer & borrowing that's happening, but that's just stuff you need to do for the compiler. Reading cod…

Rust is one the hardest language to read. Take two people that never used Go or Rust and make them read code, good luck with Rust.

So I have opened golang.org:

v1, ok1 := Not sure what is difference between := and = and what is that arrow. But if I'm going to do something with the language - I guess it will be easy to find out. Like with Rust.

Re: Zero to Production in Rust

#140

Post by rattray » Sat, Jun 05, 2021, 7:16 PM UTC

sriram_malhar wrote: post #21

rattray wrote: post #11

Earlier quoted context omitted.

Why? Golang has a much less advanced type system, comparable runtime performance, a smaller developer community, and a smaller package ecosystem. Plus, if you're building a backend for a webapp, TS allows your engineers to build full-stack features in the same language, avoiding context-switching, code duplication, and other overhead.

I accept all your points, but comparable runtime performance? That's the only reason that people away from node/ruby/python towards gaoling.

Turns out I hadn't heard of go's fiber framework, which performs impressively on Techempower's composite benchmarks (just behind the top ten dominated by C++, Rust, and .NET Core, and barely ahead of Java).

Other than Fiber, the techempower composite framework benchmark[0] ranks gin (go), nodejs, clevergo, and fastify (node) one after the other, all scoring right around 1600.

To be fair, Express is half that good at ~800, but upgrading from express to fastify should be fairly straightforward for those seeking better performance; the much newer fastify has a similar (often compatible) API.

For comparison, Python's fastapi is only 1200, and Django/Rails a mere 250, so lumping Node in with Python and Ruby doesn't make much sense; it'll often perform an order of magnitude better.

For computation-heavy workloads, multiprocessing with Node remains a challenge; Go's a more clear winner there.

[0] https://www.techempower.com/benchmarks/#section=data-r20&hw=...