> 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.
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.
> According to my opinion, a programming language should let a developer use his or her 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.
I am going to chime in and second the team argument here. Being stubborn on style tells me a person is going to be inflexible on a myriad of other things as well.
> According to my opinion, a programming language should let a developer use his or her style.
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"
> the linter displayed so many warnings due to my code style, that I turned it off.
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?
You have good point. I take issue with only a couple.
> 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?
I'm curious about what the author chose instead. Sadly, it is not mentioned in the post (maybe for the better - it'd lead to an inevitable flamewar about Go vs whatever his new choice is).
Package Management and Generics are the two big ones that I agree with here. Inheritance, when used correctly, is really useful but is too often abused and for that reason alone I cool with it's omission. I'd add that the error handling, while readable, feels a little clunky when I'm writing it.
`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 ;).
Most of the arguments against seem like either personal-taste things or something that will or at least can be fixed in one of the next releases (maybe except inheritance).
It might be personal taste, but I'd prefer a language incorporating innovations from the 1980's onwards. I doubt that will be fixed in the next release.
I agree only on the generics thing. The package management is out-of-scope for me. However rudiments of genericity should be there. I do not aim for the full thing.
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"