GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-07-13) - page 1 of 10
 
___________________________________________________________________
Toward Go 2
455 points by dmit
https://blog.golang.org/toward-go2
___________________________________________________________________
 
beliu - 39 minutes ago
This was announced at GopherCon today. FYI, if folks are interested
in following along other conference proceedings, there is no
livestream, but there is an official liveblog:
https://sourcegraph.com/gophercon
 
cdnsteve - 5 hours ago
"We estimate that there are at least half a million Go developers
worldwide, which means there are millions of Go source files and at
least a billion of lines of Go code"
 
  ovao - 4 hours ago
  Perhaps fewer than a billion lines of Go code if there were
  generics.
 
concatime - 1 hours ago
The leap second problem reminds me of this post[0].[0]
https://news.ycombinator.com/item?id=14121780
 
nebabyte - 2 hours ago
But I always heard never to use Go 2! :P
 
[deleted]
 
loup-vaillant - 3 hours ago
> For example, I've been examining generics recently, but I don't
have in my mind a clear picture of the detailed, concrete problems
that Go users need generics to solve. [?] If we had a large set of
real-world use cases, we could begin to answer a question like this
by examining the significant ones.Not implementing generics, then
suggesting that it would be nice to have examples of generics being
used in the wild? You had it coming, obviously.Now what's the next
step, refusing to implement generics because nobody uses it?> Every
major potential change to Go should be motivated by one or more
experience reports documenting how people use Go today and why
that's not working well enough.My goodness, it looks like that is
the next step.  Go users have put up with the absence of generics,
so they're not likely to complain too loudly at this point
(besides, I hear the empty interface escape hatch, while not very
safe, does work).  More exacting developers have probably dismissed
Go from the outset, so the won't be able to provide those
experience reports.
 
  why-el - 42 minutes ago
  > Not implementing generics, then suggesting that it would be
  nice to have examples of generics being used in the wild? You had
  it coming, obviously.I think you misunderstood. Clearly he meant
  to ask for examples from the real world that lack generics, but
  shows how adding them would improve the system.
 
[deleted]
 
jimjimjim - 2 hours ago
Here be Opinions:I hate generics.  also, I hate exceptions.Too many
people are wanting "magic" in their software. All some people want
is to write the "Happy Path" through their code to get some
Glory.If it's your pet project to control your toilet with tweets
then that's fine. But if it's for a program that will run 24/7
without human intervention then the code had better be plain,
filled with the Unhappy Paths and boring.Better one hour writing
"if err" than two hours looking at logs at ohshit.30am.
 
  NiceGuy_Ty - 1 hours ago
  What don't you like about generics?
 
  abiox - 1 hours ago
  in a sense, generics just let you provide parameters to your
  types, just like you give parameters to functions.  it's not all
  that magical.
 
    vram22 - 49 minutes ago
    Yes, I had read in an article about/by Walter Bright about D,
    that that was the insight he had, when working on the design of
    generics or templates for D:To paramet(e)rize the types (of a
    class or function or method), just like you parametrize the
    arguments of a function or method.
 
  baq - 1 hours ago
  there's nothing magic about generics. every time you make a
  channel or a map in go, you're using a generic function even if
  go people don't want you to call it that.there's nothing magic
  about exceptions, too, it's that it's harder than necessary to
  use them correctly and that's why it's not as big of a deal to
  not have them in go - as evidenced by this thread.
 
    why-el - 46 minutes ago
    Curious, how is a map generic?
 
    Animats - 1 minutes ago
    Yes, go has generics, or at least parameterized types, used for
    channels and maps. What it doesn't have are user-defined
    parameterized types.
 
    wtfrmyinitials - 42 minutes ago
    I can sympathize with the dislike of exceptions. I very much
    prefer Rust's error handling model (return Result)The
    fact that Go has had this much success without generics is
    mind-boggling to me.
 
[deleted]
 
