You smile in delighted satisfaction, knowing that the compiler will protect you and your team against this all too common form of bit rot — a protection that, until now, had to be enforced merely by convention and review.
It is enforced by linters and almost all IDEs. Compare to how how the following golang code drops errors silently, and is not caught by the compiler:
foo, err := getFoo()
err = processFoo(foo)
if err != nil { ... }The one which is purely aesthetic, has no actual relevance, and can trivially be checked for if you want to?
> a protection that, until now, had to be enforced merely by convention and review.
`-Werror -Wunused` is not a convention in any sense of the term.
It might be a good idea to add it to your build bot though, this way you can enforce it for commited code. That's a good compromise IMO.
after all there's no way to ignore unused variables with a compiler option
Enforcing that unused variable rule (and, in some sense the standardized code layout), for me, is sort-of assuming all code that gets compiled will be deployed at scale in a mission-critical context.
A language that also wants to cater to hobbyists should, IMO, be a bit more liberal in what it accepts, and provide flags to enforce additional rules for those who know they need them.
(I also think go could go further in enforcing quality. Code that does in, err := os.Open(path), where in doesn’t escape, should call defer(in.Close). The compiler could enforce that)
Other than the claims they put up on their blogs and presentations, what hard evidence do we have that this is actually the case ? Java and C# are much more suited for "programming in the large" than golang.
> Java and C# are much more suited for "programming in the large" than golang.
I don't agree. One point would be Go's faster compile times.
> One point would be Go's faster compile times
I'm looking for more substantive points, as frankly, this doesn't cut it. I just posted this in a different comment on this thread:
> Not much faster than C# or Java in practice, especially when using a build system that caches your build so you don't have to rebuild everything every time. The difference actually gets smaller the larger the program is. Furthermore, it's (unit/functional/integration) tests that usually take the longer time to run anyway, which you have to execute before submitting your diffs (and caching helps there as well).
I worked at an employer that heavily uses golang, and I'll tell you that build times for actual large scale projects (pulling many dependencies) were not much better (if at all) than Java's.
Either we're talking past each other or you're being deliberately obtuse.
The claim is that Go was designed to be a language in service to software engineering, for programming in the large. The evidence for this claim is that the designers claim it, that's totally sufficient. The fact that your experience of the language doesn't sync with this claim is irrelevant, because it has no bearing on the design of the thing. If you want to claim that the designers have failed at this goal, that's a totally separate argument.
My argument is exactly that, their claim is unsubstantiated, and people's experiences in practice contradict their claims. Not to mention that some of their design decisions are objectively bad, and go against their claim in the first place: https://github.com/golang/go/issues/16474
> Not to mention that some of their design decisions are objectively bad
Oh, you're just grinding axes. I'm sorry for engaging.
You can argue about whether they really failed or not, but your pedantic take on it wasn't helpful for a discussion.
My experience is radically different; I don't believe you.
The proper design would fail with an error, unless you added a switch to warn instead.
Therefore, fail for error is acceptable for internal development, but not for released code.
If i release a project, i would not want users to fail to compile it just because they have a slightly different compiler version.
When I use an external library in my project, a part of me dies inside if I see a stream of warnings. So I understand where Pike, Thompson et al are coming from. They're just misguided in their approach.
The trouble with C is that there's no "official" compiler like modern languages have, so there's no consensus on what merits a warning or not (and the spec is so terrible that you'd have a hard time coming up with them anyway). But for modern languages, you have a clean slate to work from, which means that we have an opportunity to do it right this time.
For every Virtue, there are multiple interpretations. What's simple footwear: flip-flops, Birkenstocks, or Redwings? 5 Fingers?
Criticize as much as you want, but stay civil.
He said Go is garbage, he didn't say anything of the people who write or work in Go.
Go isn't an entity here that can be offended. It's a programming language.
Same with things you spent a lot of time building.
Now if OP would have said "use case X in Go is absolutely garbage because of Z", it would have been better received. But he didn't.
Because, you see, insulting, insulting anything really, is removing space for debating, sharing ideas and advancing arguments. It's the same reason this site asks for not posting things like "+1", "first" or memes.
And it's why, being carried away by the definitive and aggressive generalization of "Go is garbage", OP closed the door for a proper discussion. The opposite of the goal of Hacker News.
Some medium are a fine place for this, mind you. I enjoy being trolled on IRC, for once, being a child of the eighties. Imgur makes for fun memes. 4chan is great to make fun of pretty much everything. And twitter is big enough that you can find an audience to bash any kind of programing language for therapeutic reason. I did that with JS for some years. Very relaxing.
But HN is definitely not the place for this.
None of those people have actually written any Go professionally.
Now breaking social convention and being aggressive has its use. But it's only fair to be called out.
I'm not a rust fanboy, but I wonder why people have the assumption that programming should _not_ be elitist. Where did we get the idea that programming should not be a skilled trade, but rather something the everyman can do?
> without foot guns rather then amazing with dragons all over.
Ironically, Rust and Clojure have less "footguns" if we're talking about concurrency and parallelism.
https://changelog.com/gotime/105
https://archive.fosdem.org/2019/schedule/event/kubernetesclu...
I'm not saying Go programmed products are lower quality, just that we've enabled certain types of organizations with the advent of greater process and rigor in languages. Someday the pendulum will likely swing again.
I've met plenty of good developers that complain at how Go ties their hands and creativity. Unsurprisingly, the language has been designed for "cogs":
---
The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike
---
I personally would want a warning but I believe computers should do what we want them to rather than we should do what they want us to.
You see, even if this is the right choice, the way it's carried out is douchey, and so I perfectly understand somebody calling it garbage to express a sentiment.
Why not pick a tool that's specialized for stuff like that, like a style checker. Put it into the build pipeline and let the build fail if the code doesn't adhere to your standards.
Importantly, there are a number of almost certain bugs the Go compiler is happy to let through without even a warning.
Like not rebinding the result of append(), or not checking the error returned by a function.
I have been working with Go for five years, and the fact that I'm forced to use all variables I define means I write simpler code. The only instance that I find I waste time is when I want to access a variable that I otherwise don't need to quickly print it when debugging something. Still, this is usually a minor issue and it's a great tradeoff. I wish more languages enforced such rule.