30 ms·

Go and Dogma

194 points by zalmoxes 10y ago

bjt 10y ago
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.)
- stanleydrew 10y ago
  The author is implying that most of the "you don't need generics" arguments come from Go's users and not Go's creators. I don't have a good feel for whether that's true of the Go community, or maybe more importantly whether it's relatively more true of the Go community than, e.g., the Python community.
  - zigzigzag 10y ago
    Arguments like "you don't need generics" or "exceptions lead to convoluted code" or "assertions are only used by lazy programmers" came from Go's creators. I too am rather surprised to see Go, Lisp and Haskell cited as languages designed by people who are not dogmatic. This may well be true at the micro-level of decisions like "how do you best compile green threads", but at the higher design levels all three languages are very, very opinionated. I think statement in particular is questionable: Contrast that kind of discussion with the heated arguments or overly zealous statements you sometimes see from users of the same languages. There's a real disconnect, possibly because the users don't have the experience of weighing the arguments on both sides and don't realize how easily a particular decision might have gone the other way. What is this implying? The designers of Go and Haskell never make "overly zealous statements" or "heated arguments"? Isn't the history of Go littered with such arguments, the most famous being that Go is simple because it's designed for Google engineers, who can't handle complex languages? It's definitely true that language communities are often zealous: when library interop is bad they have to be, in order to get an ecosystem of libraries and tools. That's why you see people posting things like "I made a terminal emulator in Rust" to Hacker News but don't see people posting the same for C++ or Java. Those languages have established ecosystems already and need much less evangelism.
    - weberc2 10y ago
      Being opinionated is pragmatic, not dogmatic. No successful carpenter uses a swiss army knife instead of a screw gun.
    - marcosdumay 10y ago
      Don't know about Go, but the one thing you don't see in the Haskell community is zealotry. Being opinionated is not the same as being dogmatic. Haskell developers have a clear position of letting features get in the language as the community pushes for, and the overall guidance is very much open to changes. The one thing you won't hear there is any equivalent of "generics are bad for you, we are not adding them".
      - yarrel 10y ago
        And Monads are like pizza.
        marcosdumay 10y ago
        Donuts. Monads I can grasp, but never got how they are like donuts.
    - rhinoceraptor 10y ago
      Golang also has its own bespoke assembler, with unique syntax: http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/ http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/
    - grey-area 10y ago
      Strong opinions are not dogma as long as they are open to understanding the other options and change (as here). I think he's just trying to say that people should be less tribal and dogmatic about their tools, ,and users should try to understand that language design is about trade offs, not holy war. I think it is unhelpful to lump rsc in with rob pike, they are very different personalities.
  - rhencke 10y ago
    For a year or so, I used to make minor contributions to the Go programming language codebase, back before it hit 1.0. That certainly by no means makes me an expert on it, nor do I claim to be someone of the caliber of Russ Cox or Rob Pike, but I did do a lot of reading on golang-dev and golang-nuts, before the language was settled on 1.0. There were a lot of discussions on generics, and the language authors and contributors were certainly open to ideas and indeed did their own fair share of research. For example, see https://research.swtch.com/generic https://research.swtch.com/generic from 2009. Indeed, the FAQ entry itself on Generics states 'Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do.', and looking at the blame log, that's from 2010 or earlier, and it's stuck to this day. So, from everything I can see, the creators themselves are certainly open to the concept - I don't see any "you don't need generics" coming from that side.
    - stablemap 10y ago
      See also this document by Ian Lance Taylor, which links to his four attempts at generics: https://github.com/golang/proposal/blob/master/design/15292-generics.md https://github.com/golang/proposal/blob/master/design/15292-...
- dmit 10y ago
  If you follow the history of that particular issue, you'll see that the Go team's (official) view has always been that there are tradeoffs involved, and that none of the existing proposals for implementing generics are sufficient improvements over the status quo. Generics are not free, they bring a lot of baggage with them. And I think most people will agree that Go has achieved a lot of success without them, so perhaps most use cases don't require generics after all.
  - coldtea 10y ago
    >If you follow the history of that particular issue, you'll see that the Go team's (official) view has always been that there are tradeoffs involved Only everybody who asks for generics knows that, and still wants them to go through and pay the price. The "we'll only add them when there's a solution with no tradeoffs" is a red-herring, like "we'll add them on a day that doesn't end in -y". >And I think most people will agree that Go has achieved a lot of success without them, so perhaps most use cases don't require generics after all. In the same sense C has achieved quite a lot with buffer overflows, so what's the point in something like Rust?
    - dmit 10y ago
      >Only everybody who asks for generics knows that, and still wants them to go through and pay the price. And those people are outnumbered by people who are comfortable and productive with the current Go implementation. Programming languages are not all placed on a single Bad<---->Good scale. There are many variables involved, and it makes sense to have local maxima like Java, Go, Clojure, C, Haskell, etc.
      - coldtea 10y ago
        >And those people are outnumbered by people who are comfortable and productive with the current Go implementation. The only way to know that would be to be able to compare one implementation with and one without generics. But only one Go implementation exists. Perhaps there's some toy attempt by someone, but not anything that is equal in all other aspects to mainland Go but with Generics on top. Plus, since most of the burden falls on the compiler writers and most of the benefits to end users, it just takes the compiler writers to be "comfortable with the current Go implementation" for this to continue to remain Generic-less.
