Please don't post in the flamewar style to HN. We're trying for better than that here, especially after having seen how programming language flamewars destroyed other communities.
> When you can't compile because of one unused variable that was commented out . . .
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.
I don't want to be warned, I want to be stopped, and, more importantly, I want everyone else to be stopped, too, unconditionally. -Wxxx doesn't get me there.
For a little while I used to compile with -Werror but I found it very annoying. I very often want to make a quick test commenting out a function call or doing an early return that would trigger a warning for dead code and prevent me from continuing.
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.
You use linters to catch those issues (and more). Any quality project will have linters, CI/CD etc. set up. And it's not like golang obviates the need for linters, if anything, it needs them more than other languages to deal with several issues, including (ironically) accidentally ignoring handling errors.
Is ignoring errors really a problem in practice? I’ve been using this language since before 1.0 and I don’t think I’ve ever been burned by this. I’m sure it happens once in a while (albeit at very low frequency), but people in this thread act like you can’t build software in Go because the compiler doesn’t catch every ignored error.
There’s a huge difference between baking a cake for your kids and running a cake factory.
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)
> Go is primarily a language for programming in the large
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.
I'm speaking about the language's principles of design, not its market efficacy. For this, there is no higher standard of evidence than the claims of the designers.
> 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.
The standard of evidence is what I see when I use the language at work. And so far, I don't see much that validates the golang designers' claims to be honest.
> 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.
> The standard of evidence is what I see when I use the language at work. And so far, I don't see much that validates the golang designers' claims to be honest.
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.
> The evidence for this claim is that the designers claim it, that's totally sufficient
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
If I say I designed X with principal Y in mind, that claim cannot be contradicted or considered unsubstantiated by other people's experience of using X. It's a statement of intent, not of consequence.
> Not to mention that some of their design decisions are objectively bad
Oh, you're just grinding axes. I'm sorry for engaging.
I'd say you weren't exactly engaging in good faith, either. It's pretty clear that their point could be summarised as something like: Go's designers tried or intended to design the language for programming in the large, but they failed (perhaps partially), so therefore Go isn't (after the fact) designed for programming in the large.
You can argue about whether they really failed or not, but your pedantic take on it wasn't helpful for a discussion.
That does not work, because warning are generally based on heuristics, may have false positives, and are not consistent between different implementations and versions of compilers.
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.
Actually, it does work, because languages tend to provide ways to notify the compiler that what you're doing doesn't warrant a warning. I've worked on big C codebases, some of which I built and some of which I inherited, and I was always able to get it to the point where it would compile with -Werror -Wall -Wextra etc, many times even -pedantic, with very few (if any) pragmas. The only exception to this was compiling for MSVC, which is no surprise since they don't really care about C.
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.
Practically any large scale project is going to have linters involved at some point. This seems to be a much better suited task for the linter to catch than to be set at the compiler level, since it severely hinders programming locally.
If I insult your mom, I don't insult you, yet you feel insulted.
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.
HN has become a cesspool for certain topics in recent years. Go threads being the worst; all the ego's seem to come out of the woodwork. I almost never bother reading the comments on anything Go related these days because it's just full of wannabe 10x programmers overstating academic edge cases as if no other language in history has ever had a shortcoming.
Yep, they construct a strawman argument about some niche edge case where Go was outperformed by some language. Or come up with some contrived examples where Go would Absolutely Need Generics.
None of those people have actually written any Go professionally.
I agree that calling a very successful language "garbage" is a childish move. I also think that we shouldn't tie our egos to the tools we are using. Nothing good arises from that.
Sure, but most people do. And it's a social convention that we do. If you know the social convention and you still choose to break it, you are willingly being aggressive.
Now breaking social convention and being aggressive has its use. But it's only fair to be called out.
A language that young professionals can use right away and can even support complex projects like kubernetes, Prometheus, consul etc. sounds like an excellent choice for companies to adopt. It might not be as elitist as rust or clojure but if collaboration is important for your project I'd rather have simple without foot guns rather then amazing with dragons all over.
> It might not be as elitist as rust or clojure but if collaboration is important for your project I'd rather have simple
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.
It’s a good aspiration to eliminate needless complexity from a language so people can spend their cognitive resources (be they great or few) on solving real problems. If you can lower the barrier such that a layman can do it, then a genius specialist can do that much more.
The problems don't go away. If the language refuses to handle them and refuses extensibility, every end user now needs to handle those problems without standard tools.
This hasn’t been my experience. I’ve been involved in the language and community for nearly a decade and I’ve never seen an incident where the grievances against the language weren’t seriously overblown. The most credible one has been dependency management. There’s still plenty of room for improvement of course, but the idea that Go’s flaws make it anything short of one of the most productive languages is generally nonsense.
Also, go is an elitist language as well, in its own way. Its creators and many of the first proponets were big Unix/C/Bell Labs names. Quite opinionated people.
I think that has more to do with the fact the k8s devs had a complete implementation of the the same product (Google's Borg) as reference. Mesos/Marathon only had a couple 10 page journal articles to look at and a ton of on the ground decisions to make and quantify the choices of.
I’ve heard the statements that the Go stdlib and Kubernetes are not good examples of Go code, but I’ve never seen someone say that it’s not a good use case for Go. Would you mind elaborating on that assessment?
There's a real analogy to be made here with mass production and it's impact on labor. We quickly went from a society that valued individual craftsmanship to one that valued the ability to treat people like cogs at the factory. I'm not even mad, mass production is a great thing that enabled access to goods that many people would never have otherwise had. But eventually there was a backlash, and handcrafted, high quality goods are preferred by many who can afford them.
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'm not saying Go programmed products are lower quality
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 also think that (unused variable) is an annoying feature. It's good that a compiler can warn about it but it should be optional. It can always be made a mandatory setting in a build pipeline or something.
It's not the computer wanting you to do this, it's the collective arrogance and pedantry of Google designers wanting you to do this. Therein lies the rub. When the compiler detects the unused variable, it doesn't warn you, nor does it remove the variable as it knows exactly how, but one-ups you to force your hand.
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.
You cannot remove an unused variable, you just dont refer to a stack place or register with it. Removing a variable would modify your source code. The compiler can only make you do it by pretending it refuses to understand it.
Why does it have to be the compiler? The thing about unused variables seems quite arbitrary to me. There are also other things the Go compiler doesn't enforce.
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.
If you are worried about wasting time with not being able to compile due to unused variables, chances are you're doing something wrong like creating long functions.
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.
The unused variable thing bothered me enough that I modified the complier to add the -warnunused flag. It's fine to nag for this, but not to block the dev cycle.
