Zero to Production in Rust • Hacker News Board

Re: Zero to Production in Rust

#141

Post by vips7L » Sat, Jun 05, 2021, 7:17 PM UTC

steveklabnik wrote: post #87

CraigJPerry wrote: post #80

Earlier quoted context omitted.

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

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.

Re: Zero to Production in Rust

#142

Post by ctvo » Sat, Jun 05, 2021, 7:19 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…

What a perfect example of developers pushing for technologies they want to learn. A web application stack in the flavor of the month systems language for correctness!

My eyes can’t possibly rollback far enough.

Re: Zero to Production in Rust

#143

Post by phibz » Sat, Jun 05, 2021, 7:21 PM UTC

nicoburns wrote: post #133

novok wrote: post #70

Earlier quoted context omitted.

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

I find it easier to either use conditional compilation or traits for test substitutes. Using dynamic dispatch for it is more trouble than it's worth IMO.

Re: Zero to Production in Rust

#144

Post by verdagon » Sat, Jun 05, 2021, 7:21 PM UTC

tialaramex wrote: post #110

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…

> 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-object basis is something I wouldn't take to my C++ code. It may be the core of Rust, and it's a neat tradeoff that enables some of its other benefits, but the indirect complexity cost is too high, IME.

> Oh there is just no way it's harder to learn than C++.

I think the jury's still out on this one.

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.

Rust has just as much complexity, and forces it all on you at once. Because of that, it is harder to learn.

Some people say Rust's rules are intuitive. I have to disagree. These years of working with Rust and teaching Rust to others have made it clear to me: though the basic concepts are simple, the architectural implications and workarounds are not.

I'm not saying C++ or Rust is better. But C++ is slightly easier to learn, IMO.

I commonly hear "But it's hard to learn how to use C++ safely!" and I generally agree with that. ASan has made things much easier in that regard, but C++ will probably never catch up enough for some use cases.

Re: Zero to Production in Rust

#145

Post by phibz » Sat, Jun 05, 2021, 7:24 PM UTC

Cyph0n wrote: post #47

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…

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.

From my experience I found the ideas of move semantics from modern C++ directly relatable to ownership and move vs borrow. I also found the FP ideas from Scala, pattern matching, combinators, result and option monads directly useful in rust.

Re: Zero to Production in Rust

#146

Post by zozbot234 » Sat, Jun 05, 2021, 7:26 PM UTC

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…

> I'd offer one exception though: mutability xor aliasability on a per-object basis is something I wouldn't take to my C++ code.

Rust has "interior" mutability for when you need mutable access to shared data. It works very similar to the "mutable" keyword in C++ except that it's always type-driven, as opposed to something being specified as part of a declaration.

Re: Zero to Production in Rust

#147

Post by davidkunz » Sat, Jun 05, 2021, 7:30 PM UTC

cjg wrote: post #33

rob74 wrote: post #25

Earlier quoted context omitted.

> When I compare my Rust and Go code, the Rust code ends up being much smaller (LoC) and much more dense/terse. Yes, but is it more readable too? The obfuscated C contest also tends to produce a lot of dense/terse code, but you probably wouldn't want to use that in a production system...

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…

It depends on what you're trying to read. If you want to understand every technical detail (e.g. who owns this variable) then Rust is great. If you want to understand the business logic behind it (e.g. under what circumstances is a customer allowed to return that product) then Rust is not so great as you would have to mentally filter out all the technical noise.

Re: Zero to Production in Rust

#148

Post by verdagon » Sat, Jun 05, 2021, 7:31 PM UTC

zozbot234 wrote: post #146

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…

> I'd offer one exception though: mutability xor aliasability on a per-object basis is something I wouldn't take to my C++ code. Rust has "interior" mutability for when you need mutable access to shared data. It works very similar to the "mutable" keyword in C++ except that it's always type-driven, as opposed to something being specified as part of a declaration.

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'll get even better in the near future; a lot of languages are improving in this regard (Cone, Lobster, etc).

Re: Zero to Production in Rust

#149

Post by zozbot234 » Sat, Jun 05, 2021, 7:39 PM UTC

verdagon wrote: post #148

zozbot234 wrote: post #146

Earlier quoted context omitted.

> I'd offer one exception though: mutability xor aliasability on a per-object basis is something I wouldn't take to my C++ code. Rust has "interior" mutability for when you need mutable access to shared data. It works very similar to the "mutable" keyword in C++ except that it's always type-driven, as opposed to something being specified as part of a declaration.

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

Re: Zero to Production in Rust

#150

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

tialaramex wrote: post #110

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…

> 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 "hardness" is ownership and move/borrow mechanics. Modern C++ has std::move, ownership, and lifetime considerations.

Add to that smart pointers, initialization, a bloatastic std lib, an even more bloatastic pseudo-std lib that you need if you have to interop with anything older than 14 (boost), umpteen different build systems, compilers, toolchains, and all that on top of almost-not-quite-C-superset, and you have a massive surface area.

On another HN thread, someone commented that developers took 3x longer to get to speed in a Rust codebase than C++. I say no way, Jose. I was committing PRs in Rust within a few months. I still don't feel comfortable in C++ of any serious complexity. That's with 2 years of C experience, 1 yr of intensive C++, and like, a few months of rust.