[akira2501]

I haven't found any issues with expression, so far. I wouldn't use it to write a UI, but for writing networking code or automated tasks I find it perfectly suited to the task.

I appreciate it's error handling. It's burdensome, sure, but it presents almost no additional cognitive load when attempting to reason about control flow.

It essentially has no enums. However, it has a comfortable type system that can wrap primitive types, and you can define methods on those wrapped types. It's serviceable, but not elegant.

I have never been a fan of pattern matching outside of functional languages. The phenomenon I notice in languages that do have it, is the majority of uses cases seem to be a pattern match with two outcomes, one a Some() and the other a None(). It really seems like a more annoying way to write if {} else {}.

It has for, but it also has 'range.' It makes up for a lot.

It has nil pointers, which are just a "zero value." It's not uncommon to make it useful and safer in certain contexts. You can request a lookup in a map that is nil. You can ask for the length of a slice that is nil. You get sensible answers still. There are still footguns, but they're all single barrel.. which is _nicer_.

I don't need a perfect language. Good enough with low cognitive load and amazing cross-compile facilities I'll take any day of the week.

[nu11ptr]

I will agree Rust has a higher "cognitive load", but not if you write it every day. I think Rust might be tough to leave and come back say a year later, but Go admittedly would be easy. That said, having written 50K+ code in both languages, I never want to write Go again. Rust on the other hand is all I want to write now. 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 can't imagine anyone would want to go back tbh, but maybe I'm wrong.

EDIT: In fairness, there is one thing and exactly one thing I miss about Go: compile times. Rust is simply no competition here, but in trade, it is doing a ton of extra work. Trade offs.

[coder543]

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

[baby]

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.

[seer-zig]

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

[Tozen]

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.

[bayindirh]

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.

[ikiris]

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.

[steveklabnik]

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.

[yawn]

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.

[kaba0]

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)

[steveklabnik]

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.

[scoutt]

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?

[zarzavat]

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.

[saghm]

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

[Klonoar]

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

[zarzavat]

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.

[baby]

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.

[cercatrova]

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.

[qaq]

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.

[masklinn]

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

[qaq]

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

[throwaway2037]

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

[sph]

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

[throwaway2037]

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!

[Klonoar]

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

[Tozen]

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.

[Klonoar]

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

[qaq]

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.

[baby]

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

[lsaferite]

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

[baby]

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.

[Klonoar]

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.

[kaba0]

And much more error prone.

[fnord123]

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.

[peaky_blinder]

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

[simiones]

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

[kaba0]

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

[pizza234]

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.

[pdimitar]

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.

[stouset]

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.

[vlunkr]

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

[swsieber]

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.

[baby]

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.

[_0w8t]

For me error handling adds a significant distraction due to high vertical space consumption leading to a lot of extra scrolling.

I wished Go formatter would compress

    if err {
        return err
    }

to

    if err { return err }

Even better would be to extend the syntax to allow

   if err return err

But I am Ok with braces.

[bobbylarrybobby]

Two comments:

There are two reasons to have match: exhaustiveness and destructuring/pattern matching. I don't think there's an if/else parallel to `match result { Ok(t) => { ... }, Err(e) => { ... } }`

The fact that a `nil` value can be made useful (which, AFAICT, means it won't blow up your program?) is not a good enough reason to include them in the language. Rust can do perfectly useful things with, say, `Option<Vec<T>>`, and it's possible to distinguish between `Some(vec![])` and `None`. If you care to ignore that distinction you're free to do `maybe_vec.map(|v| v.len()).unwrap_or_default()`. But IMO it's much better to tell the compiler to unify different cases (`None` and `Some(empty)`) than to have to work around the compiler's unification of those cases when you don't want it. It's always easier to increase entropy than to decrease it. (P.S.: should the sum of a nil list be 0, or NaN, or...?)

[int_19h]

The problem isn't null/nil as such, it's when the type system treats null values as legal at compile-time.

But if you look at e.g. Kotlin, or C# with "#nullable enable", it tracks whether a given reference can be null or not. So you write if-else code instead of match, but you have to do that in order to actually do something with a reference.

[morelisp]

> The fact that a `nil` value can be made useful (which, AFAICT, means it won't blow up your program?) is not a good enough reason to include them in the language.

"Nil is useful", in Go, means that for expensive objects it's often appropriate to pass nil instead of an empty or defaulted object, and call methods on it that act as if it was an empty object or with some default/no-op behavior. This is most obvious with lists/maps but can be applied to all concrete types.

While I can imagine a language in which `Option<T>` can re-export some of `T`'s method set with a default behavior, in practice I don't know any which actually do this.

[tialaramex]

> The phenomenon I notice in languages that do have it, is the majority of uses cases seem to be a pattern match with two outcomes, one a Some() and the other a None(). It really seems like a more annoying way to write if {} else {}.

In Rust you write this type of thing as:

  if let Some(name) = order.get_name() {
   println!("Order ready for {name}!");
  } else {
   println!("Order number {} ready!", order.num());
  }

So, it's a destructuring pattern match just written as an if-else. Because we did the match here, we can't forget and end up using name when there wasn't one, the variable only exists when it's bound.

[aatd86]

If I may ask, I'm curious about why you wouldn't use it to build a User Interface?

[akira2501]

One is Go's module/import system. It's pretty inflexible and the connection between exported functions and types and how they are Capitalized or not does create friction for me when I'm "building up" code bases from scratch. Puzzling about module boundaries and type definitions feels like it would consume more time than it's worth in a UI oriented program.

The other is most UIs are wrappers around other functionality, often in libraries. Working on anything other than pure Go code bases adds additional friction, and dynamic libraries add to that complication considerably.

[randomdata]

On the other hand, Go's defining feature: Its CSP model, lifted from Newsqueak, was originally designed for user interfaces.

I believe Go could be a really great fit for UIs, but likely never will be as there is little economic incentive to put in the incredible heavy lifting required to build up the support libraries. There are certainly some small projects trying, but without massive resources backing it, it is a struggle to achieve the full fit and finish that we've come to expect.