5 ms·

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

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 friendly. Swift is a nice mix of all worlds, IMHO. Would be nice to see that get more server-side use. At our Scala-centric company, Go gets used a lot more for one off tasks and microservices. We rebuilt one Go service in Rust just to get familiar with it and no one has written more Rust since.

Cyph0n 5y ago
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.
- steveklabnik 5y ago
  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.
  - Cyph0n 5y ago
    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".
    - steveklabnik 5y ago
      Yup, I’d agree with that.
- ibraheemdev 5y ago
  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.
  - Cyph0n 5y ago
    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.
    - ibraheemdev 5y ago
      > Also, I think str vs. String is usually confusing at first, regardless of your background. Yes, of course. Rust has some new concepts that will be confusing at first, regardless of your background. You still have to understand Rust's destructors to understand that example. I didn't mean to say that it is impossible for Rubyists to learn Rust, or that C++ devs would understand Rust immediately. Perhaps a better example: fn foo() -> &usize { let x = 50; &x }
    - tialaramex 5y ago
      I think analogous C++ code is a bug, the text might be a heap allocation (SSO may stash it inside the object) but surely the string object is local and lives on the stack. When the function returns that local object no longer exists and the reference to it is now dangling ? I would say that the relationship between str and String was what most surprised me. I at first assumed the underlying primitive would be String since str is what you get when you borrow from a String, but it isn't. str is a built-in, whereas String is just a type defined in the (optional, this is a systems language) standard library. If your environment can't afford memory allocation, you can't have Strings but you can use str just fine, that's a built-in. Since you lack allocators obviously you won't be going around minting new strings but str is perfectly fine for stuff like substring operations or comparisons.
- galangalalgol 5y ago
  I would have said it was mor like ocaml.
- phibz 5y ago
  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.
kaoD 5y ago
> 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 guarantees, I just find it pleasurable to write and even better to read. Safety is just a plus. I'm not saying this is a universal truth though, Rust just fits my mental model. It isn't even a matter of past experience: I code frontend JS for a living (though I've been exposed to all kinds of code throughout the years) and I actually enjoy JS. I tried really hard to like Go. I just couldn't.
- adamnemecek 5y ago
  I agree. Go just lets you get away with writing garbage.
- pqb 5y ago
  > 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). > I tried really hard to like Go. I just couldn't. I would expect something opposite for most of programmers. Especially, because Rust support in VSCode/JetBrains IDEs was not very good for many years. However, during talks with various people, I have noticed the Go was natural choice for many former Python or Ruby devs, while Node/Java guys had problem with adapting to it. Personally, when I take a look at the Rust code it feels like some ECMA Script in a compiled world.
novok 5y ago
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 do, so your compile time is not easily fixable with large thread ripper style workstations. Do you have similar issues with golang and rust? At least golang was designed to be compiled fast.
- nicoburns 5y ago
  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).
  - phibz 5y ago
    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.
sateesh 5y ago
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.
- pqb 5y ago
  > I never became comfortable with doing object oriented programming with Go, which has not been the case with Rust. Ouch, OOP in Go is just asking for a trouble. "Inheritance" by embedding anonymous struct/interface should be rarely used. Playing with a magic dependency injection, reflection mocking often do not leads to anything good too. > In addition in Go I find the project setup and settings like GOPATH, GOBIN quite confusing. I guess you work on Linux :) Yeah, it is weird, I am glad they have improved that flow by guessing empty GOPATH will be equal to $USER/go/ directory. GOBIN is actually not needed, only if you have used dep dependency manager, which for many years is deprecated.

Cyph0n 5y ago

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.

steveklabnik 5y ago
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.
- Cyph0n 5y ago
  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".
  - steveklabnik 5y ago
    Yup, I’d agree with that.
ibraheemdev 5y ago
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.
- Cyph0n 5y ago
  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.
  - ibraheemdev 5y ago
    > Also, I think str vs. String is usually confusing at first, regardless of your background. Yes, of course. Rust has some new concepts that will be confusing at first, regardless of your background. You still have to understand Rust's destructors to understand that example. I didn't mean to say that it is impossible for Rubyists to learn Rust, or that C++ devs would understand Rust immediately. Perhaps a better example: fn foo() -> &usize { let x = 50; &x }
  - tialaramex 5y ago
    I think analogous C++ code is a bug, the text might be a heap allocation (SSO may stash it inside the object) but surely the string object is local and lives on the stack. When the function returns that local object no longer exists and the reference to it is now dangling ? I would say that the relationship between str and String was what most surprised me. I at first assumed the underlying primitive would be String since str is what you get when you borrow from a String, but it isn't. str is a built-in, whereas String is just a type defined in the (optional, this is a systems language) standard library. If your environment can't afford memory allocation, you can't have Strings but you can use str just fine, that's a built-in. Since you lack allocators obviously you won't be going around minting new strings but str is perfectly fine for stuff like substring operations or comparisons.
galangalalgol 5y ago
I would have said it was mor like ocaml.
phibz 5y ago
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.

kaoD 5y ago

> 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 guarantees, I just find it pleasurable to write and even better to read. Safety is just a plus. I'm not saying this is a universal truth though, Rust just fits my mental model. It isn't even a matter of past experience: I code frontend JS for a living (though I've been exposed to all kinds of code throughout the years) and I actually enjoy JS. I tried really hard to like Go. I just couldn't.

adamnemecek 5y ago
I agree. Go just lets you get away with writing garbage.
pqb 5y ago
> 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). > I tried really hard to like Go. I just couldn't. I would expect something opposite for most of programmers. Especially, because Rust support in VSCode/JetBrains IDEs was not very good for many years. However, during talks with various people, I have noticed the Go was natural choice for many former Python or Ruby devs, while Node/Java guys had problem with adapting to it. Personally, when I take a look at the Rust code it feels like some ECMA Script in a compiled world.

novok 5y ago

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 do, so your compile time is not easily fixable with large thread ripper style workstations. Do you have similar issues with golang and rust? At least golang was designed to be compiled fast.

nicoburns 5y ago
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).
- phibz 5y ago
  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.

sateesh 5y ago

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.

pqb 5y ago
> I never became comfortable with doing object oriented programming with Go, which has not been the case with Rust. Ouch, OOP in Go is just asking for a trouble. "Inheritance" by embedding anonymous struct/interface should be rarely used. Playing with a magic dependency injection, reflection mocking often do not leads to anything good too. > In addition in Go I find the project setup and settings like GOPATH, GOBIN quite confusing. I guess you work on Linux :) Yeah, it is weird, I am glad they have improved that flow by guessing empty GOPATH will be equal to $USER/go/ directory. GOBIN is actually not needed, only if you have used dep dependency manager, which for many years is deprecated.