DEV Community

Discussion on: What aspect of Go were you at odds with, coming from a different tech stack?

Collapse
 
rhymes profile image
rhymes

Quoting a response of mine from December, hoping it answers your question.

TLDR; about the odd parts: syntax sometimes, error handling, interface{}, code generation as a standard way of living inside Go's universe.

My experience with Go:

  • I didn't like it in the beginning, I read some snippets around and was balking at pointers, C like constructs, error handling and stuff about the syntax. I ignored it for sometime
  • I started using Go beginning of 2018 because it made sense for the server I was writing but I wasn't and I'm still not totally in love with it
  • I don't like either that they call package modules and viceversa, but it's just naming
  • Signed and unsigned types are there because Go was supposed to be a system level language (and some people use it as such), there are cases where you need uint8 instead of the generic int like you can use 99% of the time. I'm sure that writing a parser for protobuf or something like that, they come in handy. Also remember Go has a FFI towards C
  • the tutorial talks about for because that's what you end up using the most, in addition to if and such
  • the if name, ok := elements["Un"]; ok pattern is annoying but it's a shortcut for two lines. There are no exceptions nor there is pattern matching so you end up with almost everything returning a value and an error
  • Regarding interface I don't have much to say, it's not the perfect solution, everyone knows that, they are probably going to fix it with generics in Go 2. You don't have to deal with it everytime you write code though. A good thing about interfaces in Go is the sort of "duck typing" where if you implement all methods then you're compatible with the interface, so everything is compatible with the empty interface. This mechanism is sometimes abused by people who write massive interfaces, but that's another problem
  • I agree between var a and a :=. The latter also leads to shadowing variables. I don't like it, other people here seem to like it

Syntax is not much of a counter argument because it's subjective and that subjectivity changes with time. You list R as the languages you know, that has a hideous syntax but still, it does what it has to do.

I agree syntax is important but we underestimate our adaptability or overestimate how much important it actually is. I hate PHP syntax yet there are hundreds of thousands of people that are fine with it. I hated Go syntax by looking at it yet I spent a couple of days with tutorial and Go by Example and now it's etched in my brain and I'm okay with it. I have a vague idea about what that Elixir code is doing (because I picked up Erlang years ago, and forgotten most of it) and I honestly don't like the syntax you pasted but I'm 100% sure that if I were to spend a day with the tutorial I would be fine with it as well. Pattern matching is one of the greatest things about Erlang (and Elixir), it's just that we're not used to the declarative syntax. I think we yap too much about syntax and not enough about actual problems of this or that language (lately I'm starting to think async/await is a bad pattern but that's for 2019 :D)

If we want to talk trash about Go there are plenty of arguments: no generics (and your criticism about interface is valid, it's just a well known error in design), the error handling still hasn't convinced me 100% and it can get annoying (they are thinking of tweaking it), channels are thrown around as a panacea but they are still subject to race condition (at least the more recent articles are mindful of that), there aren't that many data structures in the standard lib and the over-relying on code generation for some libs.

In return your get a language simple to pick up (a pro or a con, ymmv), reasonably simple to use concurrently, with small footprint and easy binary deployment and fast (cross) compilation.

The author, Pike, regretted having called it a systems language in the beginning and as you noticed it was birthed as an equalizer to help experienced and less experienced developers work on the same code base. Google has that famed mono-repo taking ages to compile, they needed something for everybody which means compromise.

I don't think Go is the perfect language but it's good enough for lots of server side software. I wouldn't use it on the client side for systems development, and it seems that Rust is slowly taking off there.

Thanks for the laughs, for once I mostly agree with you ;-)