Live data from Hacker News

Why you should use Go

mortenvistisen.com

61–70 of 75 posts

Re: Why you should use Go

#61
post #45

Earlier quoted context omitted.

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

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 erro…

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

Re: Why you should use Go

#62
post #57

Earlier quoted context omitted.

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.

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

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

Re: Why you should use Go

#63

This horse has been long flogged to death. My list: Mostly fits in my head, gc, not horribly slow, boring concurrency, low effort cross-compilation, good distribution story. It's contentious but I like the "low abstraction ceiling". Go punishes people who want to turn everything into a framework or abstraction and rewards people who just knuckle down and write the code that solves the actual problem instance. Is it t…

Even if you do discover a better abstraction, I find Go's tooling makes inevitable refactoring less terrible than other languages. I can easily see where I "broke" code--gopls makes fixing things really easy.

Go is not the only language with an LSP implementation. What other ones are you comparing gopls to?

Re: Why you should use Go

#64
post #55
post #30

The author here, thanks for posting this. I can see a lot of people not agreeing with Go, that’s fine, I still love writing it everyday. Taking choices away from you in terms of language features enables you to focus on the problem you’re solving. That makes it a great choice to me.

Thanks for writing this up. > Taking choices away from you in terms of language features enables you to focus on the problem you’re solving. As someone that worked with Kotlin for a couple of years, I can agree with this. I actually enjoyed the language but there were so many, I'd say, obscure things or multiple ways you could do the same thing that I'd feel lost sometimes. As someone once said - Kotlin is easy to wr…

This is a false dichotomy though. Not wanting to end up as a kitchen-sink language like C++ doesn't mean that you have to swing completely to the other extreme and refuse to add any modern feature (except possibly after years of fighting), even the ones that exist in every other modern language and have proven to have no real downsides and be hugely useful (like sum types).

Re: Why you should use Go

#65
post #56
post #55

Earlier quoted context omitted.

Thanks for writing this up. > Taking choices away from you in terms of language features enables you to focus on the problem you’re solving. As someone that worked with Kotlin for a couple of years, I can agree with this. I actually enjoyed the language but there were so many, I'd say, obscure things or multiple ways you could do the same thing that I'd feel lost sometimes. As someone once said - Kotlin is easy to wr…

Yeah, personal feelings towards a language are a big factor. I once did a short gig with a start-up that used Kotlin and the CTO was very enthusiastic about Kotlin. He showed all the things you could do in the languages like adding behavior to an integer that would be applied throughout the program. He was excited and I was a little horrified haha. But huge companies have been built using Kotlin so who am I to judge?…

It's very arrogant to imply that people who prefer other languages don't want to "solve problems and build products".

That's what everyone wants to do. They just think Go is not the best tool for doing it.

Again, you seem to think everyone else is some kind of academic egghead who enjoys other languages because they let them solve intellectual puzzles. That's not true, they prefer other languages because those other languages are better than Go for practical reasons.

Re: Why you should use Go

#66

Earlier quoted context omitted.

There are tons of examples. So here's a random one: a function that sorts an array. You either need generics, need to write it using runtime polymorphism (making it significantly slower), or need to re-write it for every type of element that you want to sort an array of. The fact that Go has functions called sort.Strings, sort.Floats, sort.Ints, etc. is just silly duplication that wouldn't have happened in any other…

Wouldn’t you just use sort.Slice? Doesn’t go having such type specific functions mean you don’t have to? Feels like that makes your codebase _less_ complex since the core logic is handled by the language stdlib, not code written and maintained by your team.

> Wouldn’t you just use sort.Slice?

That is what I meant by runtime polymorphism. It is slower. The fact that runtime polymorphism is so widely used despite being a crappy hack imitation of generics proves how useful generics is.

Edit: Nevermind, sort.Slice doesn't use runtime polymorphism. It makes you pass in a comparator function. So probably not slower (assuming the function can be inlined), but less ergonomic.

> Doesn’t go having such type specific functions mean you don’t have to? Feels like that makes your codebase _less_ complex since the core logic is handled by the language stdlib, not code written and maintained by your team.

