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.

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

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

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

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

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.

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

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.

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

Yup, I’d agree with that.

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.

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.

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.

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.

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

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.

I would have said it was mor like ocaml.