Analemma_ - 5 hours ago
> For example, I've been examining generics recently, but I don't
have in my mind a clear picture of the detailed, concrete problems
that Go users need generics to solve.This is sampling bias at work.
The people who need generics have long since given up on Go and no
longer even bother participating in Go-related discussions, because
they've believe it will never happen. Meanwhile, if you're still
using Go, you must have use cases where the lack of generics is not
a problem and the existing language features are good enough.
Sampling Go users to try and find compelling use cases for adding
generics is not going to yield any useful data almost by
definition.
 
  xyzxyz998 - 4 hours ago
  So what's happening here? The parent made a reasonable comment,
  without flaming anybody. All his children give evidence for him
  (except one but they weren't able to downvote) and yet the parent
  is downvoted. Votes don't matter but I'm curious about drive-by-
  downvoting. What does that signify? Fanboyism?
 
  phillipcarter - 4 hours ago
  We have a similar viewpoint w.r.t Higher Kinded Types in F#.
  Much of the motivation for HKTs comes from people wishing to use
  them how they've used them in other languages, but we've yet to
  see something like this in our language suggestions or design
  repositories:"Here is a concrete example of a task I must
  accomplish with , and the lack of HKTs
  prohibits me from doing this in such a way that I must completely
  re-think my approach.(Concrete example explained)I am of the
  opinion that lacking HKTs prevents me from having any kind of
  elegant and extensible design which will hold strong for years as
  the code around it changes."Not that HKTs and TypeClasses aren't
  interesting, but without that kind of motivation, it's quite
  difficult to justify the incredibly large cost of implementing
  them well.  And that cost isn't just in the code and testing of
  the compiler.  This cost also surfaces in tooling, documentation,
  and mindshare.  It could also have an unknown effect on the ethos
  of F#, which for better or for worse, does bring with it a bit of
  a somewhat intangible quality that many people like.Personally, I
  think Golang should implement generics.  But I'm sympathetic with
  the views expressed by Russ Cox here.  And I don't think it's
  just sampling bias.
 
    eropple - 3 hours ago
    This is apples and hand grenades, though. You're looking for a
    use case for HKTs. I just want to make a tree without copy-
    pasting.
 
      phillipcarter - 1 hours ago
      Fair point.
 
    int_19h - 3 hours ago
    It's the same thing in principle, but it's one of those cases
    where details matter a lot. Generics have been mainstream - as
    in, implemented in mainstream programming languages used to
    write millions of lines of production code - for over a decade
    now. At this point, someone claiming that they need specific
    user scenarios to convince them that generics are worthwhile,
    or that they aren't aware of a "good enough" way to implement
    them, beggars belief.
 
    amluto - 3 hours ago
    This is a fair point.  OTOH, just punting entirely seems like
    the wrong reaction.Rust, for example, has been thinking about
    HKTs for a while, and they might not fit well in the language.
    Rust wants to solve the problems that HKTs solve, and it looks
    like the solution is converging to ATCs (associated type
    constructors).It's taking a while, but Rust is newish, and it
    isn't taking anywhere near as long as Go is taking to get
    generics.
 
  eropple - 5 hours ago
  > no longer even bother participating in Go-related discussions,
  because they've believe it will never happen/raises handI like
  when tools are good, but I've basically written off Go as a tool
  for generating unsustainable code right now (and a big part of it
  is the odious options, either type-unsafety or code generation,
  for things that are trivially handled by parametricity). If
  things change, I'll be happy to revisit it, but the described
  thought process just ignores my existence. And that's fine from
  my perspective, because I don't need Go, but I'd still like it to
  be better in case I do need to use it.
 
    pjmlp - 4 hours ago
    I kind of think the same way, but thanks to Docker and K8s
    success, it means we might have to deal with Go code regardless
    how we think about it.
 
    kardianos - 5 hours ago
    I think the Go team would still like to understand your
    production uses that caused you to write off Go. What is your
    problem domain? How would you accomplish that in Go? How did
    you actually solve your problem with a different language?For
    me, user provided data structures are the only thing that comes
    to mind (sync.Map for example) in my production use of Go. But
    even then, my pain (time spent, errors made) due to a lack of
    generics is low.You may have written off Go. But if you're
    willing, I bet the Go team would still like to read your
    production code use-cases that caused you to do so.
 
      camus2 - 4 hours ago
      The domain problem is easy : compile time type safety instead
      of the reflection heavy mess that allow to opt-out from Go
      type system at runtime.
 
      I_am_tiberius - 4 hours ago
      I'm new to Go and actually and don't do professional IT work
      but I immediately felt the need for having a type that
      allowed me to store any type.My use case was/(still is)
      writing a spreadsheet where a user can enter different stuff
      in a cell and I want to store the value in an underlying data
      type. I now ended up storing everything as string because I
      couldn't figure out an efficient way to implement it.My goal
      would have been to have one generic type that can store the
      cell types text and number which I can store in an array.
      This generic type could then implement an interface method
      like format() which calls a different format method depending
      on the type the cell has.I played around with interface and
      reflect.TypeOf but lost too much performance compared to just
      storing everything in a string. Strings on the other hand now
      fill up my memory with stuff I don't need - at least that is
      my impression.I don't have programming experiences so maybe I
      misunderstand the discussion or just overlooked a way to
      solve my issue in an efficient way. So sorry if the example I
      mentioned something easily doable in go.
 
        masklinn - 3 hours ago
        > My goal would have been to have one generic type that can
        store the cell types text and number which I can store in
        an array.FWIW generics wouldn't help you with that, "sum
        types" would. A sum type is a souped-up enum which can
        store associated data alongside the "enum tag", so you can
        have e.g.    enum Foo {         Bar(String),
        Baz(u8, u32),         Qux,     }  and at runtime you ask
        which "value" is in your enum:    match foo {
        Bar(s) => // got a Bar with as string inside         Baz(n,
        _) => // got a Baz, took the first number         Qux => //
        Got a Qux, it stores no data     }  (and in most languages
        the compiler will yell at you if you forget one of the
        variants).So for your use case you'd have e.g.    enum
        Value {         Boolean(bool),         Integer(u32),
        String(String),         // etc?     }  > I played around
        with interface and reflect.TypeOf but lost too much
        performance compared to just storing everything in a
        string.Maybe try a struct with an explicit tag rather than
        reflection? e.g.    type ValueType int     const (
        TYPE1 ValueType = iota         TYPE2         TYPE3
        // ? one for each concrete type you want to wrap      )
        struct Value {         type ValueType         value
        interface {}     }  and then you can    switch value.type {
        case TYPE1:         value.value.(Type1)     case TYPE2:
        value.value.(Type2)     // etc...  I'd expect
        reflect.TypeOf to be very expensive, this is a check + a
        cast.
 
          I_am_tiberius - 3 hours ago
          Thanks for that information. I had thought enums can only
          be used as named types. Good to know they can hold data
          as well. I had though of that struct as well (ok, not in
          that professional way with types as constants and
          iota:-)) but found it a bit annoying that I have to store
          a type myself although the type itself should already
          have the type information somewhere itself - consequently
          that information is stored reduntantly. But I'll
          definitely try that. Thanks.
 
          eropple - 3 hours ago
          FWIW, "enums" are in most languages you'll run into
          somewhat distinct from "enum types".
 
          masklinn - 2 hours ago
          > I had thought enums can only be used as named types.
          Good to know they can hold data as well.That depends on
          the language, and enums being sum types also depends on
          the language.* Rust and Swift enums are sum types (they
          can hold data and every variant can hold different
          stuff), there is also a ton of (mostly functional)
          languages with sum types not called enum: Haskell, F#,
          OCaml, ? there are also languages which replicate them
          via other structures (sealed classes in Kotlin, case
          classes in Scala).* java enums (a bare "enum" is the C
          one) can hold data but every variant must hold data of
          the same type so you'd need up/down casts* C++, C# and C
          enums can't hold dataGo does not have enums.
 
      eropple - 4 hours ago
      My "problem domain" is "good, correct code". I write code in
      many different spaces, from web software to mobile apps to (a
      lot of) devops tools to (less these days) games. My criticism
      of Go isn't "it's not good at code for my problem domain,"
      it's "it's not good at code for your problem domain, either,
      and your workarounds shouldn't need to exist."User-provided
      data structures are a big one. (A language where I have to
      copypaste to have typesafe trees is a bad language.) But,
      beyond that, I build stuff to be compiler-verified. Here's a
      trivial example that I did yesterday that I straight-up can't
      do in Go, but did in C# as part of a object graph rehydration
      routine (where object A required pointers to object B from a
      different data set, and since it's 2017 we aren't using
      singletons so the JSON deserializer takes in converters that
      look up objects based on keys in object A's JSON
      representation):   public interface IKeyed { T Key { get;
      } }  Just being able to do that on an object is powerful. C#
      has reified types; I know what T is at runtime. (I can't
      specialize on the type in C#, but I can fake it.) But I also
      know what it is at compile-time, and so I can't accidentally
      pass `IKeyed` and `IDictionary      DependentObject>` to the same function because type
      constraints, yo.I don't really care about fast code, because
      computers are all future-computers-from-beyond-the-moon. If
      I'm using a statically-typed language, I care about correct.
      Duplicated code is code that will--not may--lead to bugs.
      State I have to maintain in my head (like "this is an int
      map, talking to an int-keyed object set") is state that will
      --not may--lead to bugs.If you're a statically-typed language
      that isn't helping me avoid bugs, you might as well not
      exist. You don't have to be whomping around stuff like
      Scala's Shapeless--I would argue that you shouldn't--but you
      have to provide at least a basic level of sanity and the
      difficulty of expressing stuff outside of parameterized types
      (even when there are workarounds) makes it not worth the
      hassle. I'll cape up for damned near everything in at least
      some context, from dynamic languages like Ruby and ES6 to
      Java (well, Kotlin) or C# to Modern C++ to Scheme or a Lisp.
      My no-buenos on programming languages are limited pretty
      exclusively to C and Go because both languages encourage me,
      encourage all of us who use them, to write bad code.
 
  xfer - 5 hours ago
  Yes, using empty interfaces and adding common data structures to
  the runtime eliminate the primary use-case of generics. Who would
  have thought..
 
  smdz - 4 hours ago
  I have used generics for quite long. When I used it I loved it.
  Then I moved to a different language for a few years, and lost
  generics. Now I have written large programs in GoLang too - and
  frankly I do not miss out on generics at all. Now, I also find
  reading code with generics isn't straightforward either - it
  requires a slightly complicated mental model.
 
notjack - 3 hours ago
> We did what we always do when there's a problem without a clear
solution: we waited. Waiting gives us more time to add experience
and understanding of the problem and also more time to find a good
solution. In this case, waiting added to our understanding of the
significance of the problem, in the form of a thankfully minor
outage at Cloudflare. Their Go code timed DNS requests during the
end-of-2016 leap second as taking around negative 990 milliseconds,
which caused simultaneous panics across their servers, breaking
0.2% of DNS queries at peak.This is absurd. Waiting to fix a known
language design issue until a production outage of a major customer
is a failure of process, not an achievement. The fact that the post
presents this as a positive aspect of Go's development process is
beyond comprehension to me.
 
  TazeTSchnitzel - 45 minutes ago
  They did the same thing with adding a ?round? function. As a
  result, there are myriad implementations of round() in the wild
  in Go, and almost every single one is broken in several ways.
 
  43224gg252 - 44 minutes ago
  It's not absurd. This methodology may not be best for everyone,
  but imo it's best for the language its self, and seeing as Go is
  one of todays fastest growing languages the developers must be
  doing something right.
 
oelmekki - 4 hours ago
As a ruby and go dev, I'm a bit sad to see backward-compatibility
going. Thinking I could write code with minimum dependencies and
that would just work as is years later was really refreshing
compared to the high level of maintenance needed in a ruby app.But
well, I trust the core team to make the best choices.
 
tschellenbach - 3 hours ago
The beauty of Go is that you get developer productivity pretty
close to Ruby/Python levels with performance that is similar to
Java/C++Improvements to package management is probably the highest
item on my wishlist for Go 2.
 
  owaislone - 3 hours ago
  > Improvements to package management is probably the highest item
  on my wishlist for Go 2.The work is in progress and will most
  likely be available for general purpose use way before Go2.Check
  it out: https://github.com/golang/dep
 
  the_duke - 3 hours ago
   There is so much boilerplate you have to write that productivity
  drops considerably, both because you have to re-re-re-re-
  implement things (or use code generation) and because you need to
  scan lot's of redundant code before making sense of it.The
  alternative is often to just use interface{}, which hurts
  performance and type safety.
 
    tschellenbach - 2 hours ago
    This has so far been a theoretical concern for me only. If you
    want to write reusable data structures you obviously need
    generics. But none of the code I've written involves reusable
    data structures, so I can't say I really miss generics.
 
  zbobet2012 - 3 hours ago
  That's going to happen before go 2. Go 1.9 / 1.10 time frame.
 
johansch - 3 hours ago
My main wish:Please don't refuse to compile just because there are
unused imports.Please do warn, and loudly say it's NON-CONFORMANT
or whatever will embarass me enough from sharing my piece of Go
code with someone else.. but.. can I please just run my code, in
private, when experimenting?
 
  ahacker15 - 3 hours ago
  I like that Go don't allows unused import and variables.If you're
  working with inexperienced programmers (and some experienced but
  bad programmers), you should be certain that they WILL let that
  code garbage there if the compiler allow it.
 
    Orangeair - 3 hours ago
    That's the kind of thing that should be detected by a linter
    and stop code submission though, not necessarily stop it from
    even compiling. What if you just want to comment something out
    quickly? I don't program in Go, but it seems like it would be
    annoying to have to repeatedly add and remove the main
    dependencies while I was iterating on something.
 
      johansch - 48 minutes ago
      It is absurdly annoying. It's the one thing that put me off
      golang development, despite all of its nice aspects relating
      to concurrency.Having custom functionality in editors to work
      around this apparently dogmatic design decision in the core
      language.. is also just absurd.
 
      infogulch - 2 hours ago
      This problem is fixed by using the "goimports" tool that will
      automatically add and remove imports as they're used on save.
      Pretty much every editor supports it. With goimports and
      gofmt that formats code, I no longer have to think about
      formatting and imports at all until I git diff, the whole
      problem vanishes.
 
    johansch - 3 hours ago
    Funnily enough: I've never found that to be a big problem with
    other languages in practice. Actually, on a scale of problems
    in other people's code I'd probably put this very far down the
    list.
 
      nuggien - 14 minutes ago
      Have you worked with code where unused variables actually
      have a side effect?
 
  rexf - 3 hours ago
  there is the godep tool that addresses the issue
  https://github.com/tools/godep> godep helps build packages
  reproducibly by fixing their dependencies
 
    johansch - 3 hours ago
    This is hostile behavior towards a new developer trying out
    golang. Any third-party tools aren't really going to fix that.
 
  nuggien - 3 hours ago
  Just use an editor that has goimports hooked up to run on save.
 
    johansch - 3 hours ago
    Or pick a language where you don't have to jump through
    arbitrary hoops.
 
      nuggien - 15 minutes ago
      depends on which editor you use, but i'd say there's a high
      chance it has a go package that has all this configured for
      you.In any case, every language has a hoop to jump through.
      Good luck finding one without.
 
  fixermark - 3 hours ago
  I'd be even more excited if the compiler were willing to execute
  complete heresy on my behalf and (with user consent) edit my
  source code automatically to remove unused imports. ;)
 
    johansch - 3 hours ago
    You mean have the compiler modify the source code files
    destructively? Then I'll have to disagree, that just doesn't
    make sense.
 
      dmit - 2 hours ago
      There was a precedent in Haskell land:
      https://twitter.com/bos31337/status/116372971509121025A more
      modern implementation: https://github.com/munificent/vigil
 
        fixermark - 40 minutes ago
        `gofmt -w` also already exists, it just (a) has to be run
        as a separate step and (b) doesn't have full cross-file
        understanding of the program.Since we have version control
        now, I don't see any threat from an optional capacity for
        the compiler to destructively mutate the source as an
        optional feature. Let the same toolchain that converts
        input to output suggest improvements to the input.
 
[deleted]
 
lemoncucumber - 3 hours ago
As much as I want them to fix the big things like lack of generics,
I hope they fix some of the little things that the compiler doesn't
catch but could/should. One that comes to mind is how easy it is to
accidentally write:  for foo := range(bar)  Instead of:  for _, foo
:= range(bar)  When you just want to iterate over the contents of a
slice and don't care about the indices. Failing to unpack both the
index and the value should be a compile error.
 
  mappu - 1 hours ago
  If `bar` is a slice then the short syntax isn't that useful
  (although it's shorter than the three-clause for loop
  equivalent).But if `bar` is a map or a channel, then that short
  syntax is very handy.For comparison's sake, you don't see many
  PHP users complaining about the difference between `foreach($bar
  as $foo)` and `foreach($bar as $_ => $foo)`.
 
[deleted]
 
EddieRingle - 4 hours ago
    > To minimize disruption, each change will require     >
careful thought, planning, and tooling, which in     > turn limits
the number of changes we can make.     > Maybe we can do two or
three, certainly not more than five.      > ... I'm focusing today
on possible major changes,     > such as additional support for
error handling, or     > introducing immutable or read-only values,
or adding     > some form of generics, or other important topics
> not yet suggested. We can do only a few of those     > major
changes. We will have to choose carefully.  This makes very little
sense to me. If you _finally_ have the opportunity to break
backwards-compatibility, just do it. Especially if, as he mentions
earlier, they want to build tools to ease the transition from 1 to
2.    > Once all the backwards-compatible work is done,     > say
in Go 1.20, then we can make the backwards-     > incompatible
changes in Go 2.0. If there turn out     > to be no backwards-
incompatible changes, maybe we     > just declare that Go 1.20 is
Go 2.0. Either way,     > at that point we will transition from
working on     > the Go 1.X release sequence to working on the
> Go 2.X sequence, perhaps with an extended support     > window
for the final Go 1.X release.  If there aren't any backwards-
incompatible changes, why call it Go 2? Why confuse anyone?---
Additionally, I'm of the opinion that more projects should adopt
faster release cycles. The Linux kernel has a new release roughly
every ~7-8 weeks. GitLab releases monthly. This allows a tight,
quick iterate-and-feedback loop.Set a timetable, and cut a release
with whatever is ready at the time. If there are concerns of
stability, you could do separate LTS releases. Two releases per
year is far too short, I feel. Besides, isn't the whole idea of Go
to go fast?
 
  artursapek - 4 hours ago
  They're trying to avoid creating the new Python 3
 
  masklinn - 4 hours ago
  Adding generics isn't even backwards-incompatible. AFAIK Java 1.5
  was just fine with Java 1.4 code, and so was C# 2.0. The latter
  using reified generics (and not cheating with builtins) lead to
  the duplication of System.Collections but given builtins aside as
  of Go 1.9 it has under half a dozen non-generic collections
  (versus 25 types in System.Collections, though some of them
  didn't even make sense as generics and don't have a
  System.Collections.Generic version) that's unlikely to be an
  issue.
 
    munificent - 3 hours ago
    > so was C# 2.0.True, but C# also has nominal types,
    overloading, and explicit interface implementation. Adding
    generics without breaking existing code without those features
    looks very difficult to me.
 
      rbehrends - 1 hours ago
      They don't have to be Java-ish generics.Think
      SML/OCaml/Ada/Modula-3 (modules parameterized by modules) or
      Haskell (typeclasses).
 
      spion - 2 hours ago
      What makes it difficult?
 
  ainar-g - 4 hours ago
  (Copying my reply from Reddit.)>If you finally have the
  opportunity to break backwards-compatibility, just do it.I think
  Russ explained pretty clearly why this is a bad idea. Remember
  Python 3? Angular 2? We don't want that to happen with Go
  2.0.>Additionally, I'm of the opinion that more projects should
  adopt faster release cycles.I am of the opposite opinion. In
  fact, I consider quick releases to be harmful. Releases should be
  planned and executed very carefully. There are production
  codebases with millions of lines of Go code. Updating them every
  month means that no progress will be made at all. The current
  pace is very pleasant, as most of the codebases I work with can
  benefit from a leap to newer version every six months.
 
    makecheck - 3 hours ago
    I think Python was too ingrained to pull a "Python 3"; Go is
    newer, and this could be more like a "Swift 3".Break early and
    then stabilize for a long time; just make sure everybody knows
    the plan.
 
      ainar-g - 3 hours ago
      It's barely related to the topic, but another team in my
      company is thinking about rewriting a pretty large codebase
      in ObjC into something more sustainable. They briefly
      discussed Swift, but decided against it exactly due to its
      relatively frequent breaking changes.Which emphasises even
      more the fact that large private codebases really dislike
      breaking changes.
 
    camus2 - 4 hours ago
    > I think Russ explained pretty clearly why this is a bad idea.
    Remember Python 3? Angular 2? We don't want that to happen with
    Go 2.0.The problem with Python 2/3 is that Python 3 didn't add
    enough new features to make people want to move to 3.The
    problem with Angular 2 is that it just didn't know what it
    wanted to be.If Go2 doesn't break enough yet still break it
    will be no different from Python 2/3 fiasco.Go has serious
    design issues, the go team ignoring them hindered Go adoption
    pace at first place.
 
      dragonwriter - 4 hours ago
      Breaking things aren't want makes people want to move; it's a
      cost, not a benefit. Now, you need to offer benefits to get
      people to pay the cost for those benefits. The Python 2/3
      problem was because there was too much breakage for the
      perceived benefit (especially early on) for many users, not
      because there was too little breakage.
 
        notheguyouthink - 2 hours ago
        Fwiw, I think breaking implies improving. Arguing that
        breaking doesn't inherently mean improving is.. well, duh.
        So in the case of many peoples comments here, "not breaking
        enough" means not improving enough. I know this is an
        obvious statement, but I feel like you're arguing a moot
        argument.. i.e., being a bit pedantic.As an aside, since
        you're making the distinction, can you have meaningful
        benefit without breakage? Eg, you're specifically
        separating the two - so can you have significant
        improvements without breakage?It would seem that pretty
        much any language change, from keyword changes to massive
        new features, breaks compatibility.
 
          dragonwriter - 53 minutes ago
          > As an aside, since you're making the distinction, can
          you have meaningful benefit without breakage?Sure, in two
          ways:(1) Performance improvements with no semantic
          changes.(2) New opt-in features that don't break existing
          code (such as where code using the new feature would have
          just been syntactically invalid in the old version, so
          the new feature won't conflict with any existing
          code.)There be no reason for SemVer minor versions if you
          couldn't make meaningful improvements while maintaining
          full backward-compatibility.
 
          vram22 - 45 minutes ago
          >As an aside, since you're making the distinction, can
          you have meaningful benefit without breakage? Eg, you're
          specifically separating the two - so can you have
          significant improvements without breakage?One way is by
          having a new language feature which does not interact
          with anything else in the old version of the language,
          i.e. is orthogonal.
 
jasonwatkinspdx - 3 hours ago
Disclaimer: I mean this with loveThis post really frustrates me,
because the lengthy discussion about identifying problems and
implementing solutions is pure BS. Go read the years worth of
tickets asking for monotonic time, and see how notable names in the
core team responded. Pick any particular issue people commonly have
with golang, and you'll likely find a ticket with the same pattern:
overt dismissal, with a heavy moralizing tone that you should feel
bad for even asking about the issue. It's infuriating that the same
people making those comments are now taking credit for the
solution, when they had to be dragged into even admitting the issue
was legitimate.
 
  notjack - 3 hours ago
  Note that at no point in the post whatsoever were any
  contributions to these specific issues from outside the core
  maintainers thanked or even acknowledged.
 
    civilitty - 2 hours ago
    Which is quite surprising. With open source projects it's
    usually the other way around...
 
      FRex - 53 minutes ago
      Google already had incident with Guava where they didn't give
      a shit about the patches:
      https://news.ycombinator.com/item?id=3691587
 
  [deleted]
 
  kevinconaway - 3 hours ago
  > asking for monotonic timeHis anecdote about Google/Amazon using
  leap smears to solve the problem is telling.  I suspect that they
  were unable to see outside their own bubble to think about how
  others may be impacted.> We did what we always do when there's a
  problem without a clear solution: we waitedThe original problem
  described the issue and the potential consequences very well and
  the problem didn't change between the initial report and when
  cloudflare hit it.  It was only until a Serious Industrial User
  (to borrow a term from Xavier @ OCaml) got bit in a very public
  way that they actually began thinking about what a clear solution
  would look like.
 
    hinkley - 1 hours ago
    Well, but that's not waiting, that's stalling.
 
    Animats - 4 minutes ago
    Given Google's orientation towards server-side web
    applications, it makes sense. On the other hand, the real-time
    OSs such as QNX have had monotonic clocks available for
    decades, and they use them for all delay and time interval
    measurements. (In real-time, you use the monotonic clock for
    almost everything that matters, and the day clock for logging
    and display only. You don't want the clock used for delays and
    time intervals to "smear"; it might have physical effects if
    it's being used to measure RPM or something and seconds got
    slightly longer.)Go is great for server-side web applications.
    The libraries for that are all there and well debugged.
    Anything else, not so much.
 
    hota_mazi - 1 hours ago
    > We did what we always do when there's a problem without a
    clear solution: we waitedAnd this is exactly why the Go
    designers don't understand language design, and how this
    ignorance shines through every single place in their
    language.Language design is about compromises. There is never a
    perfect solution, only one that satisfies certain parameters
    while compromising others. You, the designer, are here to make
    the tough choice and steer the language in a direction that
    satisfies your users.Besides, characterizing their position as
    "We waited" is very disingenuous. First of all, this is more
    stalling than waiting, and second, waiting implies they at
    least acknowledge the problems, which the Go team famously
    never does. Read how various issues are answered and then
    summarily closed with smug and condescending tones.
 
      Jare - 3 minutes ago
      You are being deliberately negative here. Choosing to forego
      generics in favor of simplicity (and its impact along several
      axes) is a postcard example of a compromise. It is a tough
      choice that many people will be unhappy with, but there are
      also many Go programmers that are extremely satisfied with
      that direction.As for acknowledging, well, they have always
      been very clear about their position. It makes no sense to
      spend a decade answering the same question over and over with
      a long and elaborate response which the person asking has
      already seen and dismissed. I can understand them becoming
      condescending after a decade of facing people who act with a
      deliberately obtuse and holier-than-thou attitude.It's not
      like they have been lazy - every release of Go has had a
      large amount of improvements that matter. Working on generics
      would have meant sacrificing a (probably large) amount of
      them.(for the record, I dearly miss generics too!)
 
      [deleted]
 
  canes123456 - 2 hours ago
  The discussion is not about identifying problems. The issue is
  communicating the problem and explaining the impact. The Go team
  was wrong about monotonic time but the correct response is not to
  assign blame. Concrete examples and conversations are a better
  way to communicate a problem. This is what they are trying to
  communicate now.
 
  [deleted]
 
  jasonwatkinspdx - 1 hours ago
  This hit a nerve, so I'm going to leave it up, but after thinking
  about it I also don't like how purely negative it is. I can't
  edit it anymore but I do want to make a follow up to say
  something things explicitly:I want to be clear I'm thankful for
  the effort everyone has put into golang. Making something people
  care about enough to love or hate is hard. Stewarding a FOSS
  project can be a very negative thankless experience as well.
  While I'm being critical above, there are also lots of examples
  of golang folks, core or otherwise, making really constructive
  and productive comments and contributions. I don't mean to
  trivialize that or ignore it.
 
  conorh - 2 hours ago
  Would you mind providing examples of what you are talking about?
  My experience has been different - I find that the golang
  maintainers are thoughtful but also very very (very) busy people.
  So I find they tend to respond in a terse, and sometimes what
  might seem like an unfriendly way, but I haven't seen any of what
  you mention here.
 
    43224gg252 - 1 hours ago
    Same, and to add: Go 2 has been planned for a while (since the
    beginning?) and I'm pretty sure the core developers tend to
    defer major new feature ideas (e.g. generics) to Go 2.If they
    implemented everything everyone asked for they'd have another
    screw-up like C++ or Java.
 
      kasey_junk - 41 minutes ago
      Calling those languages screw ups is one of the funnier
      things I've seen in awhile.
 
        43224gg252 - 19 minutes ago
        I know that both Java and C++ have a lot more issues than
        Golang ever will. I've used all three languages. Java has
        mile long class hierarchies, massive try-catch blocks,
        indentation as thick as my neck, and runs in a JVM. It's so
        bad there are already other implementations that people
        would much rather use. I also really don't like the
        file/project naming conventions.C++ is a whole other
        animal. The whole system of a Go program is typically very
        penetrable. You can trace the code down to the bottom of
        the stdlib or even the compiler builtins in seconds with
        ease (thanks to the excellent Guru and vim-go). In my
        experiences of C++, I doubt how many C++ programmers have
        ever had a look to the implementation of STL or iostream,
        which is hard to do ergonomically. Although some people
        occasionally call the opaqueness encapsulation and see it a
        good practice (which I don't agree). There are lots of
        cross compilation and static linking problems that don't
        arise with Go. There is the problem that one C++ code base
        will look completely different from others because no one
        in the C++ world follows conventions the way people in the
        golang world do.Compared to them Go is a very well thought
        out and elegant language.
 
  camus2 - 3 hours ago
  > overt dismissal, with a heavy moralizing tone that you should
  feel bad for even asking about the issueThe attitude of Go
  community cannot be separated from the patronizing tone of Go
  maintainers. In fact it stems directly from the people @ Google
  working on Go. All the bullshit "you don't need that with go"?
  comes directly from Pike,Cox and co. It's fine to be opinionated,
  but just admit these are opinions instead of engaging into the
  bullshit they engaged in for years when dismissing this or that
  problem as irrelevant.Pike said "Go design" is done. Except that
  a language which design "is done" is a dead one.
 
    pmarreck - 3 hours ago
    I'm still sitting here shocked that a language where "err" (and
    the keywords that check around it) are used an order of
    magnitude more frequently than all other syntax in that
    language, has achieved this much popularity:
    https://anvaka.github.io/common-words/#?lang=go
 
      slantedview - 3 hours ago
      Python expats needed a place to go.
 
        geofft - 2 hours ago
        I don't understand this comment - Python does what I'd
        argue to be the "right" thing, which is that operations
        which can fail raise exceptions that unwind the stack. If
        you don't care to handle failure in a particularly granular
        or graceful way (e.g., you're a command-line process, or
        you're a server process with lots of independent requests),
        you can have one large catch statement around all of your
        work, or even just use the implicit one around the entire
        program provided by the runtime.Meanwhile, well-written C
        code does this the "wrong" way; every external call has to
        be done like    if (read(fd, buf, len) < 0) {
        hopefully remember to free some things;         return
        NULL;     }  Why do you think explicit error handling is a
        Pythonic practice?
 
      spyspy - 2 hours ago
      15 Million to 17 Million is not an order of magnitude.
 
        Svenskunganka - 2 hours ago
        The top 4 keywords in the list are what's used frequently
        in go to handle errors.  if err != nil {     return err   }
        So it's more like 7,7 million to 17,6 million (the top
        fifth "the" is from comments, so it doesn't count)
 
      w8rbt - 2 hours ago
      If it weren't for Goroutines I would not find go very useful.
      I expect C++ will implement coroutines and/or fibers someday
      that will be very well designed and more carefully/broadly
      thought out.
 
        nly - 2 hours ago
        Why wait?Coroutines: http://www.boost.org/doc/libs/1_64_0/l
        ibs/coroutine2/doc/htm...Fibers: http://www.boost.org/doc/l
        ibs/1_64_0/libs/fiber/doc/html/fib...
 
          w8rbt - 2 hours ago
          Good point. I prefer ISO standards and the built-in
          library, but your point is valid. Implementations do
          exist in C++ today.
 
      osteele - 2 hours ago
      That's what kept me from looking at the language for the last
      five years. I finally broke down and wrote my first Go
      program. Yeah, the errors (and lack of generics) are
      annoying, but it gets enough else right ? tooling, runtime
      speed, compilation speed, type inference, parametric
      polymorphism (on interface types) ? that I enjoyed it anyway.
      Every language has some annoyances; it's nice when there are
      only a few.
 
        43224gg252 - 1 hours ago
        Not only that, but you can just ignore errors during
        prototyping and with a little editor magic you can go back
        easily generate at least 85% of the if err != nil {... etc.
        statements.As much as people complain about it, explicitly
        checking errors like this (and checking them all) is almost
        essential for production quality enterprise code and any
        code running on mission critical systems (and to most
        project managers, all systems are mission critical).And
        fwiw I still prefer go's style of error checking to
        languages that implement massive try/catch blocks.
 
          pmarreck - 57 minutes ago
          I think the "embrace failure" supervisor model in BEAM is
          a superior design for mission-critical systems (such as
          cell networks, where it originated) while resulting in
          literally a ton less boilerplate. You just code the
          "happy path" and done. Any errors are logged and the
          process instantly restarted by the supervisor, you can
          follow up on them if they present a problem.If you were
          to code just this "happy path" in Go, it would actually
          be the unhappy path, because you'd have silent errors
          resulting in indeterminate state (read: horrible bugs to
          troubleshoot). If you believe programming is mostly about
          managing all possible state (as I do), then Go's strategy
          is way too explicit. In Erlang/Elixir/BEAM's case, as
          soon as state goes off the rails (read: encounters
          something the programmer didn't anticipate), it's logged
          and restarted by its supervisor process almost instantly.
          (and there are of course strategies for repeated
          restarts)
 
          XorNot - 39 minutes ago
          People keep saying this and I struggle to understand how
          this represents good  design. In any language I can
          always just eat the error and keep going, or eat the
          error and restart.That doesn't fix the error, and it
          doesn't imply the program will work correctly.
 
          ethbro - 8 minutes ago
          > In any language I can always just eat the error and
          keep going, or eat the error and restart.Defer to pmarrek
          on what they meant, but to me it's an issue of practical
          programming.In a choice between "I will tell you what to
          do about errors" vs "I will assume you only crash and
          restart on any error", I've found the later to be far
          more efficient.The former generally leads to a rat's nest
          of never ending error specialization as unexpected or
          rare stuff bubbles up in UAT or down the road in
          prod.Which isn't to say there's a right answer. There's
          always going to be particular situations where of course
          you should use one or the other.But on the whole, as a
          philosophical default, fail-and-recycle-on-all-errors is
          a helluva lot easier to spec, code, test, and maintain
          for me.
 
          43224gg252 - 29 minutes ago
          Those supervisors don't always handle the errors the way
          you want and can't always be implemented without
          diminishing overall performance. It's a trade-off.
 
        olivierva - 51 minutes ago
        And don't forget simplicity as a core design feature of the
        language. That alone is worth sacrificing generics for ;-)
 
          threeseed - 40 minutes ago
          Who gets to decide what is simple or not though
          ?Coroutines seem like something that is more complex to
          me than generics.
 
      Thaxll - 2 hours ago
      Still better that try / except: pass from other languages.
 
        barrkel - 1 hours ago
        Frankly, I've never seen that (try / catch / ignore
        exception) in any commercial codebase I've worked on,
        running into tens of millions of lines.The worst I've seen
        is people logging the error message but not the exception
        itself (so losing the stack trace), or causing another
        exception to be thrown (and losing the stack trace or cause
        of the original).
 
        twblalock - 1 hours ago
        No, it's way worse, because you have to write the error
        handling multiple times even if it is all the same (and it
        usually is).For example, in Java, I can make as many method
        calls I want inside of a try block, and catch an exception
        from any one of them in the catch block. In Go, I would
        need the equivalent of one catch block per method call, in
        the form of "if err != nil { return err }". Why repeat
        yourself?If you want to pass on an error in Go, its easy to
        do accidentally -- just omit "if err != nil". Both types of
        exception handling models enable this kind of behavior. If
        you are going to do it, you might as well not repeat
        yourself while you are doing it.
 
          laumars - 1 hours ago
          > Why repeat yourself?Because you can put more meaningful
          error messages due to the granularity of the checking.
          This has made debugging things a lot easier at times.
 
          threeseed - 30 minutes ago
          Maybe you haven't used exceptions on the JVM before but
          you can wrap them so it's possible to still have
          localised error messages if you want them.But in most
          cases it is unnecessary since you always have the line
          number and type of exception printed out as part of the
          stack trace.
 
          twblalock - 48 minutes ago
          You can, but you should not be forced to do so. I could
          easily do that in Java if I wanted to, but I also have
          the flexibility to handle them all in the same way, or
          pass them back to the caller (which the right thing to do
          99% of the time), with a very small amount of code.
 
          laumars - 31 minutes ago
          To be honest moaning about Go idioms is like moaning that
          Java is object orientated or Lisp has too many braces. If
          you don't like the idioms of a particular language then
          don't use that langauge. There's plenty of others to
          choose from. But moaning that language x should be more
          like language y is just daft as it misses the point of
          why language x decided to do something different in the
          first place.I'm not saying Go's error handling is better
          than Java's. But I've written some relatively large and
          complicated projects in Go (like the Linux $SHELL and
          REPL scripting language I'm currently coding this very
          moment) and error handling really is the least of the
          problems I've been having. Sure, Go's idioms do get in my
          way from time to time. But on balance Go's idioms save me
          more time than it wastes. Which is why I keep coming back
          to Go despite having used more than a dozen other
          languages in anger. But that's my workflow and my
          personal preference. Others will find the reverse to be
          true and I wouldn't be complaining that their language
          should be more like Go.Frankly I think people waste too
          much time comparing languages. Just try something and if
          it doesn't work, move on. Don't assume your personal
          preference is a benchmark for how all languages should be
          designed as there will be a million other developers
          whose personal preference will exactly oppose you.
 
          Thaxll - 36 minutes ago
          I remember in Python some class / module would have
          different fields in the error object, so it was really
          difficult to do something meaningful with those
          errors.There is also the switch case you need to make
          when catching an error, like tcp connection then dns
          resolution and so on, you have to know every time any
          kind of sub errors.
 
      logingone - 3 hours ago
      I've described Go programs as often looking like a listing of
      things that could go wrong.
 
        mohamedattahri - 1 hours ago
        Which is exactly what software engineers should spend most
        of their time doing.
 
        jalfresi - 3 hours ago
        In my opinion and experience, that is exactly what programs
        are
 
          threeseed - 38 minutes ago
          Not in Java, Scala, Clojure etc. it isn't.You can wrap
          all your code in an unchecked exception and never again
          have to worry about errors. It's bad practice obviously
          but there are many situations in which you don't care
          what error occurred but that an error itself occurred.
 
          bboozzoo - 2 hours ago
          Unless you're writing in Erlang, in which case you
          program the success path and 'let it crash' in a
          controlled manner.
 
          grogenaut - 1 hours ago
          You're assuming that it faithfully crashes in all error
          states as opposed to incorrectly continuing on it's merry
          way.
 
          pmarreck - 54 minutes ago
          Why wouldn't it, if you're pattern-matching correctly?
          And in any event, it seems far easier to get into that
          situation in Go (which ignores errors unless you
          explicitly check for them) than in Erlang (which crashes
          on every error because restarting is cheap)
 
          tsuraan - 45 minutes ago
          Have you used erlang? Pattern matching is a big part of
          it, and pattern match failures always result in errors.
          So, if you have some function foo() that always returns
          ok or {error, Reason}, then in the "follow the happy
          path" style, you'd just have a line reading "ok =
          foo(),", and then if foo actually returns something else,
          you get a "crash". There's no assuming anything there,
          it's just the way the language works.
 
        [deleted]
 
      collinmanderson - 2 hours ago
      hah. It's #1 "err", #2 "if", #3 "return", #4 "nil". :)That
      must be because a lot of function calls are followed by:  if
      err != nil {       return err   }
      https://stackoverflow.com/questions/18771569/avoid-
      checking-...
 
    treehau5 - 3 hours ago
    > Pike said "Go design" is done. Except that a language which
    design "is done" is a dead one.Guess C is done for.
 
      TJSomething - 3 hours ago
      Except they updated C in 2011 and they're already working on
      C2X.http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2086.htm
 
      andrewprock - 3 hours ago
      I think you're confusing stable with "done". The C language
      has been getting updates about once every 10 years:Original
      (~1970) K&R (~1980) ANSI C (~1990) C99 (~2000) C11 (~2010)I
      would not be surprised to see a C22.
 
        pebers - 3 hours ago
        To what degree are those being used though? Major projects
        (e.g. Linux, CPython) are still on ANSI C.
 
          xyzzyz - 2 hours ago
          Linux is definitely not on ANSI C, and CPython is on C99
          starting from 3.6.
 
          simias - 1 hours ago
          C99 took a while to be widely adopted mainly because some
          compilers where very slow on the uptake (I'm looking at
          you Visual C++) but now I would never consider using
          anything less than that for a new project. It's almost 20
          years old!Many small quality of life improvements:
          stdint.h stdbool.h,  inline, restrict, allowing variable
          declaration within the code, snprintf, variadic
          macros...Most of those were accessible through compiler
          extensions but having them in the standard means that you
          know it'll work everywhere on any compliant
          implementation.Linux definitely isn't conservative when
          it comes to the language, not only does it use modern
          features of the language but it even relies on GCC
          extensions and even sometimes on the compiler's optimizer
          to produce the correct code:
          https://unix.stackexchange.com/questions/153788/linux-
          cannot...I'm not super familiar with CPython but it also
          doesn't appear to limit itself to C89, see for instance
          this random file I opened: https://github.com/python/cpyt
          hon/blob/master/Python/future....You can see that `const
          char *feature` is declared in the middle of some code. It
          also uses "inline" in several places.
 
          ryanplant-au - 9 minutes ago
          CPython switched to C99.
 
          astrange - 2 hours ago
          Any code that declares variables in the middle of a
          function, // comments, or varargs macros is using C99.
 
        treehau5 - 1 hours ago
        I think you are confusing getting updates with "design"Go
        gets frequent updates as well.
 
zackmorris - 2 hours ago
Go doesn't have const structs, maps or other
objects:https://stackoverflow.com/questions/43368604/constant-
struct...https://stackoverflow.com/questions/18342195/how-to-
declare-...This is a remarkable oversight which makes it impossible
to write purely-functional code with Go.  We also see this same
problem in most other imperative languages, with organizations
going to great lengths to emulate const
data:https://facebook.github.io/immutable-js/Const-ness in the
spirit of languages like Clojure would seem to be a relatively
straightforward feature to add, so I don't really understand the
philosophy of leaving it out.  Hopefully someone here knows and can
enlighten us!
 
  secure - 2 hours ago
  There doesn?t need to be a philosophy behind leaving it out. Go
  was started by selecting only features which were deemed
  necessary. I think it?s fair to assume the creators of Go didn?t
  design it for writing purely-functional code, so that?s why it?s
  not in (yet?)
 
  zemo - 1 hours ago
  it's almost like writing purely-functional code is not the goal
  of Go.
 
bad_user - 4 hours ago
Java`s generics have had issues due to use site variance, plus the
language isn't expressive enough, leading its users into a corner
where they start wishing for reified generics (although arguably
it's a case of missing the forest from the trees).But even so, even
with all the shortcomings, once Java 5 was released people migrated
to usage of generics, even if generics in Java are totally optional
by design.My guess to why that happens is that the extra type
safety and expressivity is definitely worth it in a language and
without generics that type system ends up staying in your way. I
personally can tolerate many things, but not a language without
generics.You might as well use a dynamic language. Not Python of
course, but something like Erlang would definitely fit the bill for
Google's notion of "systems programming".The Go designers are right
to not want to introduce generics though, because if you don't plan
for generics from the get go, you inevitably end up with a broken
implementation due to backwards compatibility concerns, just like
Java before it.But just like Java before it, Go will have half-
assed generics. It's inevitable.Personally I'm sad because Google
had an opportunity to introduce a better language, given their
marketing muscle. New mainstream languages are in fact a rare
event. They had an opportunity here to really improve the status
quo. And we got Go, yay!
 
  logn - 2 hours ago
  My guess as to why people in Java use generics so much and
  switched to them so quickly is the squiggly yellow lines in their
  IDEs. A lot of Java code is easier to read/write with explicit
  and implicit casting and no use of generics. And the type erasure
  makes for sometimes unintuitive behavior at runtime. Being
  familiar with Java, I appreciate Go's skepticism toward generics
  because maybe just maybe they'll figure out a way to add them
  after the fact in an elegant way.
 
  jcadam - 4 hours ago
  After some initial enthusiasm due to its gentle learning curve
  (actually, the Golang learning curve is nearly non-existent for
  an experienced programmer), I got sick of Go programming pretty
  quickly.  Writing anything non-trivial will have you fighting
  against the limitations of the language (e.g., lack of generics
  which is particularly aggravating when trying to write a
  library).I've mostly moved on to Clojure for programming backend
  services.  I still use Go for the occasional small utility
  program due to its speed and ease of deployment, though.
 
    43224gg252 - 35 minutes ago
    I've programmed scores of libraries in Go and found it
    pleasant, in fact it's more pleasant writing a library in Go
    than in any other language I've used.I've never once even
    considered the fact that I might need generics because I've
    never run into an unsolvable problem or an extremely inelegant
    engineering solution. I see a lot of people claiming that the
    lack of generics is a big problem but no one is actually
    showing a concrete case where generics are necessary.C doesn't
    have generics but we never have this discussion when we talk
    about C.
 
  hdhzy - 3 hours ago
  > Java`s generics have had issues due to use site varianceUse
  site variance can be really powerful when you're dealing with
  invariant data structures like Lists. You can then treat them
  like covariant or contravariant depending on a particular method
  call at hand.
 
  fixermark - 3 hours ago
  The point of Go 2.0, IIUC, is that it throws away backwards-
  compatibility guarantees, so if they want to do something in Go
  2.0 that breaks correct go1 code to support generics, that's on
  the table. So backwards-compatibility nastiness is not
  guaranteed.
 
    scribu - 2 hours ago
    Not quite. The article mentions that Go 1 code needs to be able
    to coexist with Go 2 in the same codebase.So, at runtime, Go 1
    code needs to be able to work with Go 2 types. That will impose
    some restrictions, I imagine.
 
      vram22 - 1 hours ago
      >The article mentions that Go 1 code needs to be able to
      coexist with Go 2 in the same codebase.Interesting. Are there
      any other languages where that is allowed? I'm assuming that
      by "codebase" you mean all the code that gets compiled into
      one program or library (for compiled languages), or is part
      of one program or library (for interpreted languages). And I
      don't mean the case where only a common subset of Lang X v1
      features and Lang X v2  features are used in the same
      codebase (because in that case, there is no issue). That
      latter case is possible, for example, in Python, and probably
      some many languages too. In fact by the definition of the
      case, it should be possible in all languages.
 
        scribu - 1 hours ago
        > I'm assuming that by "codebase" you mean all the code
        that gets compiled into one program or libraryCorrect.> Are
        there any other languages where that is allowed?One would
        be Racket, a Lisp which allows you to pick a syntax flavour
        using the #lang directive: https://docs.racket-
        lang.org/guide/Module_Syntax.html#%28par...
 
        cyphar - 1 hours ago
        I would just read the article. Basically, the restriction
        they want to impose is to make sure that you can import v2
        code into a v1 codebase and vice-versa with a v2 compiler.
        So that means any syntax breakage would need to be
        versioned or otherwise inferred, I guess.
 
JepZ - 5 hours ago
I know there is a lot of discussion about generics, but I am not
sure if that is missing the point. I mean 'generics' sounds like a
complex concept from the java development and I am uncertain if
that's really what we need in go.From my experience I think we
should talk about container formats because they make 80% of what
we would like to have generics for. Actually, go feels as if it has
only two container data structures: Slices and Maps. And both feel
as if they are pretty hard coded into the language.Yes, I am sure
there are more container formats and it is possible to build your
own, but I think it is not easy enough.
 
  eropple - 5 hours ago
  > they make 80% of what we would like to have generics forI
  regularly use generics in other languages for tasks unrelated to
  "containers"/data structures. They allow me to write less code
  and have the compiler check my mistakes.Containers are frequently
  where people start with parameterized types, but once you are in
  the habit of using them actively that's rarely where you stop.
 
    masklinn - 4 hours ago
    > once you are in the habit of using them actively that's
    rarely where you stop.Eh. Many people don't ever go beyond that
    and it's fine, containers-type structures (to which I include
    stuff like futures or option types) and functions working on
    those are by far the most common use case.
 
      eropple - 4 hours ago
      For sure. But people like me write code for many-people.
      Giving us the tools to help make things better for many-
      people is wise. ;)
 
  masklinn - 5 hours ago
  > I mean 'generics' sounds like a complex concept from the java
  development and I am uncertain if that's really what we need in
  go.That's inane and insane. Java generics do almost nothing, they
  don't even exist at runtime in a language with (much like Go)
  heavy runtime semantics. Here's what Java's generics do: get
  typechecked, and insert implicit casts.> Yes, I am sure there are
  more container formatsFirst, you forgot Channels and arrays
  (which are distinct from slices) as well as "range" to iterate
  over them generically, second there are more containers than that
  in Go's own standard library: https://golang.org/pkg/container/,
  https://github.com/golang/go/issues/18177> it is possible to
  build your own, but I think it is not easy enoughWhat does that
  mean? It is not easy enough what? To write containers? To have
  generics?
 
    JepZ - 4 hours ago
    So if generics in java don't do anything beyond 'get
    typechecked, and insert implicit casts.' the empty interface is
    enough for all use-cases in go?
 
      camus2 - 4 hours ago
      > So if generics in java don't do anything beyond 'get
      typechecked, and insert implicit casts.' the empty interface
      is enough for all use-cases in go?Do you even care about
      compile time type safety?
 
      int_19h - 3 hours ago
      Yes, in a sense that structured loops don't do anything
      beyond inserting implicit if/goto, and so the latter is
      enough for all use-cases.
 
      masklinn - 4 hours ago
      1. the empty interface does not do the first one, and thus
      does not allow writing typesafe structures and code2. and it
      requires significant expense of explicit casts which are not
      just sanity checks (which is what they are in java, due to
      type system weaknesses)
 
    JepZ - 1 hours ago
    > What does that mean? It is not easy enough what? To write
    containers? To have generics?Actually, I meant it is not easy
    enough to build container formats (maybe due to the lack of
    generics).Btw. I will not continue this conversation as I am
    tired of getting insulted (inane and insane), getting downvoted
    for merely asking questions and you editing your post without
    labeling it. Just saying.
 
egonschiele - 1 hours ago
Most of the discussion here seems to be around generics, and it
sounds like they still don't see the benefit of generics.I like Go,
but the maintainers have a maddeningly stubborn attitude towards
generics and package managers and won't ease up even with many
voices asking for these features.
 
AnimalMuppet - 3 hours ago
There are many comments griping about generics.  There are many
comments griping about the Go team daring to even ask what problems
the lack of generics cause.But take a look at this article about
the design goals of Go:
https://talks.golang.org/2012/splash.article  Look especially at
section 4, "Pain Points".  That is what Go is trying to solve.  So
what the Go team is asking for, I suspect, is concrete ways that
the lack of generics hinders Go from solving those problems.You say
those aren't your problems?  That's fine.  You're free to use Go
for your problems, but you aren't their target audience.  Feel free
to use another language that is more to your liking.Note well:  I'm
not on the Go team, and I don't speak for them.  This is my
impression of what's going on - that there's a disconnect in what
they're asking for and what the comments here are supplying.(And by
the way, for those here who say - or imply - that the Go team is
ignorant of other languages and techniques, note in section 7 the
casual way they say "oh, yeah, this technique has been used since
the 1970s, Modula 2 and Ada used it, so don't think we're so
brilliant to have come up with this one".  These people know their
stuff, they know their history, they know more languages than you
think they do.  They probably know more languages than you do -
even pjmlp.  Stop assuming they're ignorant of how generics are
done in other languages.  Seriously.  Just stop it.)
 
EngineerBetter - 3 hours ago
I suspect the authors of Golang got drunk, and challenged each
other to see how many times they could get people to type 'if err
!= nil' in the next decade.
 
Xeoncross - 3 hours ago
Generics have never stopped me from building in Go... But without
them I often do my prototyping in python, javascript, or
php.Working with batch processing I'm often changing my maps to
lists or hashes multiple times during discovery. Go makes me
rewrite all my code each time I change the variable type.
 
  notheguyouthink - 2 hours ago
  It's weird, I see these complaints so often and I just.. don't..
  get it. I'm not sure what I do differently, but I'm just so used
  to Go's method of non-generic that I don't run into frustration
  at all.The only time I even notice it is if I have to write a
  method like `AcceptInt(), AcceptString(), AcceptBool()` and etc.I
  enjoy generics in Rust, I'm just not sure what I'm doing
  differently in Go that causes me to not miss them.
 
    Xeoncross - 2 hours ago
    It's possible your data (and types) are short lived.When I'm
    doing text processing for example, I pass the same
    strings/dicts/hashes through dozens of functions for cleaning,
    sorting, organising, benchmarking, comparing, etc..It's not
    just in->save->out CRUD work.
 
drfuchs - 5 hours ago
"Go 2 considered harmful" - Edsger Dijkstra, 1968
 
  masterponomo - 3 hours ago
  Beat you to it:-)https://news.ycombinator.com/item?id=3085082
 
  zeptomu - 4 hours ago
  Underrated comment. :)Haha, thanks.If there's a Go2 there will be
  a lot of these headlines for blog posts/rants.It doesn't matter
  if it is true or not, but that phrase is wonderful.
 