- zalmoxes 10y ago
  For context here is the author discussing Generics & Go: https://research.swtch.com/generic https://research.swtch.com/generic https://news.ycombinator.com/item?id=9622417 https://news.ycombinator.com/item?id=9622417
- woah 10y ago
  I wonder what the point of railing against a lack of generics is. When I sit down to write Go, I know that I will be writing a lot of simple, yet repetitive code. It's part of the bargain. Still, if you really feel passionately that Go with generics would be frickin' awesome, generics seem like a pretty easy thing to write a preprocessor for. With the great knowledge of programming language design and implementation that most pro-go-generics internet forum posters have, it should be a piece of cake.
  - weberc2 10y ago
    I don't think it's very easy, particularly the error handling paths. Further, `go build` and friends don't support preprocessors. Much ink has been spilled about the difficulties of implementing generics.
  - nemo1618 10y ago
    >generics seem like a pretty easy thing to write a preprocessor for I am basically doing this: https://github.com/lukechampine/ply https://github.com/lukechampine/ply Ply is like Go except you can write things like []int{1,2,3}.filter(even) and it will Just Werk. It's not quite ready yet, but it feels promising. The idea is that Go doesn't really need full support for generics; most people just want a few more higher-order functions available for manipulating slices, maps, and channels.
    - rtegx 10y ago
      Havelang is an attempt to implement full blown generics (among others) for Go, and is getting close to being usable.
      - camus2 10y ago
        http://havelang.org/ http://havelang.org/ It's how C++ started. Unfortunately, that's how it will also end for Go, because of Go designers ignoring the past.
      - nemo1618 10y ago
        Have looks pretty cool, and their project is certainly far more involved than mine (e.g. they have their own lexer/parser). I am excited to see more compile-to-Go languages. The only other one I'm aware of is iGo. That said, I'm curious to know if Have is able to eliminate intermediate structures (deforesting) when chaining together transformations. Haskell performs "stream fusion" to accomplish this, but I'm not aware of how it's done in other languages. Ply does support this optimization, and that's mostly possible because it restricts the generics to a built-in set (rather than allowing the programmer to define their own generic functions). My other goal with Ply is to make it as familiar as possible to Go programmers. It's not so much inventing a new language as it is scratching an itch.
- weberc2 10y ago
  In my experience, the defenses for Go's stance on generics seem to be more nuanced than the criticisms. The Go community seems to agree that generics would be useful at least in some situations, but that many of the criticisms are exaggerated. On the other hand, many of the criticisms of Go amount to "Go is unusable because it lacks generics". YMMV.
  - chimeracoder 10y ago
    > The Go community seems to agree that generics would be useful at least in some situations, but that many of the criticisms are exaggerated The general consensus from the Go developers is probably best summarized as "Generics are useful, but each of the implementation methods we have seen so far have significant tradeoffs, and the benefits are outweighed by the costs of the methods we've seen." Which isn't to say that Go will never see generics, if someone finds the right way to implement them.
    - sanderjd 10y ago
      > "Generics are useful, but each of the implementation methods we have seen so far have significant tradeoffs, and the benefits are outweighed by the costs of the methods we've seen." I think what people tend to disagree with is the last part. There is a lot of leeway in estimating the costs and benefits and people end up with very different estimates.
