5 ms·

I typically develop in Python, C++, and Typescript, and recently had to implement some code in Go. So far I've found it a pretty unpleasant language to use. I

by rcv 3y ago

I typically develop in Python, C++, and Typescript, and recently had to implement some code in Go. So far I've found it a pretty unpleasant language to use. It feels pedantic when I don't need it to be, and yet I have to deal with `interface{}` all over the place. Simple things that would be a one-liner Python or TS (or even just an std::algorithm and a lambda in C++) feel like pulling teeth to me in Go. I'd love to hear of any resources that can help me understand the Zen of Go, because so far I just don't get it.

badrequest 3y ago
I write Go every day, and can count the number of times per year I have to involve an `interface{}` literal on one hand. Unless you're doing JSON wrong or working with an API that simply doesn't care about returning consistently structured data, I can't fathom why you'd be using it "all over the place."
- coffeebeqn 3y ago
  Me too. We have around a dozen go services and I have maybe used or seen interface{} once or twice for a hack. Especially after generics. I think the parent comment is suffering from poor quality go code. It’s like complaining about typescript because things in your codebase don’t have types
  - xarope 3y ago
    Dealing with databases and data scanning into custom structs, you would be writing lots Scanner/Valuer custom functions which use interface{} If you are the lucky ones not dealing with databases, I sort-of envy you...!
    - kiitos 3y ago
      Applications should basically never need to write custom Scanner/Valuer functions that deal in interface{}, if you find yourself doing that it's a red flag
    - badrequest 3y ago
      I use sqlc and it makes this a non-issue.
Spiwux 3y ago
You discovered the Zen of Go. There are no magic one liners. It's boring, explicit and procedural. Proponents argue that this forced simplicity enhances productivity on a larger organisational scale when you take things such as onboarding into account. I'm not sure if that is true. I also think a senior Python / Java / etc resource is going to be more productive than a senior Go resource.
- goatlover 3y ago
  Go seems like the antithesis to Lisp.
- pharmakom 3y ago
  ... so the code ends up being really long then.
  - Spiwux 3y ago
    Yes, pretty much. It's a pain to write, but easy to read. On a larger scale the average engineer likely spends more time reading code than writing code
    - tuetuopay 3y ago
      I don't find go that easy to read. It is so verbose that the actual business logic ends up buried in a lot of boilerplate code. Maybe I'm bad at reading code, but it ends up being a lot of text to read for very little information. Like a one-line list comprehension to transform a collection is suddenly four lines of go: allocation, loop iteration, and append (don't even start me on the append function). I don't care about those housekeeping details. Let me read the business logic.
      - kiitos 3y ago
        Go offers a programming interface at a lower level of abstraction than languages like Python or Ruby. What you call boilerplate or housekeeping, I consider to be mechanical sympathy. Modulo extremes like Java, the bottleneck for programmers understanding code is about semantics, not syntax -- effectively never the literal SLoC in source files. It's not as if for i := range x { x[i] = fn(x[i]) } is any slower to read, or more difficult to parse, or whatever, than e.g. x.transform(fn) in any meaningful sense.
gtowey 3y ago
Go is the language that's not made for you, it's made to make the life of the next guy who has to maintain your code easier! :-)
- Cthulhu_ 3y ago
  That's a great way to phrase it, I'm going to steal that :D
- za3faran 3y ago
  It's harder to maintain compared to similar logic written in Java or C#.
- neonsunset 3y ago
  This is partially correct. It is made to solve internal Google's politics and the hubris of yet another graudate with a CS degree and an itch to justify hours he or she invested in practicing Leetcode (which, in turns, is a skill of writing mediocre stdlib code for languages that have inadequate stdlib)
vineyardmike 3y ago
One of the big things that I’ve found helped is to “stop being an architect”. Basically defer abstraction more. People, esp from a Java-esque class based world want class inheritance and generics and all that jazz. I’ve found at work like 50% of methods and logic that has some sort of generic/superclass/OOP style abstraction feature only ever has 1 implemented type. Just use that type and when the second one shows up… then try to make some sort of abstraction. For context, I can’t remember the last time that I actually used “interface{}”. Actual interfaces are cheap in go, so you can define the interface at use-time and pretty cheaply add the methods (or a wrapper) if needed. If you’re actually doing abstract algorithms and stuff every day at work… you’re in the minority so I don’t know but all the CRUD type services are pretty ergonomic when you realize YAGNI when it comes to those extra abstractions. Edit: also f** one liners. Make it 2 or three lines. It’s ok.
kiitos 3y ago
interface{} is a pretty strong code smell.
mseepgood 3y ago
Since the advent of generics I rarely ever use `interface{}`.
devjab 3y ago
If I asked you to carve wood, would you prefer a carving knife or a Victorinox multipurpose tool? I get that it’s a bit or a cheesy analogy, but it’s basically why I liked Go. To me it’s the language that Python would have been if Python hasn’t been designed so long a go and is now caught in its myriad of opinions. Because I certainly get why you wouldn’t like an opinionated language, I really do. It’s just that after more than a decade, often spent cleaning up code for businesses that needed something to work better, I’ve really come to appreciate it when things are very simple and maintainable, and Go does that. Similarly I’m not sure you would like working with Typescript in my team. Our linter is extremely pedantic, and will sometimes force you to write multiple lines of code for what could probably have been a one liner. Not always, mind you, but for the things we know will cause problems for some new hire down the line. (Or for yourself if you’re like me and can’t remember what you ate for breakfast). The smaller the responsibility, the less abstraction and the cleaner your code the easier it’ll be to do something with in 6+ months. Now, our linter is a total fascist, but it’s a group effort. We each contribute and we alter it to make it make sense for us as a team, and that’s frankly great. It’s nice that the ability to do this, and the ability to build in-house packages, is so easy in the Node ecosystem, but it’s still a lot of work that Go basically does for you. So the zen is in relinquishing your freedom to architect the “linguistics” of your code and simply work on what really matters. I’ve never used Interface{}.

