Hacker News Reader

The problem with rust is explicitly that cognitive load in large codebases. It is much easier to read go code than rust when working on many things. Rust fits great if you don't scale though.

It’s funny how experiences differ; I can’t comment on how Go fares here, but if anything, I find that the compiler takes such a mental load off of my shoulders that Rust is the language I find easiest to make large refactorings in.

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.

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.

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)

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.

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

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

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.

Anecdote:

I have had year+ long breaks between writing Rust applications. I have been able to get back into it without issue very quickly. At least one of those times I successfully completed a large, sweeping refactoring of a project of mine that had lay untouched for three years. I can confidently say it would have been extremely difficult to do that same task in other languages I consider myself very proficient in and use daily.

> I do wonder how many people who understand Go's limitations (and work around them as you point out above) have truly given Rust a try (takes a few months - can't be done faster)

This is basically the "Anyone who doesn't love my favorite movie hasn't watched it enough times" argument. Programming language design is a complex space, there are no "correct" opinions.

No, I don't thinkbit is that argument. I think the argument is "Rust has a really steep learning curve". Nor do they imply that everyone who has given Rust 3 months will like it.

I tend to agree with his argument though, I can see how a lot of Golang developers would really benefit and enjoy migrating (I’m one of them) but I think it also depends on the type of applications that you usually write.

Async code is way nicer in Go than it is in Rust. It makes up for a lot for me when writing web services. Also Go is much easier to read vs Rust.

>Also Go is much easier to read vs Rust.

This is subjective - I for example have no real issues reading Rust code, but find Go to look like utter spaghetti on the screen.

That’s probably because you’re not used to it. I think it’s common knowledge that Golang is easy to read.

Couldn't the same be said of rust though? The biggest barrier, in my experience, is almost always familiarity with the syntax.

Pretty much this, yes.

I think my comfort with Rust moreso comes from it feeling like any other C-ish language in appearance. It reads as expected to me.

I work mostly with Rust, and have been for years, and no I wouldn't say that Rust is easy to read. It's easier to read than most legacy languages, but it's nothing like Golang.

Sure. But just due to Go type system being pretty basic I've never came across Go code I could not immediately grock, not so with Rust. Even bugging some pretty savvy Rust devs for help it sometimes took them a decent amount of time to pin down whats going on.

I have to side with those saying Go has greater readability, and is easier to use and learn. I know there is a strong push (and arguably corporate backed) to put Rust in everybody faces or present it as being superior, but we still need to be realistic and honest. Not saying that Rust doesn't have its places where it can shine, just that a lot of people are going to find Go to be easier to deal with overall, and it was partially designed to be that way.

>I know there is a strong push (and arguably corporate backed) to put Rust in everybody faces or present it as being superior

No part of my comment was doing this, and this bit is entirely unnecessary and adds nothing to the comment you wrote except fan religious wars about languages.

And much more error prone.

Depends where someone comes from. If they are from a weakly or dynamically typed language (C, python, Javascript) then Go is quite ok. If you're coming from Haskell, OCaml, or Rust, then sure Go might be frightening.

They're all weakly typed languages but C is statically typed.

I think parent didn't say anything to the contrary, or maybe it was edited?

First iteration was didn't include the part about haskell/ocaml.

Python is generally considered quite strongly typed, though dynamic. That is because Python has relatively few implicit conversions, and especially few that are surprising ("1" + 1 is an error, not 2 or "11"; and unsigned short + unsigned short does not equal a signed int).

> Async code is way nicer in Go than it is in Rust.

That’s because Go does not have async code. It has sync code on an async runtime. Like e.g. Erlang/Elixir.

This is an interesting comment. Is there a webpage where I can read more about this idea?

Perhaps https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

That guy is a lengendary blogger! And I have read that post. It was very eye opening. I always struggle when I write an (internal) API that has sync (blocking) and async (non-blocking) sections and methods. It quickly becomes very difficult to reason about!

Exactly don't have to deal with red/blue functions

> I do wonder how many people who understand Go's limitations (and work around them as you point out above) have truly given Rust a try (takes a few months - can't be done faster)

I have written both languages professionally in various contexts for years. In point of fact, I've been writing Rust since before Rust 1.0 came out, although I didn't get my first Rust job until about 3 years later. They're both excellent languages. I actually didn't learn Go until several years after learning Rust, and at the time I didn't appreciate it like I should have, since I was so excited about Rust. Only after getting professional experience with Rust did I truly begin to appreciate how nice Go is for the things it is good at.

Go is just so much better suited for network-connected services (including but not limited to web backends), and Rust is better suited for batch processing or embedded contexts where no compromise on performance can be made, in my experience. There are lots of reasons for this, but it's off topic from the question, and the answer to the question is that I absolutely do go back to Go. Neither language is a perfect tool for all problems, and I constantly dream about building my own language that learns from the best of both... there is certainly room for improvement on both ends.

I have a similar experience. Used to write a lot of golang, and now I write a lot of Rust. I think I would have pointed out the same issues: auditing Golang network code you can often find easy DoS attacks due to nil values being dereferences (protobuf I’m looking at you), there’s no sum types or enums, etc. Still though, I miss how easy it is to read golang and ramp up on a codebase. Even today I sometimes come across a golang codebase and look for something and I can always easily follow the code. Eventhough I’ve written a lot of Rust, it’s always challenging to ramp up on a Rust codebase, and the language is often abused because it’s too expressive. I’d still say Rust is so much more pleasant to write due to that expressiveness. It really is a double edge sword.

It shouldn't be a Rust vs golang. golang is mostly a somewhat better python, and mostly for writing backend services.

You can compare its domain (to a certain degree) to Java or C#, in which case the latter two are superior due to the reasons mentioned previously (enums, pattern matching, etc.).

Agree, about the "us vs them" mentality. The tribalism has gotten out of hand, though I kind of suspect some of it is corporate interests being behind it to push the illusion its a "winner take all" game and "putting the batteries in the backs" of many of the evangelists.

It feels like the language wars of 90s and 00s all over again, and I personally don't want to go through that cycle again.

I don't want to take sides, I want to enjoy programming and learning, that's all. When zealots zeal, kinder people either leave or go underground.

I've been surprised how writing Rust becomes smooth with experience (mostly; it's still complex in some areas), however, there's more to a language than just the formal part.

Rust requires designing the memory management (ownership/lifetimes) of a program, which Golang doesn't, so even if/when the cognitive load is (hypothetically) equal, there's an additional, non-trivial demand. This is not something that everybody wants in a project (the given tradeoff may not be worth); for sure, if I had to introduce a language in my team only for tooling purposes (ie. small programs), Rust would not be the most productive choice IMO.

That's where I gravitate recently. I got a few more gray hairs learning and doing async Rust and I love the resulting program's speed and correctness.

But it's not easy to quickly prototype stuff with. Just recently I had to write no less than 7 small prototypes and I gave up on the second one, relearned Golang -- took me an hour -- and finished 3 prototypes in a day.

I tend to go all the way in languages so I can use them freely afterwards. But... In Rust's case I just can't justify the effort. Golang really helps you start off a project faster.

I'll still 100% Rust. I'm working on it every day. But indeed, let's use languages where they are at their best.