Zero to Production in Rust • Hacker News Board

Re: Zero to Production in Rust

#181

Post by tayo42 » Sat, Jun 05, 2021, 10:12 PM UTC

tracer4201 wrote: post #166

tayo42 wrote: post #106

Earlier quoted context omitted.

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

I think your kind of discussing the positives of rust, but despite all that still rust is a lot of work to learn. The learning curve of rust might be worth it, I just didn't agree with the statement that rust isn't actually hard to learn.

Re: Zero to Production in Rust

#182

Post by moldavi » Sat, Jun 05, 2021, 10:21 PM UTC

vvanders wrote: post #180

moldavi wrote: post #176

Earlier quoted context omitted.

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

Let's keep this on track; we're only talking about the learning curve here.

Nobody here is saying c/c++ or rust is better after their respective learning curves. No need to be defensive, they're just languages, and every language has its strengths and weaknesses.

To the point: modern c++ is easier to learn nowadays. shared_ptr and unique_ptr are as easy as Rc and Box, but without the borrow checker making things harder. One doesn't have to deal with the decades of difficulties when learning c/c++. One can choose to dive into a terrible legacy c++ project just like they can dive into an unsafe mess like Actix, but thats hardly a reflection on how easy to learn a language, just the codebase you're learning from.

And rust's front-loading of problems is a great thing! It also makes it harder to learn, which is the point here.

Re: Zero to Production in Rust

#183

Post by vvanders » Sat, Jun 05, 2021, 11:37 PM UTC

moldavi wrote: post #182

vvanders wrote: post #180

Earlier quoted context omitted.

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

Let's keep this on track; we're only talking about the learning curve here. Nobody here is saying c/c++ or rust is better after their respective learning curves. No need to be defensive, they're just languages, and every language has its strengths and weaknesses. To the point: modern c++ is easier to learn nowadays. shared_ptr and unique_ptr are as easy as Rc and Box, but without the borrow checker making things hard…

I think we're working from different definitions of learning curves. I include in the learning curve understanding your memory ownership model, not introducing use after free, heap corruption or other failure modes.

I would argue that if you don't understand the ownership of your data you don't really understand C++(or C) and you're still learning the language. That's usually the big shift I see when developers who have a background in higher level languages moving down to C++. I've seen plenty use after free and heap corruption happen in C++0x11 and onward codebases both staying completely within modern best practices and when code diverges since there's no guardrails(ex: std::string::c_str, std::unique_ptr::get and the like).

Once you include all the footguns that exist(yes, even in modern C++) and the legacy parts of existing codebases or code that diverges from modern C++ that's why I think it has a much higher learning curve to be producing code that is at the same quality as a passing compile from Rust in aggregate.

Re: Zero to Production in Rust

#184

Post by dpifke » Sat, Jun 05, 2021, 11:49 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…

I'm a newcomer to Rust, and find it relatively easy to read, at least at the level of "what is this code doing?" (Not necessarily "why did they need to specify lifetime there?")

The major exception to this are cases where authors use macros to invent their own DSL inside Rust code. This sort of thing seems common in the Servo codebase, amomg others. It reminds me of C macros or Python metaprogramming magic, both of which directly led to some incredibly difficult past debugging experiences.

Re: Zero to Production in Rust

#185

Post by moldavi » Sat, Jun 05, 2021, 11:55 PM UTC

vvanders wrote: post #183

moldavi wrote: post #182

Earlier quoted context omitted.

Let's keep this on track; we're only talking about the learning curve here. Nobody here is saying c/c++ or rust is better after their respective learning curves. No need to be defensive, they're just languages, and every language has its strengths and weaknesses. To the point: modern c++ is easier to learn nowadays. shared_ptr and unique_ptr are as easy as Rc and Box, but without the borrow checker making things hard…

I think we're working from different definitions of learning curves. I include in the learning curve understanding your memory ownership model, not introducing use after free, heap corruption or other failure modes. I would argue that if you don't understand the ownership of your data you don't really understand C++(or C) and you're still learning the language. That's usually the big shift I see when developers who h…

That's reasonable; one's threshold of "safe enough" factors in.

If one is just designing a game, or a command line tool for internal use, one needn't make it completely rock solid, and C++ has the better learning curve.

If one includes the requirement to make it safer, Rust has the better learning curve.

And then if someone actually values memory safety, they use a GC'd language and laugh at how many engineer-months and proofs it will take us to make code as safe as theirs. Sigh, such is life...

Re: Zero to Production in Rust

#186

Post by justsomeuser » Sun, Jun 06, 2021, 12:30 AM 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 use Rust because the program I am writing mainly maps types from type A to type B.

A dynamic language has no clue what these types are so you find out what you did wrong by refreshing the app at runtime.

In Rust it tells you instantly, so it reduces the iteration time.

Many web apps fit this “map data from A to B” domain, so having a specification for types A and B and getting the compiler to check all variations seems like it would save a lot of dev time.

Out of the type systems available I like Rusts best as it seems to map well to JSON using its enums feature to represent null or polymorphic types.

But you need to pay the learning curve of Rust, which I am still not sure it is worth it.

Re: Zero to Production in Rust

#187

Post by jkelleyrtp » Sun, Jun 06, 2021, 1:29 AM UTC

rattray wrote: post #171

jkelleyrtp wrote: post #22

Earlier quoted context omitted.

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

Hmmmm RA has been good with me, unless I’m doing something with Arrayfire or PyTorch which are both sensitive to $PATH. RA is seriously the real deal, so I suggest wrenching around until it works. I had to modify my $PATH in VSCode to fix the issue - do you know what library you’re using that causes the issue?

Re: Zero to Production in Rust

#188

Post by antifa » Sun, Jun 06, 2021, 2:30 AM 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 don't think it's any harder to master than some other major languages such as C++ or Java

But this is backend web development, the major languages are more like ruby/php/python/js/java. You might write a C++ extension as an endgame move, but for webdev it's never an opening move.

Re: Zero to Production in Rust

#189

Post by reecko » Sun, Jun 06, 2021, 4:54 AM UTC

vvanders wrote: post #180

moldavi wrote: post #176

Earlier quoted context omitted.

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

> Shared ownership is code smell to me regardless of the language

This is an unsubstantiated claim. If Rust makes something hard, that doesn't automatically make it universally bad. Nearly every large Rust code base I've seen uses reference counting (both `Rc` and `Arc`) a lot. Moreover, it is not practical to write general-purpose code avoiding both GC and RC because the need for shared ownership will inevitably crop up at some point. So ruling it out as code smell is a bit dogmatic.

It is also worth noting that ownership semantics is one approach (among others like GC) to memory management. In future, more languages will have some sort of ownership semantics along with GC. Nim's ORC is currently a good example.

Re: Zero to Production in Rust

#190

Post by vldr » Sun, Jun 06, 2021, 8:02 AM UTC

For me the hard part about Rust is the borrowing, lifetimes stuff and this book doesn't really seem to address these.

For me that means you won't get to Production (at least not starting from Zero) since these are concept that make Rust truely different from other language and without properly grasping those, you will run into hard to understand errors and code that won't compile.

It also seriously affects how you structure your code in general.

There are plenty resources that do properly explain these concepts but in the end you will just need to get it in your system, which is what I'm currently struggling with. The flow of code as I'm used to writing in C, C++, Python or Go simply won't work for Rust