I'm not talking about the complexity for people using the code, but for the people writing it. Realistically not everything is in the stdlib and at some point you have to actually write some code. And at that point the features that make it easier to write code, like generics, make your life easier.

(Also the Go sort package only has support for a few built-in types. What if you want to sort a slice of user-defined structs? Then you have to use runtime polymorphism via sort.Slice, which is slower for no good reason).

Re: Why you should use Go

#67
post #56

Earlier quoted context omitted.

Yeah, personal feelings towards a language are a big factor. I once did a short gig with a start-up that used Kotlin and the CTO was very enthusiastic about Kotlin. He showed all the things you could do in the languages like adding behavior to an integer that would be applied throughout the program. He was excited and I was a little horrified haha. But huge companies have been built using Kotlin so who am I to judge?…

It's very arrogant to imply that people who prefer other languages don't want to "solve problems and build products". That's what everyone wants to do. They just think Go is not the best tool for doing it. Again, you seem to think everyone else is some kind of academic egghead who enjoys other languages because they let them solve intellectual puzzles. That's not true, they prefer other languages because those other…

Mate, come on. I've implied none of that. Just said that the simplicity of Go tends to shift my focus, at least, to the problem and product, not as much the implementation.

You like Rust and hate Go, that is very clear. But maybe before you call me arrogant and put words in my mouth, read back my comments. I haven't trashed other languages or told people that what they like is shit. Simply that I like Go, and that I don't agree with your arguments.

Re: Why you should use Go

#68
post #67

Earlier quoted context omitted.

It's very arrogant to imply that people who prefer other languages don't want to "solve problems and build products". That's what everyone wants to do. They just think Go is not the best tool for doing it. Again, you seem to think everyone else is some kind of academic egghead who enjoys other languages because they let them solve intellectual puzzles. That's not true, they prefer other languages because those other…

Mate, come on. I've implied none of that. Just said that the simplicity of Go tends to shift my focus, at least, to the problem and product, not as much the implementation. You like Rust and hate Go, that is very clear. But maybe before you call me arrogant and put words in my mouth, read back my comments. I haven't trashed other languages or told people that what they like is shit. Simply that I like Go, and that I…

It's entirely understandable that you have a different opinion from me; I just don't like the implication that "caring about solving problems" makes one appreciate Go, since that is what nearly all professionals care about.

Btw, my opinion isn't just "liking Rust" -- Rust has plenty of problems. My opinion is that Go is uniquely bad among modern programming languages. Most of the major flaws in Go are fixed in every other modern mainstream language, of which Rust is merely one example.

Re: Why you should use Go

#69

Earlier quoted context omitted.

I guess I'm part of that cult as I value simplicity greatly. Heck I was even against generics and iterators, though the former has grown on me a bit. One question I ask in earnest, why do people not just use another language rather than try to get features jammed into Go? There are so many good ones out there now, it feels like a person can choose something to their own liking. If it's being forced at work, I guess t…

You value simplicity because all of the complicated and painful code (mostly as a fault of Go's shortcomings) have been abstracted away from you.

I guess that depends on your definition of simplicity. I don't think of simplicity as 'easy to do' or 'less lines of code', but in terms of easy to immediately understand what the code in question is doing, both from explicitness of said code and size of language. Perhaps I should have used 'readability.'

Re: Why you should use Go

#70
post #55

Earlier quoted context omitted.

Thanks for writing this up. > Taking choices away from you in terms of language features enables you to focus on the problem you’re solving. As someone that worked with Kotlin for a couple of years, I can agree with this. I actually enjoyed the language but there were so many, I'd say, obscure things or multiple ways you could do the same thing that I'd feel lost sometimes. As someone once said - Kotlin is easy to wr…

This is a false dichotomy though. Not wanting to end up as a kitchen-sink language like C++ doesn't mean that you have to swing completely to the other extreme and refuse to add any modern feature (except possibly after years of fighting), even the ones that exist in every other modern language and have proven to have no real downsides and be hugely useful (like sum types).

There is no false dichotomy in my comment. I'm quite happy using Go. It was easy to pick up, the executables work fast and flawlessly and as a language it delivers the required results in what I do so far. Time will tell, but its simplicity does work great for me, and I've tried quite a lot of languages in the past 2 decades.
Post reply on HN