4 ms·

Go thinks that having a simple language, one way to do a thing, standard formatting, low boilerplate, and coupling minimised using interfaces and explicit expor

Go thinks that having a simple language, one way to do a thing, standard formatting, low boilerplate, and coupling minimised using interfaces and explicit exports all adds up to maintainability. Time will tell if it's right.

stouset 5y ago
Two of those in particular are what the overwhelming majority of detractors find issue with. A “simple” language frequently offloads more work onto its users. In my experience with golang, this is true. Meaningful abstraction is punished or impossible, so every solution to every problem—no matter how many times it’s been solved before—becomes a computer science exercise where every detail has to be dealt with and remains on full display. Reading golang is a chore because you can’t zoom out and look at the high-level flow, it’s only low-level minutiae at every level of the code. It’d be like an architect having to write the molecular layout of a skyscraper into the blueprints. Chemical formulae everywhere but no picture of walls, floors, or a building anywhere to be found. Second, claiming golang has “low boilerplate” is the programming language equivalent of Stockholm syndrome. Look up any popular project. Something like fifty percent is if res, err := func(…); err != nil { return nil, fmt.Errorf(“Look ma, I’m a human exception handler: %w”, err) } That’s not an exaggeration. 50% seems to be the trend from the projects I’ve sampled. It actually makes it frustratingly difficult to follow what a function is supposed to do because the logic is lost in a sea of nearly-identical error handling. Spotting a bug in one stanza of code that’s in a sequence of nearly-identical visual blocks is hard because your brain starts glossing over the details that are repeated.
- Seb-C 5y ago
  I wish there was a standard one-liner pattern to handle errors, that would improve it a bit visually. Go has a LOT of boilerplate. And that is why I love it. No magic. No implicit behavior. No weird stuff that will bite me if I don't know that something in a completely unrelated file is changing the behavior of my code. It allows me to write high quality code and care about all the millions of details I should be thinking about. Yes, 50% of go code is about handling specific cases and errors. And that's a good thing, because unexpected cases and error handling is 50% of the work that a developer should be doing. But often it is just neglected or difficult to spot in other languages (until it bites you).
  - JulianMorrison 5y ago
    I guess I should explain why I think Go has low boilerplate. It does have "explicit everything" and I love that too. Also no "spooky action at a distance", like redefined operators. Things do what they say and say what they mean. What it doesn't have is a lot of noise basically intended to keep the compiler happy, or implement common indirection patterns. Types are generally simple and can often be omitted. It's not traditional OO, so a lot of needless abstraction can be skipped. Complying with interfaces just means providing the required methods. Go code compared with the equivalent C or Java is denser. For what it's worth there was an attempt at improving errors, which would have added a keyword that means "do this, or if it fails return the error result in this function's error result". I liked that idea. I'm not sure why it wasn't well received, but they evidently have that on their to-do list.

stouset 5y ago

Two of those in particular are what the overwhelming majority of detractors find issue with. A “simple” language frequently offloads more work onto its users. In my experience with golang, this is true. Meaningful abstraction is punished or impossible, so every solution to every problem—no matter how many times it’s been solved before—becomes a computer science exercise where every detail has to be dealt with and remains on full display. Reading golang is a chore because you can’t zoom out and look at the high-level flow, it’s only low-level minutiae at every level of the code. It’d be like an architect having to write the molecular layout of a skyscraper into the blueprints. Chemical formulae everywhere but no picture of walls, floors, or a building anywhere to be found. Second, claiming golang has “low boilerplate” is the programming language equivalent of Stockholm syndrome. Look up any popular project. Something like fifty percent is if res, err := func(…); err != nil { return nil, fmt.Errorf(“Look ma, I’m a human exception handler: %w”, err) } That’s not an exaggeration. 50% seems to be the trend from the projects I’ve sampled. It actually makes it frustratingly difficult to follow what a function is supposed to do because the logic is lost in a sea of nearly-identical error handling. Spotting a bug in one stanza of code that’s in a sequence of nearly-identical visual blocks is hard because your brain starts glossing over the details that are repeated.

Seb-C 5y ago
I wish there was a standard one-liner pattern to handle errors, that would improve it a bit visually. Go has a LOT of boilerplate. And that is why I love it. No magic. No implicit behavior. No weird stuff that will bite me if I don't know that something in a completely unrelated file is changing the behavior of my code. It allows me to write high quality code and care about all the millions of details I should be thinking about. Yes, 50% of go code is about handling specific cases and errors. And that's a good thing, because unexpected cases and error handling is 50% of the work that a developer should be doing. But often it is just neglected or difficult to spot in other languages (until it bites you).
- JulianMorrison 5y ago
  I guess I should explain why I think Go has low boilerplate. It does have "explicit everything" and I love that too. Also no "spooky action at a distance", like redefined operators. Things do what they say and say what they mean. What it doesn't have is a lot of noise basically intended to keep the compiler happy, or implement common indirection patterns. Types are generally simple and can often be omitted. It's not traditional OO, so a lot of needless abstraction can be skipped. Complying with interfaces just means providing the required methods. Go code compared with the equivalent C or Java is denser. For what it's worth there was an attempt at improving errors, which would have added a keyword that means "do this, or if it fails return the error result in this function's error result". I liked that idea. I'm not sure why it wasn't well received, but they evidently have that on their to-do list.