[mbvisti]

For the record, I love Rust. It’s an amazing language and my example was not meant to discourage the use of Rust. But, it is verbose and generally takes longer time to write and understand compared to Go. For most projects, Go simply fits the bill for speed of development, ease of use, onboarding new people and performance.

[umanwizard]

> But, it is verbose and generally takes longer time to write and understand compared to Go.

I respectfully disagree, and I don't think I'm alone in that. I would be willing to bet that the majority of people who have used both languages professionally would agree with me.

Reading or writing N lines of Go is easier and faster than reading or writing N lines of Rust, true. But you have to repeat yourself so much in Go that doing the same thing takes a lot more lines of code than it does in Rust, so reading and understanding a whole program that does something useful is much harder. And that's just reading. Writing is even harder because Go has very few guardrails for protecting against important classes of bugs, so you spend way more time debugging issues that are just not a thing in Rust.

> For most projects, Go simply fits the bill for speed of development, ease of use, onboarding new people and performance.

I disagree about speed of development for the reasons I said above. Ease of use is subjective; I find Rust much easier to use than Go (no exhaustive match on tagged unions in 2024? Really?) As for performance, Rust is hard to beat. So you're left with onboarding new people. Sure, Go is easier to learn than Rust. But it doesn't really make sense to optimize a language for the first 100 hours spent learning it when for most people it's a tool they will use for years.

[IshKebab]

I agree with you. Go saves a lot of time by having an amazing standard library and tooling... but the tedious writing out of the loops man! I don't even mind `if err != nil` - that's just proper error handling, but writing out loops and maps by hand like a cave man... I can't go back to that.

[mbvisti]

Haha that's fair! I do miss Rust semantics with .map(), .filter() and chaining them together.

[umanwizard]

It's not just Rust that has those, it's every modern language except for Go (because Go is the only one run by "simplicity" ideologues who reflexively refuse to consider adding modern features).

[mbvisti]

I can’t claim to have been paid to write rust, but I’ve written code professionally for many years now and most of them in Go. I have also written my fair share of rust code for web applications.

The repetition in Go, in my experience, mostly happens at the beginning and then you only have to deal with ‘if err != equal nil’, which to be fair is probably a good thing. Is it really more verbose and repetitive than error handling in rust?

I would love to have the type system rust has in go. It really allows you to be expressive and put in guard rails in a way you can’t using go. But I don’t think most applications need that.

My experience tells me something different than yours, maybe I’m wrong. But I can’t reconcile your arguments with my experience writing rust web applications. Even if I still miss writing my queries using sqlx and my views with asakama.

[umanwizard]

> Is it really more verbose and repetitive than error handling in rust?

Of course.

  if err != nil {
          return nil, err
  }

is 34 characters in Go, counting a tab as one character. The Rust equivalent,

  ?

is one character.

But Go verbosity and repetition isn't limited to error handling. Another example is e.g. the lack of any metaprogramming capabilities (e.g. macros) which forces you to either copy and paste code or write a code generator in many cases (or use runtime reflection).

> I would love to have the type system rust has in go.

Unfortunately you will never get it, because Rob Pike's ideology is "if it didn't exist in C, it's too complicated and difficult for Go programmers to understand".

This isn't a joke or exaggeration -- programmers being too stupid to understand modern features has actually been cited as one of the main design constraints of Go.

> But I don’t think most applications need that.

Of course nothing needs it, just like nothing needs function calls (it was possible to write large applications in assembly language). But most applications (including all the ones I've ever written) benefit from it. Rust's type system is there to make it easier to write programs, not to make your life harder.

> My experience tells me something different than yours, maybe I’m wrong.

I wrote Rust professionally for 5 years and Go so far for about 6 months (and even that was not spent full-time on Go). So I don't claim to be an expert. But I am constantly running into things that Go makes difficult or impossible that would be a breeze in Rust.