by rcv 3y ago

badrequest 3y ago

I write Go every day, and can count the number of times per year I have to involve an `interface{}` literal on one hand. Unless you're doing JSON wrong or working with an API that simply doesn't care about returning consistently structured data, I can't fathom why you'd be using it "all over the place."

coffeebeqn 3y ago
Me too. We have around a dozen go services and I have maybe used or seen interface{} once or twice for a hack. Especially after generics. I think the parent comment is suffering from poor quality go code. It’s like complaining about typescript because things in your codebase don’t have types
- xarope 3y ago
  Dealing with databases and data scanning into custom structs, you would be writing lots Scanner/Valuer custom functions which use interface{} If you are the lucky ones not dealing with databases, I sort-of envy you...!
  - kiitos 3y ago
    Applications should basically never need to write custom Scanner/Valuer functions that deal in interface{}, if you find yourself doing that it's a red flag
  - badrequest 3y ago
    I use sqlc and it makes this a non-issue.

Spiwux 3y ago

You discovered the Zen of Go. There are no magic one liners. It's boring, explicit and procedural. Proponents argue that this forced simplicity enhances productivity on a larger organisational scale when you take things such as onboarding into account. I'm not sure if that is true. I also think a senior Python / Java / etc resource is going to be more productive than a senior Go resource.

goatlover 3y ago
Go seems like the antithesis to Lisp.
pharmakom 3y ago
... so the code ends up being really long then.
- Spiwux 3y ago
  Yes, pretty much. It's a pain to write, but easy to read. On a larger scale the average engineer likely spends more time reading code than writing code
  - tuetuopay 3y ago
    I don't find go that easy to read. It is so verbose that the actual business logic ends up buried in a lot of boilerplate code. Maybe I'm bad at reading code, but it ends up being a lot of text to read for very little information. Like a one-line list comprehension to transform a collection is suddenly four lines of go: allocation, loop iteration, and append (don't even start me on the append function). I don't care about those housekeeping details. Let me read the business logic.
    - kiitos 3y ago
      Go offers a programming interface at a lower level of abstraction than languages like Python or Ruby. What you call boilerplate or housekeeping, I consider to be mechanical sympathy. Modulo extremes like Java, the bottleneck for programmers understanding code is about semantics, not syntax -- effectively never the literal SLoC in source files. It's not as if for i := range x { x[i] = fn(x[i]) } is any slower to read, or more difficult to parse, or whatever, than e.g. x.transform(fn) in any meaningful sense.

gtowey 3y ago

Go is the language that's not made for you, it's made to make the life of the next guy who has to maintain your code easier! :-)

Cthulhu_ 3y ago
That's a great way to phrase it, I'm going to steal that :D
za3faran 3y ago
It's harder to maintain compared to similar logic written in Java or C#.
neonsunset 3y ago
This is partially correct. It is made to solve internal Google's politics and the hubris of yet another graudate with a CS degree and an itch to justify hours he or she invested in practicing Leetcode (which, in turns, is a skill of writing mediocre stdlib code for languages that have inadequate stdlib)

vineyardmike 3y ago

One of the big things that I’ve found helped is to “stop being an architect”. Basically defer abstraction more. People, esp from a Java-esque class based world want class inheritance and generics and all that jazz. I’ve found at work like 50% of methods and logic that has some sort of generic/superclass/OOP style abstraction feature only ever has 1 implemented type. Just use that type and when the second one shows up… then try to make some sort of abstraction. For context, I can’t remember the last time that I actually used “interface{}”. Actual interfaces are cheap in go, so you can define the interface at use-time and pretty cheaply add the methods (or a wrapper) if needed. If you’re actually doing abstract algorithms and stuff every day at work… you’re in the minority so I don’t know but all the CRUD type services are pretty ergonomic when you realize YAGNI when it comes to those extra abstractions. Edit: also f** one liners. Make it 2 or three lines. It’s ok.

kiitos 3y ago

interface{} is a pretty strong code smell.

mseepgood 3y ago

Since the advent of generics I rarely ever use `interface{}`.

devjab 3y ago

If I asked you to carve wood, would you prefer a carving knife or a Victorinox multipurpose tool? I get that it’s a bit or a cheesy analogy, but it’s basically why I liked Go. To me it’s the language that Python would have been if Python hasn’t been designed so long a go and is now caught in its myriad of opinions. Because I certainly get why you wouldn’t like an opinionated language, I really do. It’s just that after more than a decade, often spent cleaning up code for businesses that needed something to work better, I’ve really come to appreciate it when things are very simple and maintainable, and Go does that. Similarly I’m not sure you would like working with Typescript in my team. Our linter is extremely pedantic, and will sometimes force you to write multiple lines of code for what could probably have been a one liner. Not always, mind you, but for the things we know will cause problems for some new hire down the line. (Or for yourself if you’re like me and can’t remember what you ate for breakfast). The smaller the responsibility, the less abstraction and the cleaner your code the easier it’ll be to do something with in 6+ months. Now, our linter is a total fascist, but it’s a group effort. We each contribute and we alter it to make it make sense for us as a team, and that’s frankly great. It’s nice that the ability to do this, and the ability to build in-house packages, is so easy in the Node ecosystem, but it’s still a lot of work that Go basically does for you. So the zen is in relinquishing your freedom to architect the “linguistics” of your code and simply work on what really matters. I’ve never used Interface{}.