- cicero 10y ago
  I am not a Go user, but I've been following it from the beginning. What I've observed is that since one of its design principles is simplicity, it left out features that many people think are essential for a modern programming language. This results in a lot of criticism of the language which provokes a defensive reaction that might overstate their position. The truth is that one does not need generics. I've worked for decades in languages that don't have generics. The real question is with current software capabilities and requirements, is the convenience provided by adding generics to Go worth the cost of the added complexity. People clearly disagree, and the language designers decided "no". That's not dogma; that's engineering.
  - camus2 10y ago
    > The truth is that one does not need generics. Sure ,when you can use interface {} AKA void pointers everywhere, you certainly don't need generics /s You need generics if you want to avoid context.Context.Value(interface {})interface {} like API. You need generics if your goal is type safety AT COMPILE TIME. Obviously it's not one of the goals of Go /s ...
    - dmit 10y ago
      Here is an illuminating (to me) post that shows how the Go approach to solving algorithmic problems might be different from other languages (in this case, a generic graph data type + Dijkstra's algorithm): https://groups.google.com/forum/#!msg/golang-nuts/Rj5t1h_ztxI/Fgs6HfLqMHAJ https://groups.google.com/forum/#!msg/golang-nuts/Rj5t1h_ztx... Sure, the final implementation still has a couple instances of interface{}, but they are much more innocuous than your example.
    - randomdata 10y ago
      Out of curiosity, how would you avoid `Context.Value(interface{}) interface{}` with generics? The net/context package was designed to pass request lifetime context throughout your service infrastructure (think microservices), where the values provide metadata from your transport protocol. HTTP headers, if we want to think in terms of HTTP, although obviously there is no specific protocol dependency at this layer. The value may not even be assigned by a Go program, so it seems that runtime validation would be a necessity even with generics. A broken or malicious program upstream could easily inject something into the context that you weren't expecting, or simply not supply the value at all.
- __david__ 10y ago
  I thought the same thing. Try telling the go community that style consistency is overrated and that "go fmt" has some really bad styles in it. As far as I can tell, in that direction, only dogma lies.
  - hodgesrm 10y ago
    I believe this is less dogma than an engineering choice that some conventions are necessary to enable readability, avoid obvious errors (like forgetting braces around conditional logic), and make merges as easy as possible. Within bounds it does not matter what those conventions are so long as everyone uses them. Over time I have come to think this is the only reasonable way to approach coding conventions. Just to be clear, I personally dislike tabs and line-lengths over 80 characters. However, such choices have no bearing on the success or failure of any project I have ever experienced.
    - __david__ 10y ago
      My point is that it's dogmatic for the entire community to use a single style. I've worked on countless different C programs over the years, most with their own unique style, and while I think it's good for a project to use a consistent style, using it across every project seems dumb. Cross-project style consistency doesn't buy us anything reasonable--there's no "engineering" about it. Also, braces around conditional logic isn't what I'm talking about here (since that's not a "go fmt" style choice--that's the language syntax).
      - hodgesrm 10y ago
        This is likely to be controversial but code conventions are like GOTO statements for me--it seems best to adopt baked-in formatting conventions so that it's no longer possible to waste time and energy arguing about them. Also, it avoids the exertion of chasing people who don't do it consistently and mess up merges or ability to see diffs. Finally, it eliminates the bad feelings that result from religious arguments about code formatting. Most project teams have limited resources to come up with a solution that is close enough to correct to make the project pay off. In new technology there also tends to be a small set of technical issues that are hard and that you must get right--nothing else matters that much if you fail on the core. I am pretty heartless about anticipating things like code conventions, security requirements, legal review, etc. and just following the rules or otherwise making them non-issues for the project team in areas where it does not fundamentally alter the outcome. Edit: clarification
- zaphar 10y ago
  The Go core team has been opinionated but not really dogmatic. Their argument has never been that you don't need generics. It has been we don't want to add them in the currently available forms right now and here are the ways you can get around their absence in the meantime.
  - candiodari 10y ago
    And therefore soon we'll get a repeat of the JDK 1.5 generics disaster and many compatibility caveats.
    - zaphar 10y ago
      Or maybe they won't go the generics route and instead you'll get code generation as a first class citizen.
- deleted 10y ago
  [deleted]
empath75 10y ago
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. 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. 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 be good at developing languages 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.
- wrs 10y ago
  I doubt the vast majority of this behavior is at such a strategic or even conscious level. People are just inherently very tribal, and prone to retroactively rationalizing their choices. That's true in every domain, including programming tools.
  - nine_k 10y ago
    Being tribal just aligns well with the platform incentive: the more people use it, the better is return on investment for every participant. The participants are not required to be conscious about this; the evolution will favor them anyway if they are really numerous.
- gumby 10y ago
  > I think the reason you have those kinds of holy wars among users of a particular technology...is network effects. I find the holy wars are usually fueled by "fans" -- people less invested and less knowledgable in the topic. This is true of movies, bands, sports teams, phones, computers and cars. The fact is if you work on the tech you appreciate that there are tradeoffs and know what your overall objective is (so are less likely to argue about things that don't get you there). Musicians tend to get along -- did the Beatles hate the Stones (OK, the Stones released "Let it Bleed"). I doubt Mark Hamill hates Star Trek or Shatner Star Wars. The catholic pope meets with the grand mufti of Jarusalem. Obama and Bush talked a lot in 2008 and 2009. It's like the joke about academia being so cutthroat as the stakes are so small. Holy / Flame wars erupt among those on the periphery at best.
coldtea 10y ago
>(for example both Go and Haskell need some kind of “green threads”, so there are more shared runtime challenges than you might expect) 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.
- szemet 10y ago
  Name a language having a compiler that most similar to Go in the threading domain, e.g.: compiles to machine code have green threads use non-blocking IO in the background have parallel runtime Haskell is the first that comes to my mind. (I guess that Common Lisp is a safe bet too, as it had everything for ages before it was cool;), but I'm not familiar with that domain to be sure) Erlang have everything except machine code compilation. What else? I guess the rest is from the newer, lesser known or experimental languages. So is there anything more popular than Haskell?
  - coldtea 10y ago
    Occam (!= Ocaml) did CSP akin to Go AND static compiling back in the eighties. Various schemes have had both too (Racket, Chicken, etc), and CommonLisp is indeed a safe bet... I think Julia is there too, not sure.
  - pjmlp 10y ago
    Active Oberon, initially developed in 1996. - compiles to machine code, check. A whole operating was written in it, AOS (aka BlueBottle). - have green threads, check. That is where the name Active comes from. It makes use of tasks. - use non-blocking IO in the background, check. Tasks are used everywhere across whole OS. - have parallel runtime, check. The whole OS makes use of parallelism and its compiler, Paco, does compilation of modules in parallel https://en.wikipedia.org/wiki/Active_Oberon https://en.wikipedia.org/wiki/Active_Oberon http://www.ocp.inf.ethz.ch/wiki/Documentation/Front http://www.ocp.inf.ethz.ch/wiki/Documentation/Front http://www.progtools.org/article.php?name=oberon&section=compilers&type=tutorial http://www.progtools.org/article.php?name=oberon&section=com...
cyberpanther 10y ago
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. 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.
visarga 10y ago
/offtopic "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. 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.
- dmit 10y ago
  Agreed, but that is a technical problem that can (and should) be solved. For example, "C" and "C++" are even more unfriendly terms for search engines, yet Google handles them just fine: https://www.google.com/search?q=c+stdlib https://www.google.com/search?q=c+stdlib https://www.google.com/search?q=c%2B%2B+stdlib https://www.google.com/search?q=c%2B%2B+stdlib
  - nagvx 10y ago
    When you feed them unambiguous queries like that, yes. "stdlib" is a very unique word specific to the domain of programming. Things get trickier with terms that have more overlap, and irrelevant results tend to creep further up the page.
    - lttlrck 10y ago
      that ambiguity is hardly limited to program languages.
  - deleted 10y ago
    [deleted]
- nagvx 10y ago
  It's rather strange and ironic, given that Go came from Google, that they used such a search-hostile word. ("Golang" is a lot less problematic, of course. Hell, in an alternate universe, why not "Gol"? Only one more letter, and no serious collisions I can see...)
  - 10y ago
zzzcpan 10y ago
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. 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.
athenot 10y ago
This reminds me of Perl's motto: There Is More Than One Way To Do It. Regardless of the community, we generally all strive for the most efficient 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. It's a good idea to know why 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.
rektide 10y ago
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. 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 in it's tooling. 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.
- stcredzero 10y ago
  Go is rather unique in how much Go-tooling-specific tooling knowledge one has to have to even begin writing code There's not much of that. I think that most people who are put off by that are actually angry that Go didn't affirm their own prejudices.
- rsc 10y ago
  You're right that the two are difficult to reconcile. Even so, one of my goals this year is to try.
tiglionabbit 10y ago
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. 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*. 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. 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. There are built-in functions that use generics, but I'm not allowed to write one? Hypocrites. 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.
- wyager 10y ago
  > It has Structural Typing! Amazing! I wouldn't say Go has structural typing. It has a form of interfaces, which are not the same. Structural typing is when the data members of an object are expressed in its type. For example, `x : {f : t}` is a statement that the object `x` has a member called `f` of type `t`. That is structural typing. On the other hand, what Go has is pretty much the definition of interfaces, where you have constraint types that indicate that anything satisfying the constraint has some functions defined on it.
  - 10y ago
twblalock 10y ago
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. 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. 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.
- hodgesrm 10y ago
  Can you cite some examples of what you mean? I certainly agree on Scala--after trying it out for a while it definitely seemed to me Java was not so bad after all. (Specifically I'm thinking of things like the problems of doing builds of Kafka across different Scala versions. This was a couple years ago so maybe things are better.)
- camus2 10y ago
  > I think the Go team probably wanted to avoid the mess that C++ has become, Ultimately, people will write a Go++ because the language isn't good enough. That's not avoiding C++, that's forcing people to recreate C++ .
  - pjmlp 10y ago
    The solution "go generate" reminds me of the class generating tools that Borland shipped with their C++ compilers, before they added support for templates, back in the MS-DOS days!
AsyncAwait 10y ago
I like generics, but why can't there be a language that doesn't have them? If I want a simple language, no generics I go with Go, for everything else I go with Rust and Swift. Not every language has to have generics, when I want to use them, I simply switch languages. 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.
- camus2 10y ago
  > I like generics, but why can't there be a language that doesn't have them? Python,Ruby and Javascript don't have generics ... because they are dynamically typed. Go has generics, maps and array are container types, you just can't define your own. To say Go has no generics is stupid, it just doesn't allow you to define your own. Instead you can use catch all interface{} everywhere like dynamically typed languages. > Not every language has to have generics, when I want to use them, I simply switch languages. This statement makes no sense at all.
  - AsyncAwait 10y ago
    > Go has generics, maps and array are container types, you just can't define your own. To say Go has no generics is stupid, it just doesn't allow you to define your own. That's usually what is indeed meant by the statement "Go doesn't have generics", maybe it should be "Go doesn't have user-defined generics", but I assume most people can infer that. I really hate the recent trend of having to spell everything out. > This statement makes no sense at all. Can you be more specific? What doesn't make sense at all in saying that when I have a simple problem that is unlikely to benefit greatly from a more sophisticated type system, I reach for Go, otherwise I use a different language?
- candiodari 10y ago
  And for people who don't get a choice, there is introspection and code generation. In Go, both of those options are, firstly a necessity, secondly far more complex than generics and thirdly introduce (more) weird project-specific exceptions to the type system that can't be reasoned about.
ereyes01 10y ago
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. 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. 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... 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" :-)

194 points by zalmoxes 10y ago

bjt 10y ago

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.)

stanleydrew 10y ago
The author is implying that most of the "you don't need generics" arguments come from Go's users and not Go's creators. I don't have a good feel for whether that's true of the Go community, or maybe more importantly whether it's relatively more true of the Go community than, e.g., the Python community.
- zigzigzag 10y ago
  Arguments like "you don't need generics" or "exceptions lead to convoluted code" or "assertions are only used by lazy programmers" came from Go's creators. I too am rather surprised to see Go, Lisp and Haskell cited as languages designed by people who are not dogmatic. This may well be true at the micro-level of decisions like "how do you best compile green threads", but at the higher design levels all three languages are very, very opinionated. I think statement in particular is questionable: Contrast that kind of discussion with the heated arguments or overly zealous statements you sometimes see from users of the same languages. There's a real disconnect, possibly because the users don't have the experience of weighing the arguments on both sides and don't realize how easily a particular decision might have gone the other way. What is this implying? The designers of Go and Haskell never make "overly zealous statements" or "heated arguments"? Isn't the history of Go littered with such arguments, the most famous being that Go is simple because it's designed for Google engineers, who can't handle complex languages? It's definitely true that language communities are often zealous: when library interop is bad they have to be, in order to get an ecosystem of libraries and tools. That's why you see people posting things like "I made a terminal emulator in Rust" to Hacker News but don't see people posting the same for C++ or Java. Those languages have established ecosystems already and need much less evangelism.
  - weberc2 10y ago
    Being opinionated is pragmatic, not dogmatic. No successful carpenter uses a swiss army knife instead of a screw gun.
  - marcosdumay 10y ago
    Don't know about Go, but the one thing you don't see in the Haskell community is zealotry. Being opinionated is not the same as being dogmatic. Haskell developers have a clear position of letting features get in the language as the community pushes for, and the overall guidance is very much open to changes. The one thing you won't hear there is any equivalent of "generics are bad for you, we are not adding them".
    - yarrel 10y ago
      And Monads are like pizza.
      - marcosdumay 10y ago
        Donuts. Monads I can grasp, but never got how they are like donuts.
  - rhinoceraptor 10y ago
    Golang also has its own bespoke assembler, with unique syntax: http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/ http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/
  - grey-area 10y ago
    Strong opinions are not dogma as long as they are open to understanding the other options and change (as here). I think he's just trying to say that people should be less tribal and dogmatic about their tools, ,and users should try to understand that language design is about trade offs, not holy war. I think it is unhelpful to lump rsc in with rob pike, they are very different personalities.
- rhencke 10y ago
  For a year or so, I used to make minor contributions to the Go programming language codebase, back before it hit 1.0. That certainly by no means makes me an expert on it, nor do I claim to be someone of the caliber of Russ Cox or Rob Pike, but I did do a lot of reading on golang-dev and golang-nuts, before the language was settled on 1.0. There were a lot of discussions on generics, and the language authors and contributors were certainly open to ideas and indeed did their own fair share of research. For example, see https://research.swtch.com/generic https://research.swtch.com/generic from 2009. Indeed, the FAQ entry itself on Generics states 'Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do.', and looking at the blame log, that's from 2010 or earlier, and it's stuck to this day. So, from everything I can see, the creators themselves are certainly open to the concept - I don't see any "you don't need generics" coming from that side.
  - stablemap 10y ago
    See also this document by Ian Lance Taylor, which links to his four attempts at generics: https://github.com/golang/proposal/blob/master/design/15292-generics.md https://github.com/golang/proposal/blob/master/design/15292-...
dmit 10y ago
If you follow the history of that particular issue, you'll see that the Go team's (official) view has always been that there are tradeoffs involved, and that none of the existing proposals for implementing generics are sufficient improvements over the status quo. Generics are not free, they bring a lot of baggage with them. And I think most people will agree that Go has achieved a lot of success without them, so perhaps most use cases don't require generics after all.
- coldtea 10y ago
  >If you follow the history of that particular issue, you'll see that the Go team's (official) view has always been that there are tradeoffs involved Only everybody who asks for generics knows that, and still wants them to go through and pay the price. The "we'll only add them when there's a solution with no tradeoffs" is a red-herring, like "we'll add them on a day that doesn't end in -y". >And I think most people will agree that Go has achieved a lot of success without them, so perhaps most use cases don't require generics after all. In the same sense C has achieved quite a lot with buffer overflows, so what's the point in something like Rust?
  - dmit 10y ago
    >Only everybody who asks for generics knows that, and still wants them to go through and pay the price. And those people are outnumbered by people who are comfortable and productive with the current Go implementation. Programming languages are not all placed on a single Bad<---->Good scale. There are many variables involved, and it makes sense to have local maxima like Java, Go, Clojure, C, Haskell, etc.
    - coldtea 10y ago
      >And those people are outnumbered by people who are comfortable and productive with the current Go implementation. The only way to know that would be to be able to compare one implementation with and one without generics. But only one Go implementation exists. Perhaps there's some toy attempt by someone, but not anything that is equal in all other aspects to mainland Go but with Generics on top. Plus, since most of the burden falls on the compiler writers and most of the benefits to end users, it just takes the compiler writers to be "comfortable with the current Go implementation" for this to continue to remain Generic-less.
zalmoxes 10y ago
For context here is the author discussing Generics & Go: https://research.swtch.com/generic https://research.swtch.com/generic https://news.ycombinator.com/item?id=9622417 https://news.ycombinator.com/item?id=9622417
woah 10y ago
I wonder what the point of railing against a lack of generics is. When I sit down to write Go, I know that I will be writing a lot of simple, yet repetitive code. It's part of the bargain. Still, if you really feel passionately that Go with generics would be frickin' awesome, generics seem like a pretty easy thing to write a preprocessor for. With the great knowledge of programming language design and implementation that most pro-go-generics internet forum posters have, it should be a piece of cake.
- weberc2 10y ago
  I don't think it's very easy, particularly the error handling paths. Further, `go build` and friends don't support preprocessors. Much ink has been spilled about the difficulties of implementing generics.
- nemo1618 10y ago
  >generics seem like a pretty easy thing to write a preprocessor for I am basically doing this: https://github.com/lukechampine/ply https://github.com/lukechampine/ply Ply is like Go except you can write things like []int{1,2,3}.filter(even) and it will Just Werk. It's not quite ready yet, but it feels promising. The idea is that Go doesn't really need full support for generics; most people just want a few more higher-order functions available for manipulating slices, maps, and channels.
  - rtegx 10y ago
    Havelang is an attempt to implement full blown generics (among others) for Go, and is getting close to being usable.
    - camus2 10y ago
      http://havelang.org/ http://havelang.org/ It's how C++ started. Unfortunately, that's how it will also end for Go, because of Go designers ignoring the past.
    - nemo1618 10y ago
      Have looks pretty cool, and their project is certainly far more involved than mine (e.g. they have their own lexer/parser). I am excited to see more compile-to-Go languages. The only other one I'm aware of is iGo. That said, I'm curious to know if Have is able to eliminate intermediate structures (deforesting) when chaining together transformations. Haskell performs "stream fusion" to accomplish this, but I'm not aware of how it's done in other languages. Ply does support this optimization, and that's mostly possible because it restricts the generics to a built-in set (rather than allowing the programmer to define their own generic functions). My other goal with Ply is to make it as familiar as possible to Go programmers. It's not so much inventing a new language as it is scratching an itch.
weberc2 10y ago
In my experience, the defenses for Go's stance on generics seem to be more nuanced than the criticisms. The Go community seems to agree that generics would be useful at least in some situations, but that many of the criticisms are exaggerated. On the other hand, many of the criticisms of Go amount to "Go is unusable because it lacks generics". YMMV.
- chimeracoder 10y ago
  > The Go community seems to agree that generics would be useful at least in some situations, but that many of the criticisms are exaggerated The general consensus from the Go developers is probably best summarized as "Generics are useful, but each of the implementation methods we have seen so far have significant tradeoffs, and the benefits are outweighed by the costs of the methods we've seen." Which isn't to say that Go will never see generics, if someone finds the right way to implement them.
  - sanderjd 10y ago
    > "Generics are useful, but each of the implementation methods we have seen so far have significant tradeoffs, and the benefits are outweighed by the costs of the methods we've seen." I think what people tend to disagree with is the last part. There is a lot of leeway in estimating the costs and benefits and people end up with very different estimates.
cicero 10y ago
I am not a Go user, but I've been following it from the beginning. What I've observed is that since one of its design principles is simplicity, it left out features that many people think are essential for a modern programming language. This results in a lot of criticism of the language which provokes a defensive reaction that might overstate their position. The truth is that one does not need generics. I've worked for decades in languages that don't have generics. The real question is with current software capabilities and requirements, is the convenience provided by adding generics to Go worth the cost of the added complexity. People clearly disagree, and the language designers decided "no". That's not dogma; that's engineering.
- camus2 10y ago
  > The truth is that one does not need generics. Sure ,when you can use interface {} AKA void pointers everywhere, you certainly don't need generics /s You need generics if you want to avoid context.Context.Value(interface {})interface {} like API. You need generics if your goal is type safety AT COMPILE TIME. Obviously it's not one of the goals of Go /s ...
  - dmit 10y ago
    Here is an illuminating (to me) post that shows how the Go approach to solving algorithmic problems might be different from other languages (in this case, a generic graph data type + Dijkstra's algorithm): https://groups.google.com/forum/#!msg/golang-nuts/Rj5t1h_ztxI/Fgs6HfLqMHAJ https://groups.google.com/forum/#!msg/golang-nuts/Rj5t1h_ztx... Sure, the final implementation still has a couple instances of interface{}, but they are much more innocuous than your example.
  - randomdata 10y ago
    Out of curiosity, how would you avoid `Context.Value(interface{}) interface{}` with generics? The net/context package was designed to pass request lifetime context throughout your service infrastructure (think microservices), where the values provide metadata from your transport protocol. HTTP headers, if we want to think in terms of HTTP, although obviously there is no specific protocol dependency at this layer. The value may not even be assigned by a Go program, so it seems that runtime validation would be a necessity even with generics. A broken or malicious program upstream could easily inject something into the context that you weren't expecting, or simply not supply the value at all.
__david__ 10y ago
I thought the same thing. Try telling the go community that style consistency is overrated and that "go fmt" has some really bad styles in it. As far as I can tell, in that direction, only dogma lies.
- hodgesrm 10y ago
  I believe this is less dogma than an engineering choice that some conventions are necessary to enable readability, avoid obvious errors (like forgetting braces around conditional logic), and make merges as easy as possible. Within bounds it does not matter what those conventions are so long as everyone uses them. Over time I have come to think this is the only reasonable way to approach coding conventions. Just to be clear, I personally dislike tabs and line-lengths over 80 characters. However, such choices have no bearing on the success or failure of any project I have ever experienced.
  - __david__ 10y ago
    My point is that it's dogmatic for the entire community to use a single style. I've worked on countless different C programs over the years, most with their own unique style, and while I think it's good for a project to use a consistent style, using it across every project seems dumb. Cross-project style consistency doesn't buy us anything reasonable--there's no "engineering" about it. Also, braces around conditional logic isn't what I'm talking about here (since that's not a "go fmt" style choice--that's the language syntax).
    - hodgesrm 10y ago
      This is likely to be controversial but code conventions are like GOTO statements for me--it seems best to adopt baked-in formatting conventions so that it's no longer possible to waste time and energy arguing about them. Also, it avoids the exertion of chasing people who don't do it consistently and mess up merges or ability to see diffs. Finally, it eliminates the bad feelings that result from religious arguments about code formatting. Most project teams have limited resources to come up with a solution that is close enough to correct to make the project pay off. In new technology there also tends to be a small set of technical issues that are hard and that you must get right--nothing else matters that much if you fail on the core. I am pretty heartless about anticipating things like code conventions, security requirements, legal review, etc. and just following the rules or otherwise making them non-issues for the project team in areas where it does not fundamentally alter the outcome. Edit: clarification
zaphar 10y ago
The Go core team has been opinionated but not really dogmatic. Their argument has never been that you don't need generics. It has been we don't want to add them in the currently available forms right now and here are the ways you can get around their absence in the meantime.
- candiodari 10y ago
  And therefore soon we'll get a repeat of the JDK 1.5 generics disaster and many compatibility caveats.
  - zaphar 10y ago
    Or maybe they won't go the generics route and instead you'll get code generation as a first class citizen.
deleted 10y ago
[deleted]

empath75 10y ago

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. 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. 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 be good at developing languages 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.

wrs 10y ago
I doubt the vast majority of this behavior is at such a strategic or even conscious level. People are just inherently very tribal, and prone to retroactively rationalizing their choices. That's true in every domain, including programming tools.
- nine_k 10y ago
  Being tribal just aligns well with the platform incentive: the more people use it, the better is return on investment for every participant. The participants are not required to be conscious about this; the evolution will favor them anyway if they are really numerous.
gumby 10y ago
> I think the reason you have those kinds of holy wars among users of a particular technology...is network effects. I find the holy wars are usually fueled by "fans" -- people less invested and less knowledgable in the topic. This is true of movies, bands, sports teams, phones, computers and cars. The fact is if you work on the tech you appreciate that there are tradeoffs and know what your overall objective is (so are less likely to argue about things that don't get you there). Musicians tend to get along -- did the Beatles hate the Stones (OK, the Stones released "Let it Bleed"). I doubt Mark Hamill hates Star Trek or Shatner Star Wars. The catholic pope meets with the grand mufti of Jarusalem. Obama and Bush talked a lot in 2008 and 2009. It's like the joke about academia being so cutthroat as the stakes are so small. Holy / Flame wars erupt among those on the periphery at best.

coldtea 10y ago

>(for example both Go and Haskell need some kind of “green threads”, so there are more shared runtime challenges than you might expect) 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.

szemet 10y ago
Name a language having a compiler that most similar to Go in the threading domain, e.g.: compiles to machine code have green threads use non-blocking IO in the background have parallel runtime Haskell is the first that comes to my mind. (I guess that Common Lisp is a safe bet too, as it had everything for ages before it was cool;), but I'm not familiar with that domain to be sure) Erlang have everything except machine code compilation. What else? I guess the rest is from the newer, lesser known or experimental languages. So is there anything more popular than Haskell?
- coldtea 10y ago
  Occam (!= Ocaml) did CSP akin to Go AND static compiling back in the eighties. Various schemes have had both too (Racket, Chicken, etc), and CommonLisp is indeed a safe bet... I think Julia is there too, not sure.
- pjmlp 10y ago
  Active Oberon, initially developed in 1996. - compiles to machine code, check. A whole operating was written in it, AOS (aka BlueBottle). - have green threads, check. That is where the name Active comes from. It makes use of tasks. - use non-blocking IO in the background, check. Tasks are used everywhere across whole OS. - have parallel runtime, check. The whole OS makes use of parallelism and its compiler, Paco, does compilation of modules in parallel https://en.wikipedia.org/wiki/Active_Oberon https://en.wikipedia.org/wiki/Active_Oberon http://www.ocp.inf.ethz.ch/wiki/Documentation/Front http://www.ocp.inf.ethz.ch/wiki/Documentation/Front http://www.progtools.org/article.php?name=oberon&section=compilers&type=tutorial http://www.progtools.org/article.php?name=oberon&section=com...

cyberpanther 10y ago

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. 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.

visarga 10y ago

/offtopic "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. 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.

dmit 10y ago
Agreed, but that is a technical problem that can (and should) be solved. For example, "C" and "C++" are even more unfriendly terms for search engines, yet Google handles them just fine: https://www.google.com/search?q=c+stdlib https://www.google.com/search?q=c+stdlib https://www.google.com/search?q=c%2B%2B+stdlib https://www.google.com/search?q=c%2B%2B+stdlib
- nagvx 10y ago
  When you feed them unambiguous queries like that, yes. "stdlib" is a very unique word specific to the domain of programming. Things get trickier with terms that have more overlap, and irrelevant results tend to creep further up the page.
  - lttlrck 10y ago
    that ambiguity is hardly limited to program languages.
- deleted 10y ago
  [deleted]
nagvx 10y ago
It's rather strange and ironic, given that Go came from Google, that they used such a search-hostile word. ("Golang" is a lot less problematic, of course. Hell, in an alternate universe, why not "Gol"? Only one more letter, and no serious collisions I can see...)
- 10y ago

zzzcpan 10y ago

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. 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.

athenot 10y ago

This reminds me of Perl's motto: There Is More Than One Way To Do It. Regardless of the community, we generally all strive for the most efficient 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. It's a good idea to know why 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.

rektide 10y ago

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. 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 in it's tooling. 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.

stcredzero 10y ago
Go is rather unique in how much Go-tooling-specific tooling knowledge one has to have to even begin writing code There's not much of that. I think that most people who are put off by that are actually angry that Go didn't affirm their own prejudices.
rsc 10y ago
You're right that the two are difficult to reconcile. Even so, one of my goals this year is to try.

tiglionabbit 10y ago

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. 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*. 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. 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. There are built-in functions that use generics, but I'm not allowed to write one? Hypocrites. 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.

wyager 10y ago
> It has Structural Typing! Amazing! I wouldn't say Go has structural typing. It has a form of interfaces, which are not the same. Structural typing is when the data members of an object are expressed in its type. For example, `x : {f : t}` is a statement that the object `x` has a member called `f` of type `t`. That is structural typing. On the other hand, what Go has is pretty much the definition of interfaces, where you have constraint types that indicate that anything satisfying the constraint has some functions defined on it.
- 10y ago

twblalock 10y ago

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. 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. 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.

hodgesrm 10y ago
Can you cite some examples of what you mean? I certainly agree on Scala--after trying it out for a while it definitely seemed to me Java was not so bad after all. (Specifically I'm thinking of things like the problems of doing builds of Kafka across different Scala versions. This was a couple years ago so maybe things are better.)
camus2 10y ago
> I think the Go team probably wanted to avoid the mess that C++ has become, Ultimately, people will write a Go++ because the language isn't good enough. That's not avoiding C++, that's forcing people to recreate C++ .
- pjmlp 10y ago
  The solution "go generate" reminds me of the class generating tools that Borland shipped with their C++ compilers, before they added support for templates, back in the MS-DOS days!

AsyncAwait 10y ago

I like generics, but why can't there be a language that doesn't have them? If I want a simple language, no generics I go with Go, for everything else I go with Rust and Swift. Not every language has to have generics, when I want to use them, I simply switch languages. 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.

camus2 10y ago
> I like generics, but why can't there be a language that doesn't have them? Python,Ruby and Javascript don't have generics ... because they are dynamically typed. Go has generics, maps and array are container types, you just can't define your own. To say Go has no generics is stupid, it just doesn't allow you to define your own. Instead you can use catch all interface{} everywhere like dynamically typed languages. > Not every language has to have generics, when I want to use them, I simply switch languages. This statement makes no sense at all.
- AsyncAwait 10y ago
  > Go has generics, maps and array are container types, you just can't define your own. To say Go has no generics is stupid, it just doesn't allow you to define your own. That's usually what is indeed meant by the statement "Go doesn't have generics", maybe it should be "Go doesn't have user-defined generics", but I assume most people can infer that. I really hate the recent trend of having to spell everything out. > This statement makes no sense at all. Can you be more specific? What doesn't make sense at all in saying that when I have a simple problem that is unlikely to benefit greatly from a more sophisticated type system, I reach for Go, otherwise I use a different language?
candiodari 10y ago
And for people who don't get a choice, there is introspection and code generation. In Go, both of those options are, firstly a necessity, secondly far more complex than generics and thirdly introduce (more) weird project-specific exceptions to the type system that can't be reasoned about.

ereyes01 10y ago

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. 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. 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... 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" :-)