Zero to Production in Rust • Hacker News Board

Re: Zero to Production in Rust

#71

Post by ibraheemdev » Sat, Jun 05, 2021, 5:10 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.

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 approach of the Rust type system.

Re: Zero to Production in Rust

#72

Post by pdpi » Sat, Jun 05, 2021, 5:10 PM UTC

cjg wrote: post #59

beforeolives wrote: post #45

Earlier quoted context omitted.

Any reason to choose Rust over Go in your case?

A couple of reasons: 1. We like the thread-safety properties that Rust offers 2. We don't have any Go experience Does Go offer similar guarantees for concurrency?

Go doesn’t offer the same sort of guarantees as Rust does, but the goroutine/channel model nudges you towards a safe style

Re: Zero to Production in Rust

#73

Post by galangalalgol » Sat, Jun 05, 2021, 5:12 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.

I would have said it was mor like ocaml.

Re: Zero to Production in Rust

#74

Post by Cyph0n » Sat, Jun 05, 2021, 5:15 PM UTC

steveklabnik wrote: post #66

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.

One way of looking at Rust is that it is kinda at the intersection of three different language families: {Ruby,Python,JavaScript} x {C,C++} x {OCaml, Haskell, Scala} “Needs” is a bit strong but “may find some things familiar and therefore easier” is a common refrain.

That makes more sense. I'd probably phrase it as: "if you are familiar with a lower-level language and a functional language, you'll likely have an easier time learning Rust".

Re: Zero to Production in Rust

#75

Post by CraigJPerry » Sat, Jun 05, 2021, 5:16 PM UTC

I don’t want to shit on anyone’s hard work because this does look cool and useful if the language was Python, Java, Go, C#, …

Using a systems language where it’s not required is just burning time and money.

Re: Zero to Production in Rust

#76

Post by ibraheemdev » Sat, Jun 05, 2021, 5:17 PM UTC

zinclozenge wrote: post #42

jkelleyrtp wrote: post #38

Earlier quoted context omitted.

To write custom futures? Yes, you need to understand Pin and some advanced stuff. To use? Eh - I just turn on async_std with the Tokio flag and write go-like code with async tasks. No issues thus far.

What's the deal with cancellations? If you're coming from Go, the context package makes it convenient to do.

Funny you mentioned the context package, as it was pretty hacky way to work around the cancellation problem.

There are some pain points with cancellation in Rust. Dropping a future cancels it, but that requires ownership over the future, and may cause unexpected behavior due to the nature of futures state machines. This, along with many other issues, is being discussed by the async working group: https://github.com/rust-lang/wg-async-foundations/issues/65. If you have specific suggestions, or a problem that you faced, please open an issue! It is really appreciated - async rust's problems cannot be solved without community feedback and engagement.

Re: Zero to Production in Rust

#77

Post by sateesh » Sat, Jun 05, 2021, 5:17 PM UTC

foobarbazetc wrote: post #30

jkelleyrtp wrote: post #13

Earlier quoted context omitted.

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…

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, which has not been the case with Rust. In addition in Go I find the project setup and settings like GOPATH, GOBIN quite confusing. In contrast Rust has _cargo_ which has less cognitive overload.

I think it would be good if one dabbles a bit with both and pick one which one feels resonance with. That being said probably one need to give a bit longer time for Rust to be comfortable with it.

Re: Zero to Production in Rust

#78

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

That makes more sense - it's definitely true that knowing a lower-level language and a functional language gives you a leg up when learning Rust.

As for your example, even C and C++ devs would squint a bit at why that code doesn't compile: you're allocating a string on the heap, so why can't you return a pointer to it? Also, I think str vs. String is usually confusing at first, regardless of your background.

Re: Zero to Production in Rust

#79

Post by adamnemecek » Sat, Jun 05, 2021, 5:19 PM UTC

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…

I agree. Go just lets you get away with writing garbage.

Re: Zero to Production in Rust

#80

Post by CraigJPerry » Sat, Jun 05, 2021, 5:21 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…

>> 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 you have a self-inflicted problem - you’re slower than a dev team working in a traditional language (java, go, python, …) and you can’t easily hire talent.