I think the reason you have those kinds of holy wars among users of a particular technology, whether it's an OS or a gaming console or a programming language, is network effects.<p>All of those things are more valuable the more people that use them, and if you've invested money or time into any of them, you have more of a pay off on your investment if more people also use them. So you might feel strongly incentivized to defend your platform of choice while attacking competing platforms, even if another platform might be marginally better, but not enough to justify the switching costs.<p>If you're a language developer, you have dual incentives-- one is to get people to use your language, which would seem to encourage you to engage in holy wars, but the other is to <i>be good at developing languages</i> which requires you to think objectively about what you and other language developers are doing, so even if you're publicly defending your choices, you should be open to the idea that another way might be better.
Language designers are indeed often un-dogmatic about the language. The tool builders in Go however have built a very structured distinct practice of using Go that forces one to remain in dogma. Go is rather unique in how much Go-tooling-specific tooling knowledge one has to have to even begin writing code, owing to it's deeply inbuilt sense of workspaces (GOPATHs) and it's strict directory structure.<p>I really think this is a great post, and emphasizes a strong danger in adopter culture. But I do also think Go, in particular, is rigorously dogmatic <i>in it's tooling.</i> To good effect, in that anyone can come to any project and understand some basics, but the workspace decision is really hard to reconcile with the project-by-project view of the world that most language tooling assumes.
There are a lot of decisions in Go that I find very distasteful. It's frustrating because Go comes very close to being something I'd want to use, but falls short in all areas.<p>It has this great automatic interface system! Amazing! Except it also has "primitive" types that can't participate, so many of my functions have to take interface{} instead which is pretty much void*.<p>It can dispatch to different functions based on the argument types! It will even automatically switch to the non-pointer type if you pass a pointer to a non-pointer function. However, you can't write a pointer and non-pointer version of the same function. Also why are we using pointers to represent reference mutability and optionality these days? Other languages have maybe/option which handles optionality much better.<p>Speaking of not having maybe/option, every other line of code is "if (err == nil)" and there's no way to abstract this out. Give me `option` dammit. Exception handling exists via panic, but it's a little different than you're used to and the language designers like to pretend it's not exception handling at all.<p>There are built-in functions that use generics, but I'm not allowed to write one? Hypocrites.<p>You have to name things starting with a capital letter to make them public. Who came up with this convention? It is not shared by any language ever. It also gets extremely annoying when you want to serialize json, serialize a protocol buffer, or do a database query. Name your struct members in lowercase and those libraries won't be able to see them, but name them in uppercase and the output will be in the wrong case. Instead, you have to "annotate" those struct fields repeatedly for every library you're going to pass them to. You also have to manage "naming convention" systems that translate between the two names, and these conventions are never the same between two libraries.
I completely agree with the author, though slightly surprised to see it come from the Go community, which has seemed like one of the more dogmatic languages. (E.g. all the "you don't need generics" arguments over the years.)
I think the Go team probably wanted to avoid the mess that C++ has become, which to some extent has affected Scala as well. When a language tries to be all things to all people, it becomes cluttered and inconsistent. It can also become incompatible with previous versions in ways that prevent people from upgrading, as we have seen with Python 3.<p>However, the Go team has gone further than most in their rejection of changes, and I think it's reached the point where it hurts the adoption of the language. When I write Go code, I feel like Rob Pike is standing behind me telling me to do things the way he likes them done, or not at all.<p>There are plenty of examples of languages that have navigated this problem better than Go. Rust and Haskell come to mind immediately. C# and F# should also get more credit than they do for handling this kind of thing gracefully. Even Java 8 has incorporated many of the things people found attractive about Scala, without making them mandatory or alienating established developers.
But this is not how languages are designed and even how Go was designed, where three people had to agree on features, instead of making "engineering trade offs". And this was a decent decision for familiarity and making the language more approachable, even though it was all dogma. The reason is simple: languages follow the same rules as user interfaces in general and as in user interfaces first thing that comes to mind is usually a better choice, than something overthought by a non-professional in UX, because you have it engraved in your brain by your most often previous experience and therefore it's very likely that many people do too. And having multiple people to agree basically supercharges that.<p>But then you still have to follow the rules of the UX, consistency, flexibility, all that, and none of the languages I know of are serious about that. It's all just dogma everywhere, or "engineering trade offs" if you like. We don't have much dogma only when it comes to performance, since it's the only thing easily measurable.
I like generics, but why can't there be a language that doesn't have them?<p>If I want a simple language, no generics I go with Go, for everything else I go with Rust and Swift.<p>Not every language has to have generics, when I want to use them, I simply switch languages.<p>There is something nice about being able to keep Go in your head and I think that it has shown that there is a market for such a language.
This article brings to mind the challenge of enforcing empathy in an engineering community. Software and other technical systems are coldly precise and unambiguous. People, on the other hand, are rarely that precise and often illogical without significant effort/investment into forcing themselves to be rigorous about a though or claim.<p>I think it's too easy for community members to leave opinionated outsiders with a bad taste in their mouth when they approach your system with opinions and tendencies that were built up in other systems with different circumstances and assumptions. The kneejerk response is "well, you're wrong, we don't do it that way here," hence the dogma.<p>It takes serious effort to fight that instinct, and not everyone is good at fighting it... especially when some community members suffer from the same problem as the outsider, but with the affinity being toward their own system. This is a hard problem to solve...<p>It's a good thing this article was written and there is a willingness to at least acknowledge the problem in the Go community. It contrasts to the style of say, Linus Torvalds, whose approach is basically "empathy? fuck that, I'd rather call them names" :-)
This reminds me of Perl's motto:<p><i>There Is More Than One Way To Do It</i>.<p>Regardless of the community, we generally all strive for the most <i>efficient</i> way to accomplish a goal, but the definition of "efficient" can vary: execution performance, elegance, ease of developing, ease of integrating into X... Often, one or a few leading solutions emerge but it's tempting to take those pragmatic optimums and turn them into law—or worse: follow them for the wrong reasons.<p>It's a good idea to know <i>why</i> you're using a particular design tradeoff, and remain flexible to change if you find your constraints have changed. Some environments make this interchangeability easier than others but there's almost always a choice.
><i>(for example both Go and Haskell need some kind of “green threads”, so there are more shared runtime challenges than you might expect)</i><p>That's a very generous definition of similarities, as tons of languages have green threads, even Java/JVM had them initially (and still has them in various implementations over native threads). Could even add that most languages also have GC, some type system, io, modules, etc.
The problem is when we form Groups or Tribes based around something we fall into the trap of just whitelisting or blacklisting things. This is a natural human algorithm to simplify things in our brain and make our decision processes more efficient.<p>A way to fight this is to make sure you belong to more than one language community. Then you'll be forced to not make such a simplified model.
/offtopic<p>"Go" is such a poor name, both for a language and game, because they collide with the English word, it's impossible to perform targeted search or sometimes even to know what an article is about.<p>Some TV shows like "24" suffered from the same fate. On reddit the game of Go is represented by the Korean "baduk", probably to escape the confusion cone.