A Farewell to Go
churchwood.at
churchwood.at
As someone who has wasted many hours debating which JavaScript style guide to follow I disagree with this. Go have quite frankly put to bed any debates or arguments over "curly brace on same line or below" by setting a style and having it policed by the compiler. When working in a team it's good to have an official style guide that's enforced, in the long run this is a good thing.
I don't think this was done because Go's developers are opinionated, I think they looked at other languages and seen the mess that can happen when you don't set a style guide and thought "we're not doing that"
> For example placing an opening curly bracket on a new line causes the compiler to emit a syntax error.
That's actually part of the syntax, not the style. The compiler adds an implicit semicolon at the end of every line, and if there is one before the block of a switch, if, for, etc, then it looks like it's missing (and the next line's curly braces is just a new block.
The author has obviously not tried to maintain a project where each contributor has his own coding style.
Fine if you work on your own. But if you work in a team, whose style do you use? I much prefer Go's "stop wasting time on things that don't matter and just use this style" approach.
Please no. Never. moving to enforced styles freed me from having to think and debate about them. I think go set a precedent here that every new language should follow.
I think people underestimate the enormous cost of custom. Once style can be customized it opens up a whole universe of costs: compatibility, learning curve, project onboarding, tooling complexity. These are hours upon hours of human lives that just vanish into the abyss of pointlessness. Not just during the a style debate itself, but the mental energy it consumes at all times when "you know this specific situation would look nicer if we just made this one tweak to the style" is a possibility.
The standardized style is one of the best things about Go and one of the things I miss the most when working in other languages.
The usual thing to say at this point would be "To be fair there are some things I don't like about Go format, but the social benefit is worth it" but I've moved past even that. At this point I don't even give a shit about style. As long as it has something reasonable and it does it automatically. And before you write me off as never caring, I used to be that person that spends hours aligning things until they look just right, adjusting spaces to align mid-line, debating on brace & bracket placement. But it's all garbage now. Just make it good enough to read and get it out of my way.
I don't like playing Microsoft Word layout games in my text editor anymore.
> According to my opinion, a programming language should let a developer use his or her style. A heavy influence on the programmer’s style is okay, but a fanactic, religious-like enforcement is inacceptable.
I believe the OP exhibits a fanatic, religious-like enforcement of how he wants to format his code. If he would use gofmt, he would not have this issue:
> For example placing an opening curly bracket on a new line causes the compiler to emit a syntax error.
Because gofmt will fix it for him.
> The same goes for string concetanations that start on a new line.
Not even sure what OP means here. There are both the `` string escaping for multiple lines, and you can perfectly fine split up expressions over multiple lines, like so:
s := "aaa" +
"bbb"
Way to go, cowboy.
> Broken Package Management
See gb, govendor, glider etc. Many languages can be critized for the same, but there are solutions. Use them.
> A possible mitigation strategy is shown by the Kubernetes project whose creatores store their application’s dependencies in their repository. However, this is an anti pattern of using a VCS.
No, this is not an anti-pattern, it is a perfectly valid solution to vendoring dependencies.
> No Inheritance, Missing Generics
Please learn the language better.
> Feature-Lacking HTTP Library
So, use one of the many http libraries around that suits your need better. How many languages even ship a http library in std lib?
> No, this is not an anti-pattern, it is a perfectly valid solution to vendoring dependencies.
I'm not going t to tell you it won't work, because it will, but this very rarely done, particularly if you use a DCVS like git. When's last time you saw a Java Maven project do this. Almost never. Why? Because there is a very standard, robust way to vendor dependencies.
> Please learn the language better.
How is learning go better going to help you make a useable skiplist? What non-novice wisdom would help out?
`if err == nil` (am I right!?)
Importing Gorilla really doesn't seem like it should be a deal breaker however I understand why someone fond of Python would lament not having everything built into the language ;).