Xoros - 4 hours ago
It's Angular all other again... Lessons learned Google teams ?It's
complicated to decide to drop backward compatibility but, as stated
in another comment, what's the point of making a go 2 instead of a
go 1.x if it's the same ? The pleasure of advancing version number
?
 
didibus - 3 hours ago
I get that everyone would love to have a functional language that's
eager by default with optional lazy constructs, great polymorphism,
statically typed with inference, generics, great concurrency story,
an efficient GC, that compiles quickly to self contained binaries
with simple and effective tooling which takes only seconds to setup
while giving you perfomance that equals java and can rival C, with
a low memory footprint.But, I don't know of one, and maybe that's
because the Go team is right, some tradeoffs need to be made, and
they did, and so Go is what it is. You can't add all the other
great features you want and eat the Go cake too.Disclaimer: I'm no
language design expert. Just thinking this from the fact that I've
yet to hear of such a language.
 
  Tyr42 - 3 hours ago
  Sounds like you want Eager Haskell.
 
    piinbinary - 2 hours ago
    Idris is basically an eager-evaluated Haskell, with other
    niceties on top (dependent types if you want them; fixed String
    type)
 
    daww - 2 hours ago
    yes please
 
  rbehrends - 1 hours ago
  Honestly, no. For starters, I don't want a functional language
  (at least not a purely functional one). Purely functional
  programming has some distinct downsides. My preferences are
  firmly on the multiparadigm side, and I'm perfectly happy with a
  reasonable imperative language (that still supports higher-order
  functions and closures).What I'm not happy with is language
  designers seemingly ignoring the state of the art even when it
  comes to picking low-hanging fruit.
 
  nightski - 2 hours ago
  Nearly every item on your list is available with OCaml.
 
    LukaD - 1 hours ago
    I really enjoy writing OCaml but I hate all the tooling around
    it. It lacks a good package management and build system ? la
    Cargo.
 
    spyspy - 2 hours ago
    A large standard library, too?
 
    ziotom78 - 2 hours ago
    Apart from "great concurrency story", because of the well known
    problems with the GC. This might be a huge shortcoming for a
    number of people.
 
      trishume - 2 hours ago
      Multicore OCaml is in the works and is looking amazing, but
      is indeed a ways away. They're taking their time and doing it
      properly so things are fast and safe.
 
        oblio - 2 hours ago
        The thing is, until it's shipped, it's still vaporware for
        most people, especially if they want to use it in a
        commercial setting.KDE 4 was released in 2008 and it was
        supposed to be ported to Windows. We're in 2017 and KDE 5
        is still far from being considered stable on Windows. And
        I'm sure you can also think of many examples of programs
        promised and never delivered or underdelivered.
 
      rbehrends - 1 hours ago
      It isn't a great concurrency story, but the shortcomings are
      also overstated. OCaml does message-passing concurrency just
      fine and allows for shared memory for arrays and matrices of
      scalars, which is good enough for most
      scenarios.(Technically, there's also Ocamlnet's multicore
      library, but that's too low-level for most people.)
 
    cdelsolar - 2 hours ago
    Except no one's ever heard of OCaml.
 
      pjmlp - 2 hours ago
      Depends how good their CS degree was.
 
    abiox - 1 hours ago
    it's a bummer that the windows story for ocaml is so sketchy.
    i'd like to use it for work (various utilities and whatnot) but
    the ecosystem seems to make a lot of assumptions about the
    system it runs on.  (for me there's still haskell and rust at
    least.)
 
  devit - 1 hours ago
  Rust is probably what you are looking for.> a functional
  languageHas closures.Has pattern matching.Has algebraic data
  types (however variants can't have generic parameters not present
  on the data type itself, but you can use trait objects to do
  that).Functions that don't take &mut parameters, & parameters
  with types with interior mutability and don't call functions that
  do I/O are pure (although they may not terminate and may abort).>
  optional lazy constructs"Automatic" lazy costructs are usually
  unnecessary and thus almost never used, but can be implemented as
  a library using macros.Can also just use closures and call them
  explicitly.> great polymorphismHas trait/typeclass polymorphism
  with either monomorphization or dynamic dispatch.Structures can't
  be inherited, but composition gives equivalent results and is the
  proper way to do it.There have been several proposals for
  inheriting structures though, so maybe it will be available at
  some point, despite not being advisable.> statically typed with
  inferenceYep.> genericsYup.Not higher kinded, no constant integer
  parameters and not variadic yet, but those features should be
  available in the future.> great concurrency storyRust is the only
  popular language supporting safe concurrency without giving up
  the ability to share memory between threads.> an efficient GCIt
  turns out that a GC is unnecessary, and that reference counting
  is enough, which is what Rust provides (although it's still
  relatively rarely used).If you insist on a tracing GC, there
  are/have been several attempts to add it, and maybe there will be
  a mature one in the future.In particular, there is a "rust-gc"
  crate, and Servo has a working integration with the SpiderMonkey
  GC, which I suppose should be possible for others to use with
  some work.> compiles quicklyWork in progress (incremental
  compilation, more parallelization).> self contained binariesYes
  (or optionally using shared libraries).> simple and effective
  tooling which takes only seconds to setuprustup can install the
  compiler and package manager in one line.If you want an IDE,
  you'll have to install that too separately. Work in progress on
  improving IDE functionality and ease of use.> giving you
  perfomance that equals java and can rival CPerformance is at
  least theoretically the same as C since the generated assembly
  code is conceptually the same (other than array bounds checking,
  which can be opted out from with unsafe code).> low memory
  footprintSame as C.
 
  spion - 2 hours ago
  OCaml might become this once multicore happens.
 
  mhh__ - 2 hours ago
  With the possible exception of the GC, d(lang) fits those
  parameters. Including optional lazyness, performance etc.
 
fusiongyro - 5 hours ago
The paragraph I was looking for is this:> For example, I've been
examining generics recently, but I don't have in my mind a clear
picture of the detailed, concrete problems that Go users need
generics to solve. As a result, I can't answer a design question
like whether to support generic methods, which is to say methods
that are parameterized separately from the receiver. If we had a
large set of real-world use cases, we could begin to answer a
question like this by examining the significant ones.This is a much
more nuanced position than the Go team has expressed in the past,
which amounted to "fuck generics," but it puts the onus on the
community to come up with a set of scenarios where generics could
solve significant issues. I wonder if Go's historical antipathy
towards this feature has driven away most of the people who would
want it, or if there is still enough latent desire for generics
that serious Go users will be able to produce the necessary
mountain of real-world use cases to get something going here.
 
  TheDong - 5 hours ago
  The fact that go1.9 will include a "sync.Map" type which should
  be generic, but can't be due to the language's limitations should
  already answer that.See also all of the "container" portion of
  the stdlib: https://golang.org/pkg/container/All of those should
  be generic, but aren't.Clearly there's already sufficient demand
  for generic collections just based on the stdlib and the fact
  sync.Map was seen as needed.
 
    xienze - 4 hours ago
    > All of those should be generic, but aren't.They aren't
    because the prevailing attitude is "what do you need generics
    for?  Just do a cast!"The issue is the Go developers are
    unwilling to consider generics until someone can come up with a
    problem that absolutely, positively cannot be solved without
    generics.  And of course there isn't one.
 
      bpicolo - 4 hours ago
      I mean, having to cast after every single call to heap is a
      problem.Go is turing complete already, so all problems are
      already able to be solved. :)
 
    jadbox - 4 hours ago
    Agree- having map, filter, reduce with strong type guarantees
    will be a huge boon. Imagine being able to map over a
    collection and the code hints will understand the new output
    types in the chain. This is something you cannot have when your
    higher order ops are all typed to Interface {}.
 
      djur - 1 hours ago
      Unfortunately, Go is a language whose original creator is of
      the opinion that map/filter/reduce are just ways to make your
      program "fit on one line"[1], and that you should just use a
      for loop[2].[1]: https://groups.google.com/forum/#!topic
      /golang-nuts/RKymTuSC... [2]:
      https://github.com/robpike/filter
 
    jerf - 3 hours ago
    "All of those should be generic, but aren't."I think even more
    damning then "these should be generic" is that there should be
    more of them. The real problem is the lack of generics inhibits
    the introduction of more data structures because they are hard
    to use.It is true that arrays and maps/hashes take you a long
    way, but there's a lot of other useful data structures in the
    world. And despite the fact they may look easy at first, data
    structure code tends to be notoriously difficult to write both
    correctly and with high performance.
 
    maxekman - 3 hours ago
    The sync.Map case for generics is a perfect example. Thanks for
    bringing it up.
 
    piinbinary - 5 hours ago
    I'm not sure why this is being downvoted. These are perfect
    examples of where generics would make a genuine improvement.
 
  hota_mazi - 1 hours ago
  That's a charitable way to look at the comment.My more cynical
  reaction is that someone who doesn't understand the benefit of
  generics or can't even come up with examples where generics are
  superior to their alternative should not be allowed anywhere near
  a language design discussion.
 
  stormbrew - 5 hours ago
  If I were in the "go community" I would be pretty annoyed by this
  quote. I would find it dismissive of the literal years of people
  pointing at areas of their code that are bloated and less safe
  due to not having generics.It doesn't seem to me that there's a
  shortage of people pointing out real-world use cases at all, and
  I'm looking from the outside in.
 
    liveoneggs - 3 hours ago
    the use of the monotonic click example is also interesting
    because of the similar tone of responses to that issue.  I
    think it's just the rsc way.basically it goes like:  > If
    google isn't screaming about it, it's not important.  > If
    google has a workaround, then it's fixed.
 
  crawshaw - 5 hours ago
  Several members of the Go team have invested significant effort
  in studying generics and designing proposals, since before Go
  1.0. For example, Ian Lance Taylor published several of his
  previous efforts, which had shortcomings he was dissatisfied
  with.I believe your impression of the Go team's position has been
  corrupted (likely unintentionally) by intermediaries.
 
    pjmlp - 4 hours ago
    Except they seem to focus only on Java, .NET and C++,
    forgetting that generics were initially implemented in CLU back
    in 1975, and there were several programming languages since
    those days that had some form of generics being designed into
    them.
 
      vram22 - 3 hours ago
      Any thoughts on Eiffel's implementation of generics?https://e
      n.wikipedia.org/wiki/Eiffel_(programming_language)#...
 
        pjmlp - 3 hours ago
        I liked using it at the university back in the day, and
        didn't had to repeat code.Eiffel is a very powerfull
        language with good tooling, just failed adoption, because
        licenses were too expensive and software industry still has
        issues valuing quality.
 
          vram22 - 2 hours ago
          Interesting to hear your experience. I had read a good
          amount about Eiffel and also large parts of Bertrand
          Meyer's book Object-Oriented Software Construction (quite
          a thick book too, and which uses the syntax and semantics
          of Eiffel, or something close to it, IIRC [1]), some
          years ago. Had found the language very interesting and
          also was impressed by it (and by the book). Read some
          case studies / success stories about it, which were good
          too. He and his team seem to have taken a lot of pains
          and thought a lot about the design as well as
          implementation of the language, from both an academic and
          industrial use perspective - so it seemed to me.There is
          also an interesting anecdote about use of Eiffel in the
          book, here:https://en.wikipedia.org/wiki/Object-
          Oriented_Software_Const...That section shows the the 1st
          edition of the book did use Eiffel (as I said above).
 
          pjmlp - 2 hours ago
          With Eiffel tools you got the IDE with interactive
          development, including a VM for rapid prototyping. Then
          you would use the AOT compiler (via compilation to C) to
          produce shippable binaries.So combining the easiness of
          interactive development with performance when it was time
          to ship the product.It was also available before Java was
          a thing.This is what I always kind of missed with Java
          and .NET, the previous generation of languages (Eiffel,
          Modula-3, Oberon(-2)) all had a mix of interactive
          development and AOT compilation for shipping release
          builds.
 
          hota_mazi - 1 hours ago
          You seem to imply that Eiffel's solution was superior to
          Java's but nothing could be further from the truth.The
          Eiffel compiler required four distinct sequential
          processes (note: not phases. I really mean that four
          programs needed to be run in sequence, and each of these
          four programs implemented who knows how many passes).
          Eiffel generated C++, huge executables, was incredibly
          slow (even with contract stuff turned off).It was very
          hard to debug, with gdb routinely giving up on the
          complex .o generated. It was a very verbose language that
          implemented all known features under the sun, a bit like
          Ada and Scala.Eiffel didn't take off for some very solid
          reasons.
 
          vram22 - 1 hours ago
          >It was a very verbose language(Haven't worked much on
          Java recently, but did use it a fair amount some years
          ago.)Isn't Java roughly equally verbose as Eiffel?>that
          implemented all known features under the sunAt least
          based on looking at the Wikipedia article for Eiffel, it
          does not seem to have implemented functional programming,
          unless the article is out-of-date, or unless the agent
          mechanism supports FP somehow (not sure about that last
          bit).
 
          vram22 - 58 minutes ago
          >With Eiffel tools you got the IDE with interactive
          development, including a VM for rapid prototyping. Then
          you would use the AOT compiler (via compilation to C) to
          produce shippable binaries.I seem to remember that there
          was some intermediate form of language translation too -
          something called melting or freezing or some such (might
          have been two different things). This was for
          EiffelStudio, probably, not generic Eiffel stuff.>This is
          what I always kind of missed with Java and .NET, the
          previous generation of languages (Eiffel, Modula-3,
          Oberon(-2)) all had a mix of interactive development and
          AOT compilation for shipping release builds.Interesting.
          Didn't know that that generation had both. As an aside, I
          had read a good description about Modula-2 (not -3) in a
          BYTE article (IIRC, years ago), and it seemed to me at
          the time that it was a good language. Having had a good
          amount of Pascal background before doing a lot of C, I
          was interested to try out Modula-2, but probably didn't
          have access to any compiler for it at the time. Later I
          read that Delphi's feature of units for modularity may
          have been inspired by Modula-2's modules, along with the
          concept of separate compilation.
 
      masklinn - 4 hours ago
      > Except they seem to focus only on Java, .NET and C++C#
      isn't mentioned in any of the previous proposals, only Java,
      C++ and C.
 
        _old_dude_ - 1 hours ago
        C# does generics specialization at runtime, hard to do if
        you have no JIT :)
 
    sbov - 2 hours ago
    Did he compare those shortcomings with the shortcomings of not
    implementing generics at all?  Because that is the tradeoff
    here.  After decades of research, a decade of go, millions of
    lines of public and private code, a decade of feedback, and
    dozens of languages with generics, it's obvious that the
    perfect generic system isn't going to just happen, so it's not
    perfect generics vs imperfect generics, it's no generics vs
    imperfect generics.
 
    kyrra - 4 hours ago
    Link to top-level proposal: https://github.com/golang/proposal/
    blob/master/design/15292-...If you scroll to the bottom, you
    can see 4 large proposals written by Ian over the years.
 
    wwweston - 3 hours ago
    While "fuck generics" might be a low-resolution
    characterization, it's not entirely inaccurate, and the efforts
    of Taylor (and perhaps others) notwithstanding, as long as
    anyone is writing things like "I don't have in my mind a clear
    picture of the detailed, concrete problems that Go users need
    generics to solve," there's reason to believe it's apt
    enough.As other respondents to the GP comment show, it's not at
    all hard to come up with that ostensibly elusive picture if
    you're attending to it. So I suppose the obvious takeaway is
    that they're still not really attending to it. Which is fine,
    Go clearly has its niche and its fans, and people who don't
    want a pretty good Blub have other options.
 
  callesgg - 5 hours ago
  Not having generics makes it hard to do proper type safe
  functions and libraries.My specific problem when i realized it
  was an actual problem was when i tried to connect to a sql
  databse and working with a proper ORM.
 
    weberc2 - 4 hours ago
    Why does an ORM need generics? I ask because I've built
    something very like an ORM in Go and I didn't have any problem
    without generics. ADTs on the other hand...
 
      callesgg - 3 hours ago
      In my specific case it was the fact that i could not have one
      insert function or one update function.I would need one for
      each and every struct(table).These days there is a tool that
      can generate all those struct methods:
      https://github.com/vattle/sqlboilerSo from the ORM
      perspective we (as the community) have worked around it.
 
        weberc2 - 2 hours ago
        I guess I don't see how generics would help you reduce the
        number of insert/update functions. The basic problem of an
        ORM is to map struct fields to columns; I don't see how
        generics would help you here. Can you write the generic
        pseudocode you want to write?
 
        slantedview - 2 hours ago
        The idea that we don't need generics because we can
        generate code is kind of ridiculous, and certainly doesn't
        pass the simplicity smell test.
 
          weberc2 - 2 hours ago
          He wasn't making that argument...
 
        staofbur - 3 hours ago
        This is incidentally where .Net was around the 1.1 release
        (2003ish) We had code generation frameworks kicking out
        swathes of boiler plate.Now Repository and for us around
        200,000 lines of code are gone and only one narrow set of
        tests to execute.
 
      steveklabnik - 2 hours ago
      The strongest typed ORM I've ever used is
      http://diesel.rs/This code (okay I made the use line up
      because it's not on the website and I'm lazy, you do need one
      though):  use some::stuff::for::the::dsl;      let versions =
      Version::belonging_to(krate)       .select(id)
      .order(num.desc())       .limit(5);   let downloads =
      version_downloads       .filter(date.gt(now - 90.days()))
      .filter(version_id.eq(any(versions)))       .order(date)
      .load::(&conn)?;  is completely, statically typed,
      with zero runtime overhead. Generics + type inference makes
      sure that everything is valid, and if you screw it up, you
      get a compiler error (which honestly are not very nice at the
      moment).Thanks to generics, all of this checking is computed
      at compile time. The end resulting code is the equivalent of
      let results = handle.query("SELECT version_downloads.*
      WHERE date > (NOW() - '90 days')       AND version_id = ANY(
      SELECT id FROM versions           WHERE crate_id = 1
      ORDER BY num DESC           LIMIT 5       )     ORDER BY
      date");  but you get a ton of checking at compile time. It
      can even, on the far end of things, connect to your database
      and ensure things like "the version_downloads table exists,
      the versions table exists, it has a crate_id column, it has a
      num column", etc.You can absolutely create an ORM _without_
      generics, but it cannot give you the same level of guarantees
      at compile time, with no overhead.
 
        weberc2 - 2 hours ago
        Ah, I think the bit where generics is useful is in making
        sure the value types are consistent (i.e., that you're not
        building a query that subtracts an int from a string or
        compares a date to a bool). This still doesn't guarantee
        that the types will match with the database columns, but it
        is a step up from the non-generic alternative.
 
          hinkley - 57 minutes ago
          I keep meaning to pick up Rust, still looking for some
          entry point that's interesting enough to get me off my
          butt.How (well) does diesel deal with migrations?  I've
          seen other ORMs fall down the stairs trying to deal with
          schema modification over time.
 
          weberc2 - 41 minutes ago
          I think you meant to respond to Steve. I'm not a Rust
          guru (I keep trying it, but I don't have any applications
          for which it's reasonable to trade development time for
          extreme performance). I definitely don't know anything
          about diesel.
 
          steveklabnik - 2 hours ago
          It can check that they match with the columns, yeah.It
          also heavily relies on generic types to ensure that
          everything is well-formed, and to provide zero overhead.
 
          weberc2 - 44 minutes ago
          How does the compiler know the types of the database
          columns?  That information has to come from somewhere.
          Also, type checking is negligible from a performance
          perspective, so I the "zero overhead" is of minimal
          interest.
 
  zerr - 5 hours ago
  They should look up the usage of empty interfaces [in the wild or
  in-house].
 
    munificent - 5 hours ago
    This is a great point. Other analysis one could do:1. Look at
    uses of cast operators in a codebase. How many of those would
    be eliminated by making the surrounding operation generic?2. Go
    through the language spec and see how many features could be
    moved out of the language and into the core library if generics
    were supported.
 
  saghm - 4 hours ago
  I haven't programmed in Go, but from what I understand, Go's
  explicit error handling isn't enforced by the type system, as you
  can leave off an `if err { ... }` check and everything still
  compiles. I think adding a generic result/error type (like the
  Result type in Rust or the Either type in Haskell) would be a
  pretty useful feature, as currently the error handling sits in
  kind of a weird place between forced handling and traditional
  exceptions.
 
    the_duke - 3 hours ago
    I have no idea why you are being downvoted.In Rust, this was
    handled the right way. The Result type forces you to at least
    actively dispose of the error.In Go, it's just way too easy to
    leave an error unhandled.
 
      kibwen - 40 minutes ago
      > The Result type forces you to at least actively dispose of
      the error.Sort of: by default, an unused value of the
      `Result` type produces a compiler warning. Like all warnings
      in Rust, this category of warnings can be promoted to a hard
      error for all users with a single line of code. And unlike
      other languages where compiler warnings are uniformly
      ignored, there is a strong culture in Rust of making sure
      that code compiles warning-free (largely due to the fact that
      the compiler is rather selective about what to issue warnings
      about, to help avoid useless false positives and warning spew
      (there is a separate project, called "clippy", for issuing
      more extensive warnings)).
 
    imsofuture - 4 hours ago
    Go's errors are really nice (if a bit repetitive) in my
    opinion. Type signatures enforce that you accept and
    acknowledge an error returned from an invocation, but leave it
    up to you to handle, pass along, or silently swallow.
 
      hdhzy - 3 hours ago
      So... Just like checked exceptions in Java?
 
        baq - 1 hours ago
        yeah but better because you don't break the world if you
        add a new exception to a public method.
 
        imsofuture - 2 hours ago
        Yes, it's somewhat similar in that the compiler checks if
        you have handled or chosen not to handle an error. You're
        not allowed to ignore it (through omission).
 
      acdha - 3 hours ago
      Does that mean it now throws an error if you use the common
      punt like `foo, _ := ?` and never check `_`?
 
        imsofuture - 2 hours ago
        No, but that's what I mean as intentionally ignoring.
 
        growse - 2 hours ago
        No, because using `foo, _` you're explicitly saying that
        you don't care about the error.
 
  tomovo - 5 hours ago
  Go 2, codename "Hell with generics". Just kidding of course. I am
  sure some useful form of generics will eventually find its way
  in.
 
    vram22 - 2 hours ago
    "2 Hell with generics", or "Go 2 Hell with generics"/jk 2
 
    tomovo - 5 hours ago
    More importantly though, looking at C++ I think it may be hard
    to come up with a generics system that doesn't lend itself to
    abuse and ridiculous mega constructs. I would love to see
    something that provides power in ways that disallow craziness
    (Boost Spirit kind) but provide enough power to avoid all the
    cases that suffer without generics.
 
      twblalock - 4 hours ago
      The craziness is preferable to passing void* or Object or
      Interface{} everywhere. At that point, you might as well use
      a language without strong typing, for all the safety you're
      going to get. You can end up with just as much craziness with
      void* and Object and Interface{}.The Go team needs to stop
      trying to control what people do with their language. If
      people come up with crazy implementations, it's their own
      problem. It's up to the Go community to provide alternatives
      to prevent those crazy implementations from becoming
      standardized in Go programming culture. Refusing to implement
      generics because programmers might abuse them is
      paternalistic and counterproductive.
 
        tumdum_ - 3 hours ago
        Using interface{} you never get implicit/silent conversion,
        so Go type system is strong (and static obviously). It just
        lack parametric polymorphism.
 
        tomovo - 3 hours ago
        "If people come up with crazy implementations, it's their
        own problem."Some people are turned away from C++ after
        seeing random bits of crazy language/template misuse,
        although when used sanely C++ could've served them nicely
        for their job.Same thing is going to happen to Swift very
        soon.https://engineering.kitchenstories.io/comfortable-api-
        reques...Those function signatures are definitely not...
        self-documenting, I'd say.
 
          dbaupp - 2 hours ago
          Those signatures seem complicated to me because there's a
          pile of arguments and some of them are functions with
          extra annotations, not because there's generics involved.
          The equivalent signatures using interface{} (or maybe
          something more precise) would be likely just as noisy, if
          not more so.
 
      eropple - 5 hours ago
      Both C# and Java have taken different approaches to
      constrained generics that are still really useful for
      about...I dunno, the 90% case (C# has reified generics and so
      it's more like 95%, but type erasure also has its pluses when
      you're off-roading around in a framework somewhere). Scala
      goes a little further and covers, like, the 99% case, and
      plenty of inadvisable ones too.
 
      int_19h - 4 hours ago
      C++ doesn't have generics, it has templates, which are
      effectively a syntax-constrained form of macros. That's why
      it lends itself to abuse (or creative use, depending on your
      take on macros).
 
        tomovo - 3 hours ago
        So C++ generates separate code for each template type and
        C# and Java do a typecheck at compile time and reuse the
        same codepath for all types at runtime?
 
          pjmlp - 3 hours ago
          .NET does a mixture of C++ and Java, meaning generic
          instatiations for value types get their own version of
          the code, instatiations  for reference types get a shared
          version.
 
          int_19h - 2 hours ago
          It's worth noting that in case of C#, it's really an
          implementation detail. It could just as well share all
          instantiations by boxing and adding a bunch of runtime
          checks - the language semantics wouldn't change because
          of it.In C++, on the other hand, separate compilation of
          template for each instantiation is effectively part of
          language semantics, because it has numerous observable
          effects.
 
          [deleted]
 
  HarkMamilton - 5 hours ago
  I think this is too little, too late. Anyone who saw an advantage
  to using generic programming is already using something else.
  They've already invested resources in something besides Go; why
  spend the effort to switch back for what will, at best, probably
  be very mediocre support for parametricity compared to whatever
  they're already using?
 
    cat199 - 5 hours ago
    This presumes that:a) generic programming is a new thingb) any
    of those people you mention aren't using go for some things and
    other things where this feature is desiredc) that the feature
    will 'at best' be at level Xd) that level X won't be enough to
    satisfy some use casesand a whole host of other things, not
    least of which the fact that go itself was invented to suit
    some purpose after other languages existed, and has been
    successful for many users
 
    matthewowen - 4 hours ago
    Most of the projects which will use Go have not begun yet.
    Adding support means people may use Go for those future
    projects.
 
      resf - 2 hours ago
      The opposite side of that coin is that other programming
      languages do already exist.Any new language is already
      playing catch-up to reach the state of the art. Go is 10
      years old and in those 10 years has made astonishingly little
      progress at implementing basic features such as error
      handling, because the designers cannot escape their
      bubble.The most sensible thing to do is to kill Go, not to
      improve it. The root problem is not the lack of this or that
      feature, but the bizarre beliefs of the people running the
      project.
 
        johnwilkesbooth - 2 hours ago
        > The most sensible thing to do is to kill Go, not to
        improve it.Care to expand this? It's pretty clear that you
        don't find Go suitable for your own use cases, but I've
        found it to be an extremely productive language, despite
        the fact that it may have a couple of warts.
 
  untog - 4 hours ago
  It strikes me as a pretty odd statement, though. I'll admit that
  I'm not very familiar with Go, but surely you can look back at
  the benefits of generics in other languages? Go is hardly so
  specialised that you can't learn a single lesson from elsewhere.
 
    Touche - 4 hours ago
    I agree, I didn't find the statement refreshing at all, I found
    it insulting. You damn well know the use-cases for generics. If
    you still don't like it; fine, say that explicitly. Don't
    pussyfoot around it and play the "we just don't know that much
    about it yet" lie.
 
  coldtea - 4 hours ago
  >This is a much more nuanced position than the Go team has
  expressed in the past, which amounted to "fuck generics," but it
  puts the onus on the community to come up with a set of scenarios
  where generics could solve significant issues.It seems to me to
  be the same "Generics is some foreign concept we just heard of,
  and we're not sure how to implement them in Go yet, but we'll
  consider it if we chance upon some magical optimal way" that has
  been the official party line of Go since forever...Even the "we
  are asking you for proposals" part has been there since a decade
  or so...
 
  [deleted]
 
  vec - 1 hours ago
  I'm not even a Go developer, I just played with it a bit a couple
  of years ago and used it for a small one-off internal API thing,
  and I can think of a dozen real-world use cases for generics off
  the top of my head.  * type-safe containers (linked lists, trees,
  etc.)   * higher order functions (map, reduce, filter, etc.)   *
  database adapters (i.e. something like `sql.NullColumn`
  instead of half a dozen variations on `sql.NullWhatever`)   * 99%
  of functions that accept or return `interface{}`  I appreciate
  that they seem open to the idea for v2, but "the use case isn't
  clear" is absurdly out of touch with the community. Using
  `interface{}` to temporarily escape the type system and
  copy/pasting functions just to adjust the signature a bit were
  among the first go idioms I learned, and they both exist solely
  to work around the lack of generics.
 
  slantedview - 3 hours ago
  The idea of needing to come up with use cases for generics is
  baffling. The existence of generics in numerous other languages
  already support of plethora of use cases. I really don't get that
  statement at all.
 
    43224gg252 - 1 hours ago
    Then why don't you come up with a legitimate use case?
 
  wheaties - 5 hours ago
  If they want to "learn" about generics perhaps they can read the
  literature of the past 30yrs and look at how other languages have
  adopted those learnings: Java, C#, Haskell, OCaml and Coq.Look,
  even allowing type aliases to become part of an interface
  declaration would be a HUGE win. You can't currently write
  portable arbitrary data structures without reimplementing them
  with a code generator. Ugh!
 
    pjmlp - 4 hours ago
    You forgot CLU in 1975. :)
 
    seanwilson - 4 hours ago
    > If they want to "learn" about generics perhaps they can read
    the literature of the past 30yrs and look at how other
    languages have adopted those learnings: Java, C#, Haskell,
    OCaml and Coq.Yeah, I find it strange how languages are
    trending at a glacially slow pace to having the same features
    that strongly typed functional programming languages have had
    for literally decades. It's like we're going to be using actual
    functional programming languages eventually but the only way
    it'll happen is to very slowly change what everyone is
    currently using in small steps.Static types, immutability, type
    inference and non-null variables are popular design choices
    right now but they've been  in functional programming languages
    for nearly 50 years. I'm still waiting for inductive types and
    pattern matching to turn up in a mainstream language and seeing
    them talked about like they're new concepts.
 
      JBReefer - 4 hours ago
      C# is adding pattern matching in the upcoming release, and to
      your point, people are acting like it's the new hotness.
 
        masklinn - 4 hours ago
        That's not exactly surprising, the C# community has been
        doing that since the beginning of the language, anything
        not in the language is pointless academic wankery, and as
        soon as Microsoft announces it it's the best innovation in
        computing history since Microsoft was created.Source: got
        to interact with the community between the C# 1.0 and 4.0
        releases (2.0 added generics, 3.0 added lambdas, neither
        feature was considered of any use to a Productive Developer
        up to the day when Microsoft officially announced them).
 
          hinkley - 1 hours ago
          Clearly they finally learned the lessons of Apple.  Old
          is busted, new is perfect.(says a man planning to
          purchase his 5th Macbook Pro later this year)
 
          seanmcdirmid - 3 hours ago
          > That's not exactly surprising, the C# community has
          been doing that since the beginning of the language,
          anything not in the language is pointless academic
          wankery, and as soon as Microsoft announces it it's the
          best innovation in computing history since Microsoft was
          created.That isn't true inside Microsoft. Many of the
          people who work on C# are the same academic wanks that
          work on Scala or F#. C# has a different user base from
          those languages though, so they still have to be careful
          what they add to the language, and many language features
          are planned 3 or 4 versions in advance.
 
          masklinn - 2 hours ago
          > That isn't true inside Microsoft.No, that was not
          intended as included in "the C# community". Hell, SPJ
          used to work at Microsoft (he may still do, but he used
          to).> the people who work on C# are the same academic
          wanks that work on Scala or F#I'm sure you mean wonks,
          but I liked the typo.> C# has a different user base from
          those languages though, so they still have to be careful
          what they add to the language, and many language features
          are planned 3 or 4 versions in advance.I have no issue
          with the evolution of C# rate or otherwise, only with a
          number of its users.
 
        seanmcdirmid - 3 hours ago
        It is new to C#, which is slowly catching up to Scala and
        F# in that regards. Mads Torgesen is good friends with
        Martin Odersky, in fact, when I first met Mads back in 2006
        or so, they were talking about adding pattern matching to
        C#. C# is a much more conservative language, and it makes
        sense it would take a while to add.There are good reasons
        to use C#, so when it gets a new feature that other
        languages have had for years, well, it is newsworthy.Now
        when will javascript get pattern matching?
 
          dvlsg - 2 hours ago
          There's a proposal for it! Stage 0? Stage 1? Don't
          remember what stage it's in off the top of my head, but
          it looks promising.
 
          _old_dude_ - 57 minutes ago
          There is a paper, Pizza into Java: Translating theory
          into practice, from Odersky and Wadler at POPL 97 about
          how to mix generics, lambda and pattern matching in a
          Java like language.C# and Java are slowly catching up :)
 
          herrschnapps - 2 hours ago
          It's just become a Stage 0 proposal:
          https://github.com/tc39/proposal-pattern-matching
 
      masklinn - 4 hours ago
      Surely if Go is considered mainstream so is Swift?
 
    [deleted]
 
    masklinn - 5 hours ago
    > perhaps they can read the literature of the past 30yrs40,
    nearing on 45:> Milner, R., Morris, L., Newey, M. "A Logic for
    Computable Functions with reflexive and polymorphic types",
    Proc. Conference on Proving and Improving Programs, Arc-et-
    Senans (1975)
 
      endymi0n - 4 hours ago
      Guess what: they
      did.https://news.ycombinator.com/item?id=8756683They just
      weren't ready to make any of the significant tradeoffs other
      languages have to do in order to support them.Whether that's
      a good outcome, I'm not fully sure - but there's definitely a
      lot of research in that area.
 
        pcwalton - 4 hours ago
        The basic tradeoff is monomorphization (code duplication)
        vs. boxing (in Go speak, interface{}). The problem with
        saying "well, this is a tradeoff and both sides have
        downsides, so we won't do anything" is that the tradeoff
        still exists?it's just something that manually has to be
        done by the programmer instead of something that the
        compiler can do. In Go, the monomorphization approach is
        done with code duplication (either manually or with go
        generate), while the boxing approach is done with
        interface{}. Adding generics to the language just automates
        one or both of the approaches.The idea that the
        monomorphization/boxing tradeoff can be dodged by not
        having generics in the language is a fallacy. In Go, today,
        you as a programmer already have to decide which side of
        the tradeoff you want every time you write something that
        could be generic. It's just that the compiler doesn't help
        you at all.
 
          willtim - 3 hours ago
          In Haskell (and I believe Scala), one can use pragma
          hints to specify to the compiler when to specialise, if
          performance becomes a problem. So I don't see this as an
          argument against parametric polymorphism.
 
          masklinn - 4 hours ago
          > The basic tradeoff is monomorphization (code
          duplication) vs. boxing (in Go speak, interface{}).And
          even that is not the whole story, just because you reify
          generics does not mean you have to monomorphise
          everything, Microsoft's C# compiler only monomorphises
          value types.Also Go may box in other contexts than
          interfaces depending on escape analysis (according to
          https://golang.org/doc/faq#stack_or_heap).
 
          slavapestov - 2 hours ago
          > The basic tradeoff is monomorphization (code
          duplication) vs. boxing (in Go speak, interface{}).There
          is also the approach taken by Swift, where values of
          generic type are unboxed in memory, and reified type
          metadata is passed out of band. There's no mandatory
          monomorphization.
 
          [deleted]
 
          dbaupp - 2 hours ago
          The Swift approach shares many of the same
          characteristics and trade-offs as "true" (aka Java-style)
          boxing. Of course, it does avoid some downsides of that,
          but also brings along some additional ones.
 
          slavapestov - 1 hours ago
          I think the main difference is that the Swift approach
          ends up being more memory-efficient, eg consider Swift's
          Array is stored as an array of integer values
          compared to a Java's ArrayList where each
          element is boxed.Also the Swift optimizer can clone and
          specialize generic functions within a module, eliminating
          the overhead of indirection through reified metadata.
 
          dbaupp - 1 hours ago
          Yes, there's some pitfalls of Java that Swift avoids,
          like compulsory allocation, but it fundamentally has the
          same style of indirection (often pointers to stack memory
          rather than heap, but still pointers), type erasure and
          pervasive virtual calls, and brings with it even more
          virtual calls due to needing to go through the value
          witness table to touch any value (which might be
          optimised out... or might not, especally with widespread
          resilience).The compiler specializing/monomorphizing as
          an optimisation shows that Swift has a hybrid approach
          that tries to balance the trade-offs of both (like many
          other languages, like Haskell, and, with explicit
          programmer direction, Rust), but the two schemes still
          fall into the broad categories of monomorphizing vs
          dictionary passing, not something fundamentally
          different.
 
          pcwalton - 2 hours ago
          Really by "boxing" I mean "dictionary passing" (I've also
          seen the term "intensional type analysis" for it). That
          encompasses approaches like Java as well as those of
          Swift.Hybrid approaches in which the compiler (or JIT!)
          decides whether to monomorphize or use vtables are also
          possible.
 
          slavapestov - 1 hours ago
          "Dictionary passing" is a good term for this
          implementation strategy, I haven't heard it named before.
          Do you know of any other languages that take a similar
          approach?
 
          dbaupp - 1 hours ago
          Haskell and Ocaml, e.g.
          http://okmij.org/ftp/Computation/typeclass.html .
 
          vram22 - 3 hours ago
          >monomorphizationDoes that mean writing a separate
          version of an algorithm for each type or types that you
          want it to handle? Like a sort for ints, a sort for
          floats, etc., even if the logic is otherwise the same (or
          almost)?Not a PL design or theory expert, just
          interested.
 
          pcwalton - 3 hours ago
          Yes, it means specializing the code and generating a
          separate version of the function for each type it is
          instantiated with.
 
          vram22 - 2 hours ago
          Got it, thanks.
 
        masklinn - 4 hours ago
        > Guess what: they did.Yeah as pointed out in that very
        thread by pjmlp:    As usual, it lacks discussion about
        generics in:     Eiffel     Ada     Modula-3     D
        MLton     .NET     Rust     Haskell     OCaml     Sather
        BETA     CLU  Oh wait, they're pointing out that none of
        these is even remotely being discussed in the article
        hinting that they did not, in fact, and much prefer taking
        down strawmen they built from some sort of daguerreotypes
        of Java and C++.> They just weren't ready to make any of
        the significant tradeoffs other languages have to do in
        order to support them.Ah yes, the ever so convenient but
        never actually clarified "tradeoffs", which only ever
        happen for generics but oddly enough apparently don't
        happen for any other feature.> there's definitely a lot of
        research in that area.That there is, would be nice if Go's
        designers ever bothered actually using it.
 
  solomatov - 5 hours ago
  I would start using Go in my projects if it introduces generics.
  It's a show stopper for me.
 
    treehau5 - 3 hours ago
    Conversely, I would stop using Go in my projects if it
    introduces generics.If Go wants to be more sophisticated, there
    are other sophisticated languages I can use out there like
    Haskell, Rust, F#, Scala, etc. The problem I have learned in my
    career is "sophistication" usually gets in the way of getting
    things done because now you have all these clever developers
    full of hubris creating these novel implementations that nobody
    else in the world understands, and your project fails but hey
    -- at least you have a dope, terse, generic implementation --
    totally rad.
 
      slantedview - 3 hours ago
      > Conversely, I would stop using Go in my projects if it
      introduces genericsDepending how they're implemented, you
      might not have to use them (even via libraries). Not using
      the language altogether is a bit dramatic.
 
        erikpukinskis - 1 hours ago
        That's never really true, because using a language means
        using other people's libraries, and using libraries means
        debugging and extending them, so you eventually end up
        needing to work with anything the language can serve
        up.This is my beef with JavaScriot these days... They
        introduced a slew of new, in my opinion insane, control
        structures, and while I can avoid them in my code, they are
        still slowly polluting my dependencies, and adding obscure
        runtime requirements for my projects.
 
      Daishiman - 2 hours ago
      So you'd rather take a half-dozen, half-assed implementations
      of templates, macros, flaky cast-to-interface things and a
      bunch of incompatible weirdness rathern than a singular,
      reasonably effective pattern that's been proven successful
      over literally hundreds of programming languages?
 
    Spiritus - 4 hours ago
    The question is _why_ do you need generics, for what use
    case(s), etc? Saying ?I need generics otherwise I won?t use Go?
    is exactly the type of feedback they don?t want.It seems like
    you?d have valuable feedback given that it?s a ?showstopper?
    for you.
 
      abiox - 4 hours ago
      > for what use case(s)i almost feel this is like asking
      bjarne what use cases there are for 'classes' in c-with-
      classes.  it's a structural language change that (depending
      on implementation details) can have sweeping ramifications on
      how one writes code.type parameterization allows for the
      expression of algorithms, idioms and patterns wholly or
      partially separate from concrete type details.  i'm sure
      others can better sell the topic though.
 
      [deleted]
 
      littlestymaar - 3 hours ago
      Not the GP, but you can think about generics as a better kind
      of interfaces :- performance wise: no dynamic dispatch, means
      no virtual function call, means faster code.- type safety:
      let say I want a data structure that can store anything but
      everything in it must be the same type. You just can't do
      that with Go's current type system without introspection
      (which is cumbersome and really slow).Generics already exists
      in Go : maps, slices and channels and generic, and it was
      mandatory for performance reason. The problem of not having
      generics is that the community can't build its own
      implementation of useful data structures : for instance,
      until the last release Go lacked a thread-safe map. That's
      fine, let's use a library for that ? Nope, can't implement
      that because, ?no generics?.Generics are rarely useful in
      your own code, but they allow people to create good
      abstractions in their libraries. Without generics, the
      ecosystem growth is limited.
 
        brandonbloom - 2 hours ago
        > you can think about generics as a better kind of
        interfacesNo, you can't, because generics don't provide the
        key feature of interfaces: run-time dynamism.You could make
        a case that static polymorphism and dynamic polymorphism
        could be accomplished by a single mechanism, as traits do
        in Rust, but you can't say generics are "better" than
        interfaces, since they solve a different set of problems,
        with different implementation strategies, despite related
        theoretical foundations.> The problem of not having
        generics is that the community can't build its own
        implementation of useful data structuresThis is not true
        either, although it is true that it is harder to do this
        sort of thing in Go, the result may in fact not be as fast
        as you can achieve with monomorphisation, and you may have
        to write more code by hand.The "trick" is the Go model is
        to provide an interface (which yes, potentially
        unnecessarily uses a dynamic mechanism) to implement
        indirect operations. For example the Swap function of
        https://golang.org/pkg/sort/#Interface enables
        https://golang.org/pkg/container/heap/#Interface - which is
        a reusable data structure. Compiler-level static-generics
        for slices and arrays, combined with indirecting through
        array indexes, enables you to avoid boxing when
        instantiating the heap interface. The data structure can be
        instantiated with an interface once, so there is no dynamic
        lookup for heap operations, but there is still a double
        indirect call.Yes, this is less convenient than proper
        generics, but this doesn't mean you can't do these
        things.Furthermore, I've never actually needed to do this
        outside of sorting (which is, absolutely, is annoying) in
        large projects. Almost every time I need a specialized data
        structure, I usually need it for performance reasons, and
        so hand-specializing for my needs tends to be worthwhile
        anyway.> Generics are rarely useful in your own code, but
        they allow people to create good abstractions in their
        libraries.I'd like to see something like templates or
        generics for Go, but I definitely don't want Java-style
        "fake" generics without code specialization. Furthermore, I
        found that the vast majority of generics-heavy libraries
        back in my C# days were more trouble than they are worth,
        despite meaningful opportunities for better performance
        with value types. Copy/paste almost always resulted in a
        better outcome.
 
      xenadu02 - 3 hours ago
      Create an ordered set or bloom filter type for Go and let us
      know how you make out.
 
      slantedview - 3 hours ago
      > The question is _why_ do you need genericsWhy do we need
      anything beyond assembler?
 
      Touche - 4 hours ago
      Do you not see how this is an insulting question? You know
      very well the use cases for generics. You do not need users
      to present new ones. You can literally Google "generics use
      cases" and get hundreds of thousands of results that directly
      answer that question.
 
        Spiritus - 4 hours ago
        Did you even read the blog post? Such feedback was
        explicitly asked for.
 
          AaronFriel - 4 hours ago
          I think the problem everyone has swallowing that ask is
          that the value of generics is that it's so widely taught,
          with so many use cases, and so much literature (academic
          and otherwise) that the suggestion that they need use
          cases is laughable.What use cases do they need other than
          the extremely large body of public knowledge on the
          matter, and why would one more example change anyone's
          mind?To me this represents the epitome of the insular and
          outwardly hostile attitude that the Go team has toward
          good ideas elsewhere in the CS world. Would it really
          make a difference to the team if I or anyone else were to
          hunt down specific examples and present them with
          problems solved with generics and stronger type systems?I
          doubt it.
 
          weberc2 - 4 hours ago
          Off topic, but any chance UNI is your alma mater? I think
          we may have been there at the same time, judging by your
          name and some of your comments.
 
          lomnakkus - 4 hours ago
          Asking for use cases when the use cases and benefits are
          already well-known seems pretty disingenuous to me. (Of
          both you and the blog post.)... but, hey, just to indulge
          you, a few off the top of my head:- Generic containers in
          libraries (aka not built-in)- Parametricity to restrict
          user-supplied implementations of interfaces; not quite as
          valuable in a language with casts, etc., but still
          reasonably valuable.- To give a sound account for the
          currently-magic built-in types.That should be enough,
          frankly, but I'm sure I could come up with more if I were
          to spend 5 more minutes on it...Can we stop pretending
          that they don't know of any compelling use cases now?
 
          Spiritus - 4 hours ago
          I was merely suggesting to indulge the author, especially
          now that generics might actually happen.
 
          cyphar - 1 hours ago
          The problem is that the community did indulge the author
          and the other Go maintainers 5 years ago and their was an
          apparent refusal to see lack-of-generics as an issue,
          almost as though Turing-completeness was sufficient
          justification to not include them."Find us examples and
          show us so we can ponder this further" is incredibly
          condescending after we did that 5 years ago and they
          decided to stall (or to use the author's term, "wait") on
          the issue. Honestly I think it might be too late for
          generics to be added, because the large body of existing
          interfaces aren't generic and likely would have a very
          high transition cost.
 
      coldtea - 4 hours ago
      Because I like both reusable implementations of algorithms
      across compatible types AND type safety.It's not rocket
      science.And because it's 2017.
 
      the_mitsuhiko - 4 hours ago
      The benefits of generics are well understood.
 
        Spiritus - 4 hours ago
        So why is he requesting feedback on the matter?
 
          AaronFriel - 4 hours ago
          Bad faith.
 
    nemo1618 - 4 hours ago
    You might be interested in my side project:
    https://github.com/lukechampine/plyIt's a small superset of Go
    that allows you to call map/filter/reduce methods on any slice.
    It's not true generics (you can't define your own generic
    functions or types) but it covers the most common use case for
    me: declarative data processing.
 
    Shorel - 3 hours ago
    What do you use?
 
  kccqzy - 1 hours ago
  Generics in Go:
  https://twitter.com/snoyberg/status/882255351382462464
 
  xienze - 5 hours ago
  > This is a much more nuanced position than the Go team has
  expressed in the past, which amounted to "fuck generics," but it
  puts the onus on the community to come up with a set of scenarios
  where generics could solve significant issues.Nah, this is pretty
  much the same answer they've been giving all along, lots of
  handwaving about how generics are so cutting edge that no one can
  figure out how to use them effectively yet ("we just can't wrap
  our heads around this crazy idea!")In other words, don't count on
  them in Go 2.
 
  pjmlp - 4 hours ago
  I would already be happy if they supported generics like CLU did
  in 1975, no need for nothing too fancy.
 
  kernelbandwidth - 3 hours ago
  The request for use cases in Go seems a bit like begging the
  question to me. Since Go doesn't have generics, anything designed
  in Go will necessarily take this into account and design around
  this lack. So it's relatively easy to show that Go doesn't have a
  compelling use case for generics, since the designs implemented
  in Go wouldn't (usually) benefit from generics!Rust has generics
  and traits/typeclasses, and the result is my Rust code uses those
  features extensively and the presence of those features greatly
  influences the designs. Similarly, when I write Java, I design
  with inheritance in mind. I would have trouble showing real world
  use cases for inheritance in my Rust code, because Rust doesn't
  have inheritance and so the designs don't use inheritance-based
  patterns.Essentially, how does one provide real world evidence
  for the utility of something that's only hypothetical? You can't
  write working programs in hypothetical Go 2-with-generics, so
  examples are always going to be hypothetical or drawn from other
  languages where those tools do exist.
 
    erikpukinskis - 1 hours ago
    This suggests that both generics and inheritance are
    unnecessary.
 
      kccqzy - 1 hours ago
      It only suggests you can't easily give an example because the
      language is forcing a design where such things aren't needed.
      Sort of like linguistic relativity.
 
        XorNot - 18 minutes ago
        Which still proves the parent's point: it's not necessary.
        The question is what absolutely can't be done without them
        (probably nothing) so a better question is how much
        design/engineering/test time could be saved with them?On
        the latter part I'm fairly cynical these days, since I'm
        presently on a team where the lead embraced a Scala-DSL
        heavy, functional design and the net result has been a
        total loss of project velocity because when we need to
        prototype a new requirement, the push back has been
        paraphrasing "oh, could you not do that in 
        and handle it somewhere else?" - so we end up with a bunch
        of shell scripts cobbled together to do so.
 
nickbauman - 4 hours ago
Will there be gotos in Go 2? Asking for a friend.
 
  Siecje - 48 minutes ago
  They are in Go 1 and Go 2 will be backward compatible, so yes.
 
alexandernst - 5 hours ago
How about fixing all the GOPATH crap?
 
  kzisme - 4 hours ago
  I'm also curious as to what issues you have come across with
  GOPATHS
 
    frik - 4 hours ago
    Multiple unrelated Go projects in different repos located in
    different directories.No problem at all with very other
    language, except with Go - not possible!I want to open cmd.exe
    (Win) or bash (Linux) and cd to the directory and build. And
    not configure a GOPATH in the environment variables of the
    current user or pretend it to the batch script, set it in
    IntelliJ Go plugin, etc. It so unflexible, so arkward, and
    there is no reason for this crap at all. So please fix it for
    Go 2. Thx
 
      kzisme - 3 hours ago
      This is the sort of thing that makes it hard to get started
      with Go in my opinion.
 
        cdelsolar - 2 hours ago
        It shouldn't be. Set the GOPATH once and use any text
        editor.
 
          Spiritus - 1 hours ago
          Except you have to set it every time you open a shell.
          You can?t put it into your .bashrc either unless you only
          ever work on one project. This workflow sucks:    $ cd
          projects/foo     $ export GOPATH=$PWD     $ cd
          src/github.com/company/foo     $ go build
 
          cdelsolar - 1 hours ago
          OP was talking about getting started. I also don't
          understand why you can't use the same GOPATH across
          multiple projects, especially with godeps?
 
      baq - 3 hours ago
      make still works. I don't go build, I make build. Yes, you
      have to set it up for each project, but only once.Give me
      cargo for go either way.
 
  tschellenbach - 4 hours ago
  We've worked around it like this and it works pretty well:
  https://github.com/getstream/vg
 
    notheguyouthink - 2 hours ago
    I'm so undecided on using GOPATH like that. Though, I may just
    do it.Personally I hate Go's imports, and I think the GOPATH is
    a terrible, terrible idea. Yet, I quite like the vendor
    directory, and I expect the new `dep` tool to be the final
    touch.Now my only problem is that I often forget which projects
    of mine are in my GOPATH, so I'm afraid to delete them -_-
 
      stubish - 1 hours ago
      vendor has big problems too. There are some proposals on how
      to start fixing them, after the dep tool lands (originally
      slated for 1.7 or 1.8 but still in Alpha?)To support the
      uncommon edge case, src/foo/vendor/dep is completely
      different to src/bar/vendor/dep.Your src/foo code can't pass
      src/foo/vendor/dep types to src/bar code expecting
      src/bar/vendor/dep types. Even if the deps are identical
      checkouts. Code can become uncompilable by the act of
      vendoring a dependency.You have two completely different sets
      of globals. Code can stop working by the act of vendoring a
      dependency.The initialization runs twice. So well known
      packages like glog will panic if two packages has it vendored
      because they both try to update settings in the standard
      library.GOPATH would be preferable, but none of the tools for
      managing packages at that level support pinning. So you dare
      to be developing more than one package at a time, you end up
      with a single monolithic repository representing your GOPATH
      and pin your dependencies in src/, or end up with symlink
      hacks and other unmaintainable tricks.
 
  frik - 4 hours ago
  ++Now we have at least vendor. But this alien-style fixed paths
  is really annoying - no other language forces such GOPATH crap.
  Please remove this limitation from Go 2!
 
    artursapek - 4 hours ago
    What exactly is wrong with GOPATH? I find it much easier to
    reason about than imports in say Ruby or Python, which are
    global names with no hierarchy and are resolved in much less
    obvious ways.
 
      brango - 4 hours ago
      There's no obvious way to separate personal work, from work
      work, from exploratory work, from any other way you want to
      categorise your source directories. You just have to chuck
      them all in the same root and hope you can remember what each
      project is for.
 
        kevinmgranger - 4 hours ago
        That is the reason why GOPATH is an environment variable:
        so you can change it easily, you own way.
 
        artursapek - 4 hours ago
        What? Manage it the way you'd manage any other environment
        variables, like AWS_SECRET_ACCESS_KEY. That's exactly what
        a bash environment is for.
 
        zbobet2012 - 4 hours ago
        Uhh, just keep separate gopaths? I keep a separate go path
        per project.
 
  GoodbyeEarl - 3 hours ago
  I still find it difficult to install and use Go.
 
  vhost- - 3 hours ago
  yeah, I don't fully understand this. I've had the least problems
  with GOPATH than I have with any other language. You literally
  set GOPATH=${HOME} and it just works.
 
  hackerboos - 3 hours ago
  I think 1.8 addressed the
  issue.https://golang.org/doc/go1.8#gopath
 
    closeparen - 1 hours ago
    "The GOPATH issue" is the requirement that I keep my source
    code checkouts at any particular path, in any particular
    structure, to be able to use the toolchain.Solving the GOPATH
    issue would be letting me "git clone" a Go project to a
    directory of my choosing and still use the tools.
 
munificent - 5 hours ago
    > I can't answer a design question like whether to support
> generic methods, which is to say methods that are     >
parameterized separately from the receiver.  I work on the Dart
language. Dart was initially designed with generic classes but not
generic methods. Even at the time, some people on the team felt
Dart should have had both.We proceeded that way for several years.
It was annoying, but tolerable because of Dart's optional type
system -- you can sneak around the type checker really easily
anyway, so in most cases you can just use "dynamic" instead of a
generic method and get your code to run. Of course, it won't be
type safe, but it will at least mostly do what you want.When we
later moved to a sound static type system, generic methods were a
key part of that. Even though end users don't define their own
generic methods very often, they use them all the time. Critical
common core library methods like Iterable.map() are generic methods
and need to be in order to be safely, precisely typed.This is
partially because functional-styled code is fairly idiomatic on
Dart. You see lots of higher-order methods for things like
manipulating sequences. Go has lambdas, but stylistically tends to
be more imperative, so I'm not sure if they'll feel the same
pressure.I do think if you add generic types without generic
methods, you will run into their lack. Methods are how you abstract
over and reuse behavior. If you have generic methods without
generic classes, you lose the ability to abstract over operations
that happen to use generic classes.A simple example is a
constructor function. If you define a generic class that needs some
kind of initialization (discouraged in Go, but it still happens),
you really need that constructor to be generic too.
 
  masklinn - 5 hours ago
  >  You see lots of higher-order methods for things like
  manipulating sequences. Go has lambdas, but stylistically tends
  to be more imperative, so I'm not sure if they'll feel the same
  pressure.`range` is generic, and by virtue of that is a builtin
  which only works with a subset of the also builtin magically
  generic types.The reason why Go "does not feel the same pressure"
  has nothing to do with its imperative style[0] it is because they
  special-cased a few generic structures as builtin very early on,
  unlike, say, Java (which only had arrays as a typed
  datastucture).[0] Java and C# are could hardly be more
  imperative, hell Java is only just adding anonymous functions
 
    snuxoll - 4 hours ago
    Java has "had" anonymous functions for ages with anonymous
    inner classes, they just sucked as an implementation.
 
      jdmichal - 4 hours ago
      Absolutely correct. Lambdas are just shorthand for anonymous
      inner classes which implement an interface with only one
      method -- aka single abstract method (SAM) types.For
      instance, you have two functions. One takes `Function      Type>` and the other takes `UnaryOperator`. Giving the
      "same" lambda to both functions will result in two anonymous
      inner types, one implementing both interfaces.
 
        _asummers - 3 hours ago
        They're not exactly shorthand. They use `invoke_dynamic`
        under the hood, which defers the creation of the lambda til
        it is used. Conceptually they are, but in practice they're
        a little different.
 
      masklinn - 4 hours ago
      > they just sucked as an implementation.They also sucked as
      an interface (for developers to use), resulting in them only
      being used when no other option was available (Comparable) or
      for cute hacks (double-brace initialisation).
 
  dvt - 4 hours ago
  I edited a book on Dart a few years ago. It's a shame the
  language hasn't gotten much traction outside of Google, as I
  enjoyed learning and using it.
 
    [deleted]
 
    girvo - 3 hours ago
    I think it'll see more traction with Flutter and the like over
    the next year
 
  jcstk - 4 hours ago
  Ditto on generic methods both changing the game for Dart and
  being necessary. I spend most of my time in Dart, Swift and ObjC,
  and I've built serious applications in Erlang and Java. All of
  which I like for different reasons.My opinion is that Dart's type
  system is the optimal type system. It allows for statically typed
  API surface, but at the same time, I can still add some dynamic
  voodoo under the surface and enable productive meta-programming.
 
    willtim - 4 hours ago
    As a far as I can tell, an "optional type system" is just an
    unsound type system with a marketing name. Any decent static
    type system would allow one to progressively increase the level
    of typing, the weakest form being using a Variant type to hold
    all other types. The advantage here is that any
    invariants/proofs that are captured in the system are not
    compromised by unsoundness.
 
      rbehrends - 1 hours ago
      No, there's more to it. There's been some research in recent
      years on the actual benefits of types and the results are
      less straightforward than some people think.An important
      aspect of type annotations, for example, seems to be that
      they help document the API of a module, regardless of whether
      they're statically checked. This is especially relevant with
      respect to maintenance tasks.Conversely, the benefits of
      static type checking to get correct code initially seem to be
      a lot murkier. There seems to be a cost associated with
      static types and that is that it takes longer to write code;
      time that can be spent in a dynamically typed language on
      other validation work (remember that types do not even
      remotely capture all software defects).This means that it is
      definitely worth exploring the benefits of
      optional/gradual/soft typing vs. static typing and/or runtime
      type checking vs. compile-time type checking.Conversely, the
      assumption that static types are an unalloyed good is not
      currently borne out by the evidence (in part, of course, that
      is because the evidence is inconclusive).
 
      munificent - 3 hours ago
          > As a far as I can tell, an "optional type system" is
      > just an unsound type system with a marketing name.  It is a
      term with a specific meaning. The key bit separating it from
      both gradual typing and a static type system with a dynamic
      type (like Scala or C#) is that in an optionally typed
      language, the type system has zero runtime effect. If you
      were to take a source file and mechanically strip out all of
      the type annotations, the resulting program behaves
      identically to the original one.Dart 1.0 was an optionally
      typed language. Dart 2.0 is not -- we've gone to a mandatory
      static type system (with lots of inference and a dynamic
      type). The limitations of optional typing are simply too
      onerous, and it's just not what users expected or want.    >
      Any decent static type system would allow one to      >
      progressively increase the level of typing, the weakest     >
      form being using a Variant type to hold all other types.
      That's the dream of optional typing and gradual typing. In
      practice, I have yet to see a language that does this
      harmoniously. It sounds simple, but things quickly get very
      complex when you start working with generic types and first-
      class functions because the boundary between the untyped and
      typed code gets very strange. To keep the guarantees you
      expect inside your typed code, you have to figure out how to
      handle untyped data that flows into it. That gets nasty very
      quickly when that untyped data may be an instance of a
      generic class or a function.
 
        willtim - 3 hours ago
        >  To keep the guarantees you expect inside your typed
        code, you have to figure out how to handle untyped data
        that flows into it.This would be solved in a conventional
        static type system by forcing the user to eliminate the
        variant, and forcing the user to deal with the case that it
        has an unexpected value.So I cannot see why even C# dynamic
        is necessary, except to perhaps save some thinking, but
        this isn't a good thing IMHO.
 
          avip - 2 hours ago
          The dynamic type was added to C# to facilitate
          interoperability (ex. DLR), not so much to encourage lazy
          devs to get their bugs at runtime rather than compile
          time.
 
          pjmlp - 2 hours ago
          Additionally to simplify dynamic dispatch calls on COM.
 
          willtim - 2 hours ago
          I still do not understand why this cannot be done via a
          Variant type. Also it doesn't explain why Dart 2 has a
          similar feature.
 
          barrkel - 1 hours ago
          Think of dynamic as a different word for Variant.The
          semantic differences for OLE2 Variants vs C# dynamic
          mostly only exist in implementation protocols.
 
      geofft - 2 hours ago
      I don't think I've seen a Variant type in any language that
      doesn't store some form of type information at runtime
      (unless you count C void pointers, which I don't), and "any
      decent static type system" incurs no runtime overhead in the
      common case.
 
        willtim - 2 hours ago
        Of course variants would need to tag their payload, but
        this is what all dynamic languages need to do anyway. My
        point was that such dynamic behaviour can be done without
        resorting to an unsound "optional type system".
 
      barrkel - 1 hours ago
      Writing well-typed code means writing a proof of some set of
      properties over the code. There are three assumptions
      here:(1) creating abstractions that are typed correctly is
      easy(2) the existing abstractions you're building from are
      correctly typed(3) the properties that the type system proves
      are valuable enough to reward the effortWhether (1) is true
      depends on your type system. If it's very simple (e.g.
      dynamically typed), it's trivially true. If it's rich and
      expressive, it can sometimes be impossible to express your
      intent without obfuscating your types (e.g. using pointers
      and typecasts or polymorphism or some other loophole); and
      with some type systems, it's plain impossible to express some
      valid programs.Whether (2) is true is a social problem. You
      need to have enough sensible people in your community such
      that you get to use List rather than ObjectList with
      typecasts, or what have you. What's available in the runtime
      libraries often translates into what's commonly used for APIs
      in third party modules, and if the library of types isn't
      rich enough, APIs will use loopholes or typecasts or other
      mechanisms that obfuscate types. Third party code turns into
      a kind of firewall that stops your types (and the
      information, proofs, they convey) from flowing from one
      module to another in your program.Whether (3) is true also
      depends on your type system, but also on your application
      domain. It's in direct opposition to (1); the more you can
      prove with your type system, the harder it normally is to
      write code that proves exactly the right things, and neither
      more nor less (the risk is usually too little type
      information flowing through). If the properties being proved
      are important to your application domain, then that gives a
      big boost to type systems that can prove those properties. If
      it's just because it gives you warm fuzzies, and testing is
      what proves interesting things because interesting properties
      (in your domain) are harder to prove with a type system, then
      rich type systems are less useful.Personally, I was once a
      strong proponent of rich expressive type systems. But I
      eventually learned that they can become a kind of
      intellectual trap; programmers can spend too much time
      writing cleverly typed confections and less time actually
      solving problems. In extremis, layers of abstraction are
      created to massage the type system, often in such an indirect
      way that the value of the properties being proven are lost
      owing to the extra obfuscation. Now, I see much more value in
      a strong type system for languages like Rust, but much less
      value at higher levels of abstraction. That's because many of
      the properties being proven by Rust (like memory safety) are
      already proven in high-level dynamic languages through GC and
      lack of pointers and unsafe typecasts. Whereas application-
      level properties being proven through type systems are seldom
      valuable.Documentation and tooling are much stronger
      arguments for types in high-level languages than proofs;
      ironically, this means that the type systems don't need to be
      sound, as long as they're usually OK in practice!
 
elliotmr - 2 hours ago
I must say that whenever there is a discussion about the merits of
the Go programming language, it really feels hostile in the
discussion thread. It seems that people are seriously angry that
others even consider using the language. It is sort of painful
reading through the responses which implicitly declare that anybody
who enjoys programming with Go is clueless.It also really makes me
wonder if I am living in some sort of alternate reality. I am a
professional programmer working at a large company and I am pretty
sure that 95% of my colleagues (myself included, as difficult as it
is for me to admit) have no idea what a reified generic is. I have
run into some problems where being able to define custom generic
containers would be nice, but I don't feel like that has seriously
hindered my ability to deliver safe, functional, and maintainable
software.What I appreciate most about Go is that I am sure that I
can look at 99% of the Go code written in the world and I can
understand it immediately. When maintaining large code bases with
many developers of differing skill levels, this advantage can't be
understated. That is the reason there are so many successful new
programs popping up in Go with large open-source communities. It is
because Go is accessible and friendly to people of varying skill
levels, unlike most of the opinions expressed in this thread.
 
  scribu - 2 hours ago
  I think the negative attitude comes more from frustration than
  from anything else.> I am a professional programmer working at a
  large company and I am pretty sure that 95% of my colleagues
  (myself included, as difficult as it is for me to admit) have no
  idea what a reified generic is.I didn't know what it was called
  either until I saw them mentioned here, but now that I know about
  it, I get why it would be useful. Before that, I kind of assumed
  all languages with generics would also allow you to access the
  type information at runtime.> I have run into some problems where
  being able to define custom generic containers would be nice, but
  I don't feel like that has seriously hindered my ability to
  deliver safe, functional, and maintainable software.I don't mean
  any disrespect, but this is a very good example of the Blub
  Paradox: http://wiki.c2.com/?BlubParadox
 
    hota_mazi - 1 hours ago
    FYI, reified generics undermine type safety and correctness in
    general, which is one of the reasons why so few languages
    support the concept (another is that erased generics allow for
    easier interoperability and for the creation of a much wider
    class of static type systems).In my experience, most people who
    think they need reified generics don't really understand them
    and can actually do fine with much safer concepts expressed on
    an erased runtime.
 
    elliotmr - 2 hours ago
    > I don't mean any disrespect, but this is a very good example
    of the Blub Paradox: http://wiki.c2.com/?BlubParadoxInteresting
    read, and I admit there is some of that. But my point isn't to
    say that those features aren't useful or powerful, but rather
    that with the constraint of working with a large group of
    programmers of varying skills, simplicity has more value than
    power (as long as we can deliver software that meets our
    requirements). It is similar to point 4 in the "Problems with
    the Blub Paradox" section.
 
      dtech - 3 minutes ago
      One of the problems is who decides what is too simple. E.g.
      why are for loops, function calls and lamdbas considered
      simple enough to be in go, but generics aren't? When I TA'ed
      CS introductory courses, student usually had a lot less
      trouble with understanding generics than lambdas.Not
      including feature X in programming language Y will also
      ensure that no-one who primarily uses Y will ever come to
      understand or appreciate X.The blub paradox basically
      represents the opinion that it is always better for languages
      to include more powerful features.I think that goes to far
      (working primarily in Scala I am seeing firsthand how much
      diminishing returns extra complexity in the language can
      have), but I'm certainly of the opinion that Go leans too
      heavily toward handicapping the language too much in pursuit
      of simplicity.
 
    Entalpi - 1 hours ago
    This made me think about Pony and its capabilities system..
    Also of Haskell and all the rmap, lmap, rfold, lfold, rmagic,
    lmurloc.. :P
 
  neurotrace - 2 hours ago
  I don't think anyone has been arguing against it's ease of use
  nor the ease of readability. Most people seem to be against it's
  ergonomics and intentional lack of features.
 
    oblio - 2 hours ago
    What if those two are related? ;)
 
    owaislone - 1 hours ago
    I like Go and it's intentional lack of feature or very slow
    speed of adding features is my favorite feature. May be I am a
    pseudo programmer like most people who dislike Go would
    probably say.
 
  geodel - 1 hours ago
  It is because some people here who have no stake in Go programing
  seem extraordinarily angry or maybe just concerned that why the
  hell Go authors didn't just override Go programmers' and listened
  only to enlightened PL experts here and at Reddit.If it were a
  topic of gender or race instead of programing language I am sure
  this behavior would be called out as
  mansplaining/whitesplaining.I do wish some term like
  'PLsplaining' be used for this infuriating behavior of calling
  Go/PHP or whatever programmers clueless.
 
  smegel - 6 minutes ago
  To be fair, forcing \t on people was a douchebag move.
 
  camus2 - 1 hours ago
  > It also really makes me wonder if I am living in some sort of
  alternate reality. I am a professional programmer working at a
  large company and I am pretty sure that 95% of my colleagues
  (myself included, as difficult as it is for me to admit)What are
  you and your co-workers using aside from Go?
 
    elliotmr - 1 hours ago
    Mostly C and C++. Personally I am working in a C++ codebase
    right now and I struggle with all sorts of finicky cross-
    compilation and linking problems that just wouldn't exist in
    Go.We also do some Python and Javascript for scripts and web
    work.
 
  runT1ME - 46 minutes ago
  >What I appreciate most about Go is that I am sure that I can
  look at 99% of the Go code written in the world and I can
  understand it immediately.No you really can't.  You can look at
  any given line of code and tell me what it does, where as it
  might take more time to parse any given line of Haskell, Scala,
  or OCaml longer.However, expressivity in a large application pays
  a dividend tenfold, because the main challenge of reading code is
  not any given line, it is understanding the application
  architecture, the frameworks, the data flow and how it all works
  together.> That is the reason there are so many successful new
  programs popping up in Go with large open-source
  communities.Successful, or popular?  Just look at Docker.
  Certainly popular, but check the bug tracker or talk to anyone
  with real world experience using it at scale and you'll be
  hearing a completely different story.
 
jgrahamc - 5 hours ago
I didn't expect to get namechecked in that.Shows the value of
constantly being transparent and supporting open source projects.