Hacker News Reader

> That said, I am curious why different people have these different feelings. One aspect is likely rooted in the fact all of our brains are different. But I also wonder if first impressions play a big role here.

Path dependency has big impact on what seems natural, intuitive, etc. Part of that is what you've done before, and part is first impressions, and part of it is your approach to learning (or the approach taking to teaching you) the subject at hand.

I’ve approached Rust via different books and tutorials before and come up with the “it’s awesome, but too hard” feeling and set it aside.

Recently I've been trying Hands-on Rust [0] and going off to the side from it and Rust is clicking pretty well. Not sure if the book is a better fit for me, if the past false starts have prepared the ground, or what specifically changed.

[0] https://pragprog.com/titles/hwrust/hands-on-rust/

> Path dependency has big impact on what seems natural, intuitive, etc

So much this. One example I hit a lot is when people keep saying “async/await is too hard, green threads are much more intuitive”: coming from a JavaScript background I feel async/await and all the future combinators much more intuitive than dealing with threads and channels. Before async rust was stabilized I had to learn how to use threads and I was always frustrated how clunky it felt, and now that Rust has async/await I use it for everything IO related, because to me it's just much more familiar.

I hadn't heard of the term "Path dependence" before, thanks for sharing that. I think your comment is a better articulation of what I was trying to say: it's not actually about your first impressions with rust, but really about all your past experiences with programming and learning programming languages (up to and including your first impressions with rust)

Despite being contemporaries, both nominally for systems programming, Rust and Go are very different, starting with memory management. If you're used to writing (correct) C++ programs, particularly those that exploit move semantics in C++11 and later, then you can appreciate what Rust is doing for you, weird syntax and all.

On the other hand, if you're fine with a garbage collector, which most people are most of the time, then Go is going to feel more natural. For some people, Go is more comparable to Python than Rust, because of this one big difference.

The big issue I had with learning Rust is not the simple stuff -- I could write safe Rust fairly quickly. The problem I continue to have is that many internal behaviors of the language are totally undocumented and inexplicable. For example, implicit reborrows. They happen everywhere, but it's still just a pile of unicorn farts as far as documentation. The idea of a language with no documentation for a given syntax is horrifying. Rust does very well in documentation for beginners, but if you actually want to understand the language, if you want to know what's really happening, you're usually fucked.

> A good example of a cryptic rust error is the `expected type Foo, but found type Foo` error message which is very inscrutable, especially to a new users.

Does Rust actually give an error like `expected type Foo, but found type Foo`, as in both types are the same in the error? I don't think I've seen that before, but I don't write much Rust.

If both types are the same, what does the error mean?

I've seen this error a lot when working with two different versions of the same library. Specifically, you can directly include version A, but a different library depends on a version B, with some of that exposed in the public API.

I think the compiler will now give you a hint that they may be from different versions. If not, next time you see it you should open up a bug in rustc.

To anyone who gets a cryptic error message - that's a bug, report it.

Yup, newer compilers will give you an explicit hint about thee types from being different versions of different crates, but older compilers did not.