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.
after all there's no way to ignore unused variables with a compiler option
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.
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.
My experience is radically different; I don't believe you.
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.
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?