It's not about refactoring for me. It's about trying to grok what the heck some library author or coworker was thinking when they went all Architecture Astronaut with the type system and traits. It reminds me of how people go crazy with OO and end up with delegation spread across several files. I already have to hold the problem in my head. I find that Go takes such a mental load off my shoulders that I find it the easiest to grok other's intentions (including my own several months/years later) in.

It may depend on the problem at hand as well. I never really bought this “each line is easier to comprehend” reasoning, because then ad absurdum we would all be writing assembly.

But sure, one is a low level language which can and thus must care about every little detail, while the other is a managed language. (And honestly, mixing the two as if they share the same niche is very off putting)

That's fair. In my mind, they're at least related: if I'm trying to learn about some code, I change stuff and see what breaks.

Just as parent, my greatest struggle with learning Rust is to open someone else's code and trying to understand what is going on. With C that's a lot easier.

I you were to learn Rust from scratch, what project would you recommend for the "changing and breaking" approach?

I don't know if I use that to learn the language itself, but also, different people have different learning styles. What I personally do to learn new languages is write some sort of program that I know well. So for me, that's text adventure games. When I'm trying to learn a new language, I go and make a very simple one. This helps because you're not learning a new domain and a new language at the same time.

But along the whole "break it" idea... I don't know if you're an IDE person or a text editor die-hard, but I've found that rust-analyzer helps a ton. I'm historically a "vim with no plugins" kind of guy, but I'm using VS: Code with the vim keybindings now, and even if I'm not changing some code and getting feedback from the compiler itself, using rust-analyzer to go "hey what's this type here? Where's it defined, let's go take a look" has helped a ton.

That said, types help and poking around helps, but it's not always a panacea. Today I'm working on fixing something that doesn't quite work, even though yesterday I figured out how to assemble everything I'm supposed to need from this library I'm using. "It compiles it works" is a thing people say, and while I feel that way often, it's not true all of the time, of course.

The differentiating factor is probably prior exposure to C++. If you have used C++ then Rust is so easy and convenient and fun. It takes hideous C++ monstrosities and turns them into easy one liners.

If you have never used C++ and your baseline is Go or JavaScript then it probably looks like a confusing hellscape. You have to learn a whole new kind of type system, a new nomenclature (“Vec”s instead of “Array”s), new concepts like allocators, plus the borrow checker and lifetime annotations, and module/crate system. Former C++ programmers only have to learn the latter half.

> The differentiating factor is probably prior exposure to C++. If you have used C++ then Rust is so easy and convenient and fun. It takes hideous C++ monstrosities and turns them into easy one liners.

Obviously you didn't mean that as a universal rule, but for posterity, I'm a counter-example to that. I learned Rust before learning C++ or Go. If anything, I think this biased me _more_ towards Rust than the others; C++ just kind of felt like a more error-prone, less ergonomic Rust, and Go just felt like it took far too much boilerplate to get anything done.

>If you have never used C++ and your baseline is Go or JavaScript then it probably looks like a confusing hellscape.

I'm not sure this is accurate - have you seen modern TypeScript? I actually find that more confusing than Rust to read.

(FWIW, I was predominantly Python/JS-centric before just going "all in" on Rust. It's not that bad, in my experience - if anything, I find Rust "just works" whereas I got tired of the churn in those environments)

Yes, TypeScript can get very complex too. But there is little overlap in the complexity of TypeScript, which mostly comes from learning how to program within the structural type system; and Rust which is about memory management without a GC.

Rust and C++ are like Hebrew and Arabic. Difficult languages for an outsider, but if you speak one you have a significant head start towards learning the other. TypeScript is Japanese: knowing Japanese doesn’t help you speak Arabic, despite both being difficult.

I hate C++ but got used to Rust. It just has a steep learning curve unlike Golang. Takes a while but when you get there it is really pleasant.

On the other hand Golang can be fun in like a week of learning it.

Not really. I come from TypeScript and started writing Rust, and they're quite similar in terms of type expressiveness. With both I feel the same level of comfort of refactoring.

Meanwhile Go doesn't even have algebraic data types. I can't imagine working with a language that doesn't have these kinds of functional features anymore after having gotten used to them.