GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-11-10) - page 1 of 10
 
___________________________________________________________________
Eight years of Go
204 points by spacey
https://blog.golang.org/8years
___________________________________________________________________
 
stablemap - 4 hours ago
A post earlier this year by Rob Pike, celebrating ten years of
Go:https://commandcenter.blogspot.com/2017/09/go-ten-years-and-...
 
  weberc2 - 3 hours ago
  This blog post is 8 years since Go was an open source project.
  Rob's post was probably something like "10 years since we began
  work on Go".
 
    stablemap - 3 hours ago
    Yes, I didn?t mean to imply a contradiction. Just two articles
    that go well together.
 
indescions_2017 - 3 hours ago
> every single cloud company has critical components of their cloud
infrastructure implemented in GoAnd this is how the "network
effect" propagates. As the customers of cloud services also begin
to experiment in Golang. And discover the holistic ecosystem of
distributed systems packages.Even Blizzard with its massive C++
codebase is gaining convertshttps://youtu.be/Az5F4lwSljI?t=23m50s
 
dogruck - 1 hours ago
In honor of the exponential, I wish the conclusion was ?Thank you,
and here?s to sixteen more years!? :-)
 
mfrw - 3 hours ago
Simplicity is the Ultimate form of sophistication -- Leonardo da
VinciThe quote fits perfectly for the design of go.
 
  simon_o - 2 hours ago
  Like nil interfaces not being nil.Or using characters from the
  Canadian Aboriginal Syllabics unicode block to emulate generics.
 
  nv-vn - 1 hours ago
  I think it fits better for Scheme or Forth. I would not describe
  Go as simple at all relative to those languages.
 
[deleted]
 
davidkuhta - 4 hours ago
way to go, Go!Just to accentuate some of the neat things you can do
with Go, watch: 'Can you write an OS Kernel in Go?' from the Golang
UK Conf. https://www.youtube.com/watch?v=8T3VxGrrJwc
 
  bitmapbrother - 3 hours ago
  That was seriously impressive.
 
nine_k - 4 hours ago
Go is an example of how to be extremely successful by catering to
the needs of the project's core audience (well-rounded stdlib,
extremely fast GC, short build times, trivial deployment, etc)
while paying much less attention to the vocal minority's complaints
(generics, package system, etc).
 
  asavinov - 3 hours ago
  > ... while paying much less attention to the vocal minority's
  complaints (generics, package system, etc).It is much more
  difficult not to add a feature than to add it, and the ability to
  reject even important feature requests is very important for the
  survival of a system in long term. This observation is formulated
  in "Getting Real" (https://gettingreal.37signals.com) as "Forget
  Feature Requests" and "Start With No".
 
  qaq - 3 hours ago
  How would allocating resources to making a nice package mnger
  would have hindered Go popularity :)? Tacking it on postfactum is
  always a big pain.
 
  hood_syntax - 4 hours ago
  Are the complaints about lack of generics really a minority
  thing? Writing separate functions to sort different types just
  strikes me as ridiculous.EDIT: My original tone was a bit nasty
  in retrospect. Did a little research and while I still am on the
  generics side, the current situation seems at least workable for
  a good number of use cases.
 
    kown223 - 4 hours ago
    how often do you sort? most of the time you would do a database
    ORDER BY instead.
 
      tytytytytytytyt - 3 hours ago
      Thanks, that was great. :D
 
      jackmott - 1 hours ago
      can't tell if joking
 
      tree_of_item - 4 hours ago
      I...I can't even believe you just said that. Go really does
      have a unique core audience.
 
        z0r - 3 hours ago
        more like tree_of_interface{}interfaces are a poor
        substitute for generics, but that's by design. the minute
        they add a reasonable implementation of generics Go will
        begin to metastatize into something unrecognizable as
        people will no longer be bound by the limitations of the
        already existing core generic types. the core developers
        really do not want that to happen.it's a highly opinionated
        language and for some reason some people enjoy writing
        mountains of for loops so that their code can remain
        "simple" as they produce a maze of twisty funcs all alike.
        i mostly see a for loop or two per func with a map and some
        slices repeating the same patterns over and over. that's
        the way the language designers want it.i work with a lot of
        go programmers and they are all fine and good programmers.
        that makes it even harder to understand why they enjoy all
        the boilerplate and even defend it.
 
        the_common_man - 3 hours ago
        > Go really does have a unique core audience.I..I can't
        believe you just said that. Such generalizations based on a
        single comment by an anon.
 
        jonloldrup - 3 hours ago
        Ignorant here (I've never done database work): What's wrong
        with asking the database to do the sorting for you?
        (assuming you do work that involves a database. Perhaps
        this assumption itself is the problem?)
 
        shurcooL - 4 hours ago
        (This is not endorsement of the parent post; I don?t agree
        with it either.)This is how you can sort slices of
        arbitrary types in
        Go:https://play.golang.org/p/VHJW9lVY9bI?m not sure about
        you, but it feels very reasonable to me. It?s not anywhere
        near the top of my list of pains that I feel when working
        with Go everyday.
 
        kown223 - 4 hours ago
        care to enlighten me? if you have an index you could get
        the sort for free, also you never pull all results, so why
        would you pull all, just to sort, on the web I would love
        to work more in ram, but since you assume a server will
        crash, you need to save the actual state in the db.
 
          joshmarlow - 3 hours ago
          I didn't down-vote, but what jumps out to me is the
          assumption that you'll generally be pulling data from a
          database.  Yeah, that's almost certainly true in a web-
          application, but it's not going to be nearly as universal
          in a systems-programming niche which is where Go appears
          to be excelling (as perceived by someone outside of the
          Go community).So ease of implementing sorting in your
          core language without making assumptions about the
          operating environment of code written in that language
          sounds like a reasonable demand.
 
        krylon - 3 hours ago
        I understand why that would make you uncomfortable. ;-)But
        to be honest, more than 50% of the cases where I needed
        data to be sorted in a certain way, that data came out of a
        relational database, and adding an ORDER BY-clause to the
        SQL query was so much easier than doing it myself.I do
        agree with the second part of your comment in that Go has a
        certain type of application where it really shines. But
        that type of application is not uncommon, and when you hit
        the sweet spot, it really shines.
 
    Gys - 4 hours ago
    Assuming developers are rational in their choices, by far most
    of the Go developers still prefer to use the language without
    generics.I think its just a minor problem compared to all
    benefits.
 
      weberc2 - 3 hours ago
      > by far most of the Go developers still prefer to use the
      language without genericsI've been writing Go regularly for
      at least 5 years, and my guess is that at most 60% of Go
      developers prefer no generics. I also think that number is
      climbing.
 
        jackmott - 1 hours ago
        yes, but those of us who would desperately like to use Go
        because there are vanishingly few GC languages that compile
        to native exe AOT, won't because of no generics. So it is a
        bit of a tautology.How useful they are depends greatly on
        what you are doing, and programmers do a great many
        different things.  For many kinds of library development,
        they can save you massive amounts of time and code, and/or
        lead to much better performance vs the workarounds
        available.I wonder how many people who prefer Go without
        generics are coming from C++ templates, or Java generics,
        vs C# or F# generics.
 
        rifung - 3 hours ago
        I write Go at work but have never heard anyone say this.Can
        you explain why you would prefer no generics to this dumb
        junior engineer who wants to be enlightened?
 
          weberc2 - 1 hours ago
          To be clear I prefer generics. The cases for why other Go
          developers don't want generics seem to mostly fall on "it
          will change the language / encourage people to write
          stupidly complex code" to "it's too hard to implement".
          The first one is valid--Go's constraints give it this
          nice property that there is (more or less) one obvious
          way to write most programs, and that will go away with
          generics; however, I think that cost is worth the gain.
          The other criticism seems like a cop-out; the Go team has
          far and away more than enough talent to slap generics
          onto the language.
 
      kmicklas - 3 hours ago
      This level of myopia from Go developers is why it gets so
      much flack.
 
    [deleted]
 
    ori_b - 4 hours ago
    But you don't need to do that. It's a bit clunkier than
    generics, but it's usable: https://golang.org/pkg/sort/
 
      pcwalton - 3 hours ago
      You're still writing separate functions (implementations of
      sort.Interface) to sort different types.
 
        fauigerzigerk - 2 hours ago
        For sorting slices you only have to pass one function:
        sort.Slice(s, func(i, j int) bool { return s[i].X < s[j].X
        })
 
        dualogy - 3 hours ago
        A little boilerplate hasn't killed anyone. If you're
        talking about "100s of different Enterprise Business
        Objects (TM) structs", something is probably off in the
        overall program design and/or code-gen should probably be
        introduced regardless of the 'sort' (and related typically-
        generics use-cases) question, as that sounds like something
        to be largely derived from pre-existing schemas of some
        sort..
 
          pcwalton - 3 hours ago
          > A little boilerplate hasn't killed anyone.It's
          annoying, especially since basic generics are simpler
          than interfaces.> If you're talking about "100s of
          different Enterprise Business Objects (TM) structs"I
          don't write enterprise software. I sometimes need to sort
          things.
 
        ori_b - 2 hours ago
        But this is something you often need to do for any non-
        trivial type, even with generics. There's a reason that C++
        std::sort<> takes a comparator, or why Rust requires you to
        implement the 'Ord' interface.Again, it's a little clunkier
        in Go, but not unusably so.
 
          pcwalton - 2 hours ago
          You need to define how to order things in other languages
          (though not in languages where you can automatically
          derive implementations like Haskell or languages with
          built-in polymorphic comparison like OCaml) but you don't
          need to define how to swap elements over and over.
 
          ori_b - 1 hours ago
          Yes, I'm aware. That's the clunky part that I was
          referring to (although, you can still avoid it for
          slices, and simply pass a single compare function.)Go is
          far from my favorite language, but the sheer amount of
          bad criticism by people that clearly don't use the
          language annoys me.
 
      krylon - 3 hours ago
      I have had the need to sort data rarely enough that it has
      not been a real problem to me (most of the time that data
      came out of a relational database that did the sorting for
      me).But when I did have the need to sort stuff, I have found
      it annoying. Even C has a more convenient solution for this
      problem. (Admittedly, Go's sort.Sort can work for data
      structures other than arrays/slices.)Like I said, it has not
      been a sufficiently large problem to really bother me, but it
      is not a pretty solution, IMHO.Of course, one might argue
      that the creators of Go knew that sorting things was not such
      a common problem for their target audience, and thus they
      made the trade off to make sorting suck in return for overall
      simplicity; Go's type system makes it practically impossible
      to implement a type-generic sorting function like C's
      qsort(3) without sacrificing performance or making the
      language more complex.So maybe that is one of the trade offs
      we have to make. I still wish for a better solution, even if
      that may be impossible without turning Go into another C++.
      And if you like C++, that is totally fine, it has a number of
      very big advantages. But then you do not need Go to become
      another C++ if you have the original right there; and even if
      you wanted to get away from C++ without giving up the
      benefits it offers, D looks like a more promising
      alternative.
 
      hood_syntax - 4 hours ago
      I did a little research after I posted my original comment
      and came across that. It does seem usable even if it's not
      what I'd prefer
 
    misframer - 4 hours ago
    I've been using Go at work and for my personal projects for
    over 4.5 years. I rarely have to sort. It's not a big deal for
    me.
 
      sanderjd - 28 minutes ago
      It's not about sorting, it's about every single abstract
      operation on a collection or other type of container. You
      either have to use primitives, or reimplement everything
      yourself on each new type. Most people just use primitives.
      This proliferation of primitives is what I actually dislike
      about reading and writing code in Go, but it's caused by not
      having a way to define abstract data types that work well.
 
    [deleted]
 
    nine_k - 4 hours ago
    Apparently, the project leaders see it as a lower-priority
    (though not unimportant) issue. Looking at the adoption
    figures, they seem to be right.I personally stay away from Go
    due to lack of generics and other expressiveness issues. People
    who have to work with it write code generators on top of the
    compiler, because the compiler team won't include it into the
    language. (I can see how it's not an easy thing to do; Russ Cox
    wrote a nice piece about it.)Java prior to version 5 had the
    very same problem. It was wildly popular nevertheless. It took
    Java 8 years to gain support for generics, though, about as
    long as it took Go to not yet obtain them. (By that time, Java
    was widely considered the Cobol of 21st century; I think Go
    must be successfully stealing that crown now.)
 
      pjmlp - 1 hours ago
      > Looking at the adoption figures, they seem to be right.Not
      really, for me Go is a bit like JavaScript.I have to deal
      with Go thanks to Docker and K8s, doesn't mean I would use it
      when given the option.
 
    AnIdiotOnTheNet - 4 hours ago
    Yes, it is minor. Go has interfaces, so you just write a
    Comparer interface and sorter that takes two Comparers and then
    anything implementing Comparer is sortable.*Note: author has
    written basically nothing in Go and only has a passing
    familiarity.
 
      weberc2 - 3 hours ago
      If your `Comparer` is an element type (as opposed to Go's
      `sort.Interface` abstraction over collections), this is going
      to be horribly unperformant. Suppose your `Foo` type
      implements `Comparer`, and you have a large `[]Foo`. Then
      you'll first have to iterate over each element in `[]Foo` and
      add it to your `[]Comparer`, probably with an allocation per
      element. Then each invocation of `foo.Compare()` is going to
      be indirect as well (in other words, an interface lookup and
      a function call, i.e. no inlining). Mind you, this is still
      faster than many languages, but it's not the kind of
      performance people expect from Go.
 
        AnIdiotOnTheNet - 3 hours ago
        From this description, I'm getting the impression that Go's
        interfaces are not as much like Java interfaces as I had
        assumed.Never the less, I find that generics usually are
        just an over-engineered solution to any given problem.
 
          weberc2 - 47 minutes ago
          The primary differences (I think) are that everything in
          Java is already a pointer, so there isn't an extra alloc
          to make an interface. The same is true in Go if your
          comparables are all pointers. Probably the more
          significant difference is that Java has a JIT compiler,
          which may be able to inline all of those calls to
          Compare(). This is largely why Go's `sort` package
          abstracts over the collection, not over the element.
 
    Silfen - 4 hours ago
    My concern is less about writing a bunch of separate functions,
    but rather the way this hampers the abstractions that are
    available to you everywhere in the language. You don't have map
    or fold! And that's only the very tip of the iceberg.
 
      jopsen - 2 hours ago
      Yeah, I wish go had more functional stuff, like .map(),
      .filter(), etc.On the other hand I enjoy that when I pickup a
      package someone wrote there is not a bunch of different meta-
      programming using templates.Generics sometimes lead people
      (including myself) to over-engineer solutions... usually
      because we want as much compile safety as possible. But at
      what cost in complexity.
 
        erik_seaberg - 1 hours ago
        I'd rather read x.filter().map() than read the loops
        someone had to expand them into by hand.
 
          ryanplant-au - 37 minutes ago
          I groan every time I have to implement the 15th type-
          specific loop implementation of what I'd do with a single
          map or fold in Ruby/Elm/Haskell/JS/TS/Crystal/every other
          language I use. It's not a lot of effort but it's a lot
          of mess and cruft.
 
  GuB-42 - 3 hours ago
  Like pretty much every successful programming language.Most of
  them have one original goal, and a core philosophy to go with
  that goal and that guides the compromises.Take C for instance :
  its original goal was to write UNIX. Because of this, it has to
  be low level, portable, and efficient. These are the important
  things and that's why people use C. Features important for
  writing UNIX stuff get priority, this ensure consistency.Go is
  Google's language, made to be effective at doing what Google
  does. And its direction ensure that people who follow Google's
  way of coding are happy. There are other options for those who
  don't like it.
 
  pera - 4 hours ago
  Maybe, but even then at the end they decided to pay attention to
  this "vocal minority" and add go dep.
 
  krylon - 4 hours ago
  You are not wrong.But I think there is more to it. I have used Go
  (almost) exclusively for private toy programs I write in my free
  time to relax (sounds weird, I know), so my perspective may be
  warped. But something about is very compatible with the way my
  mind works. With some other languages, say C or C#, I find myself
  constantly browsing through documentation to figure out what a
  given construct means in that language. And don't get me wrong, I
  like both of these languages.But with Go, my intuition what I
  think a given piece of code should mean is nearly always in line
  with the language specification. The only other language I had
  this level of rapport with is Python.There are many things I miss
  in Go, but all in all, I think it is simplicity done right.BUT if
  Go had not also gotten the things right that you mention, it
  probably would not have become this popular.
 
    insulanian - 2 hours ago
    > sounds weird, I knowNo, it doesn't.
 
    johndubchak - 2 hours ago
    > I write in my free time to relax (sounds weird, I know)Not
    weird at all. I do that myself. I believe the relaxation is in
    pure creativity, the wonder of exploring something novel and
    the absence of any pressure or stress due to timelines or
    deadlines. You're also exercising both right and left sides of
    the brain.I suspect there are many many more who do the same.
 
      krylon - 2 hours ago
      Huh. That are exactly the reasons I would give if I had to
      explain that hobby to somebody. ;-)Feels kind of good to know
      that I am not the only one doing this.When it goes really
      well, programming is akin to what I think meditation must be
      like. But explaining that to people who have never programmed
      themselves is hard.
 
    tetraodonpuffer - 3 hours ago
    > my intuition what I think a given piece of code should mean
    is nearly always in line with the language specification.for
    some things yes, but for others I think that it's more
    familiarity than intuition, take for example interface slices,
    you start by learning that you can assign any type to
    interface{}, so intuitively you'd think that you could assign
    any type slice to []interface{} but you find out soon enough
    that doesn't workIf you dig a bit it is completely
    understandable why it doesn't given how interfaces are laid out
    in memory, but from an intuitive standpoint you'd think that
    since you can do it in the scalar case you should be able to do
    it in the slice case too...This is a very minor nitpick, I do
    agree that compared to many other languages golang is very easy
    to mentally parse, at the expense of some expressivity at
    times.Whenever I code in it, which these days is pretty much
    all the time, I do miss some conveniences from other languages
    (generics, list comprehensions, ...) but of course every
    language has its tradeoffs, I most certainly miss golang's
    strengths every time I have to write some C or python.
 
      slrz - 1 hours ago
      > take for example interface slices, you start by learning
      that you can assign any type to interface{}, so intuitively
      you'd think that you could assign any type slice to
      []interface{} but you find out soon enough that doesn't
      workWhy do you expect this to be the case? Just because you
      can assign a char to an int in C, you wouldn't expect to be
      able to assign a char pointer to an int pointer. Similar for
      C++ and std::vector vs std::vector.It's the same
      and probably even more relevant with void?/int? (assignable)
      vs. void??/int?? (not assignable). You can assign an int?? to
      a void?, though, just as you can assign an []int to an
      interface{} in Go.Also, even as an absolute greenfield
      programmer with no experience in other system languages, if
      you really think it through, you will come to the conclusion
      that it mustn't be possible to assign arbitrary slice values
      to an []interface{} variable, given the way slices work.
 
      terminalcommand - 3 hours ago
      IMO interfaces are the Achilles' heel of Golang. Another
      thing that has been bugging me about them is that you cannot
      specify which interface you're implementing in the code
      (beside from comments). I think that is so because Go hates
      circular imports. If you had to import a file to be able to
      use an interface, you'd soon run into compile errors due to
      circular dependencies.And as there is no way to immediately
      see where some interface is declared and if/which interface
      is implemented, you have to rely on comments and resort to
      manual search to find out more. That may be easy in smaller
      codebases or worthy of effort in important codebases such as
      Go standard library. But all an all this ambiguity does not
      fit with Go's discipline to prevent human errors by making
      everything uniform and explicit as possible.Just for the sake
      of providing an example, let's look at time.go under
      https://golang.org/src/time/time.go, we can see in the
      comments of several functions that the programmer states a
      particular interface is implemented. Line 1112 of the
      aforementioned file is as follows:  // MarshalBinary
      implements the encoding.BinaryMarshaler   interface.   func
      (t Time) MarshalBinary() ([]byte, error) {  Now where is
      encoding.BinaryMarshaler declared? There is a package called
      encoding, maybe there? But the package has many many files,
      where would I find where BinaryMarshaler is defined? I'd have
      to resort to manual search. Now imagine that this is not an
      interface in the standard library, but rather an interface in
      some mediocre codebase that you're handed for the first
      time...Tl;dr All I'm saying is that runtime errors due to
      empty interfaces are not the only flaw of Golang. Interfaces
      as implemented in Go could in some cases present a serious
      threat to code structure.
 
        krylon - 3 hours ago
        It would be nice to add at least the options to explicitly
        state that type X should implement interface I, and have
        the compiler barf / emit an error if X does not implement
        Y.Like I said before, this has not been enough of a problem
        to really bother me, but I would be quite happy if Go fixed
        this.
 
          tetraodonpuffer - 2 hours ago
          can't you simply do this (from [1]) somewhere in your
          code to enforce?    type T struct{}     var _ I = T{}
          // Verify that T implements I.     var _ I = (*T)(nil) //
          Verify that *T implements I.  [1]
          https://golang.org/doc/faq#guarantee_satisfies_interface
 
          terminalcommand - 2 hours ago
          Yes you could, but then you'd have to have both the
          declaration and the implementation of the interface in
          the same package. That would mean that if either of them
          is in a separate file, you'd have to import it. That in
          return, could easily call hellish compiler errors due to
          circular dependencies. In Go any circular dependency is
          an immediate compile error.Looking at the link, the
          second advice is that you could require users to
          implement special functions such as ImplementsFooer() to
          explicitly declare which interface they're implementing.
          This could help, but this practice is not present in the
          codebases I've seen including the Go standard library (to
          the best of my knowledge).
 
          majewsky - 2 hours ago
          A possible solution is to have a separate (otherwise
          unused) package in your codebase with just a test in it:
          //compile_test.go   func TestThatThisModuleCompiles(t*
          testing.T) {}    //list of "type implements interface"
          tests   var _ mymodule.MyInterface =
          myothermodule.MyStruct{}   ...  Then you just ensure that
          `go test` is run, e.g. by the CI.
 
          terminalcommand - 2 hours ago
          That's a clever way to solve the issue. I think most Go
          codebases could benefit from such explicit checks where
          the language does not provide an unambiguous solution.The
          interface issue has been on my mind for quite sometime. I
          had thought maybe declaring all interfaces in seperate
          files might help with the structure (like having the
          definitions in a header file in C), but the Go standard
          library does not use this approach. Interfaces and
          implementations are scattered across files and modules.
          Maybe I'm being too clever and we all know that Rob Pike
          always says that programmers should not be too clever.
          Maybe I should loosen up a bit, and treat Golang more
          like a pragmatic language. They did the best they could
          and produced a wonderful language. Any additional feature
          such as generics and explicit implements statements would
          have made the language much more complex.
 
          cube2222 - 2 hours ago
          Sibling comment shows one way to do it, but in most
          cases, at least for me, which is when both the struct and
          interface are in the same package it gets solved by the
          NewMyInterface method.As it's return type is MyInterface,
          but it actually returns myStructure which causes the
          compiler to check the interface satisfying.
 
        cube2222 - 2 hours ago
        I actually experienced the opposite. Interfaces in go work
        so well, partly because you can create an interface which
        automatically gets satisfied by existing structures. For
        example I often use a requestDoer interface which only has
        the http clients "Do" method.I'm using Goland so I have
        jump to interface from any structure implementing it. So
        that's another one that gets solved by tooling.The
        structurally typed interfaces are actually my favorite part
        about Go probably.
 
          terminalcommand - 2 hours ago
          How do you jump to the interface from any structure
          implementing it? Beside from comments there is no
          immediate way to which interface/interfaces a structure
          is implementing.Maybe Gogland solves this by keeping
          records on all interfaces, and checking all structures
          whether they satisfy them. If that's the case, this is
          definitely solved by tooling.
 
          cube2222 - 1 hours ago
          That's exactly what it does as far as I know.EDIT: I can
          also search for any interface with a struct selected, and
          generated stubs for all method. Well, basically what you
          get for any other language when implementing interfaces.
 
          sythe2o0 - 1 hours ago
          If you need this, you can write type assertion lines in a
          var block of the interfaces that you explicitly want to
          implement (and this will throw compile time errors if
          they don't).
 
          [deleted]
 
          [deleted]
 
          slrz - 32 minutes ago
          The standard godoc documentation browser does this too
          when started with the -analysis option. They all use the
          same source code oracle functionality available from the
          x/tools repo.
 
      donatj - 1 hours ago
      > intuitively you'd think that you could assign any type
      slice to []interface{} but you find out soon enough that
      doesn't workI've been writing Go for upwards of six years,
      professionally for three, and I have never tried that. I
      can't think of the last time I used interface{}...I generally
      consider anything using interface{} crap code someone who
      doesn't know the language wrote, probably coming from a
      loosely typed language.
 
    nine_k - 4 hours ago
    Go does have brilliant simplicity! It's the simplicity of
    Pascal I used in middle school, and of Modula-2 I used on my
    freshman year, with basically the same syntax. I'm glad Go
    revived a number of good ideas from Pascal / Modula /
    Oberon.For writing toy programs to relax (can relate), I
    personally prefer Python, or maybe a Scheme. While also being
    simple at the core concepts, they have much more expressive
    power, an easier way to combine simple things into complex
    things. They pay for that by higher resource consumption, of
    course. I do fondly remember a PDP-11 Pascal compiler reporting
    "15 KB used" after compiling my program; you can't get a Python
    process with these constraints. But by now we have _vastly_
    more computing power.
 
      pjmlp - 1 hours ago
      > I'm glad Go revived a number of good ideas from Pascal /
      Modula / Oberon.Sadly it feels more like Oberon-07 than
      Modula-2, feature wise.
 
      TheOtherHobbes - 3 hours ago
      Go has human-sized simplicity. Programming language
      complexity is limited by human cognitive limitations, and Go
      has a small cognitive load.This makes it feel like a very
      intuitive language.That doesn't mean it is an intuitive
      language - just that it feels like one for a specific class
      of problems.Personally I enjoy using it for the same reasons
      as everyone else. But... I'm also aware it's quite an old-
      fashioned language, with some bumps under the floorboards
      where useful things were hammered down to make them go away,
      instead of being fully solved.
 
        krylon - 16 minutes ago
        There is a good chance you are right.But as long as it is
        humans writing most/all Go code, fitting a human brain well
        is a valid design choice.Yes, it has its fair share of
        problems. But for now, I find it preferable to anything
        else we have got.
 
  moocowtruck - 2 hours ago
  go would be seen as a project of insanity if not been made by
  google; and would most likely be in a field of dead language
  husks
 
  dekhn - 4 hours ago
  Complaints about generics aren't coming from a minority group.
  It's a majority now.
 
    LanceH - 3 hours ago
    The majority may want generics.I don't know that the majority
    want generics at the expense of compile times or other possible
    tradeoffs.
 
      shabbyrobe - 1 hours ago
      This is exactly my feeling. I don't want generics if I have
      to pay anything for them in build time, or if it limits
      go/ast or go/types. A lack of generics has been a pain point
      a couple of times in my current project (beyond what very
      simple code generators can provide), but crazy fast build
      times have been a massive benefit.Imagine how much wailing
      and gnashing of teeth there will be if Go 2 delivers generics
      but with triple the build time and +50% binary size... if you
      thought the minority was vocal now, wait til you see that!
 
    tqkxzugoaupvwqr - 3 hours ago
    How do you know? Anyone who is not interested in generics
    simply abstains from these discussions/polls. This skews
    perception.
 
      dekhn - 3 hours ago
      because people at my company collect data on this.
 
    theshrike79 - 3 hours ago
    People want generics because they think every language should
    have generics.What they don't know is the exact cases where the
    lack of generics causes a real-world problem for them. This is
    what the developers are requesting at the moment, in order to
    possibly bring generics to Go 2.
 
      erik_seaberg - 2 hours ago
      Every statically-typed language needs generics to allow a
      function to be used with more than one type. Otherwise you
      throw away most of the type info and end up with the same
      problems dynamically-typed languages have.
 
  camus2 - 3 hours ago
  > while paying much less attention to the vocal minority's
  complaintsThat's debatable. Those who can't stand the language
  don't bother using it,therefore don't bother complaining about
  it.My point is Go biggest critics have already abandoned the
  language long ago.Go reminds me Rails. It had a huge success 8
  years ago but since all other languages have caught up when it
  comes to RAD webdev. The JVM and others will eventually catch up.
 
  chmln - 1 hours ago
  Go devs who want generics are obviously a minority.Those who care
  about generics enough probably just avoid Go and use another
  language.
 
    pjmlp - 1 hours ago
    If only we could avoid Docker and K8S in the process.
 
  rdsubhas - 4 hours ago
  I'm not sure what you mean by vocal minority's complaints.Golang
  generics is the second most voted issue on GitHub itself: https:/
  /github.com/issues?q=is%3Aopen+is%3Aissue+sort%3Areac...(I'm not
  sure if GitHub sorting is broken, but the same issue has more +1s
  than the top +1d issue as per that sort mode as well)Generics has
  the most experience reports in Go 2 proposal. Maybe this can be
  categorized and excluded as a vocal minority, but above data
  doesn't seem to.
 
    jackmott - 1 hours ago
    the guy is just being a dick.
 
    theshrike79 - 3 hours ago
    They haven't said "No" to generics.What the developers want is
    for people to submit _actual_ problems that generics would
    solve, with examples. Because there are more than a few way to
    do it and they want to pick the right one.
 
      [deleted]
 
        sctb - 3 hours ago
        We've asked you twice before not to do this and now you're
        at it again, so we've banned the account like we said we
        would. If you would like to comment within the guidelines,
        we'd be happy to unban your
        account.https://news.ycombinator.com/newsguidelines.html
 
      erik_seaberg - 3 hours ago
      That's easy. Concurrent access to maps is unsafe.
      https://golang.org/pkg/sync/#Map should be a drop-in
      replacement but due to the lack of generics it can't present
      a compatible or typesafe API.
 
        terminalcommand - 2 hours ago
        I've run into concurrency problems using maps while writing
        an irc client. It was really frustrating for me, because it
        did not happen everytime I ran the program, but rather
        rarely. I had chosen Go for it's memory-safety and easy
        concurrency. But I felt like I could not vouch for my
        program's safety any more. I did not know about sync/map at
        the time, had I known, I would probably have used it.I
        think Golang has a fondness for magical (to me) special
        language constructs. For example if you want to use the RPC
        modules, you have to write your functions a certain way. Or
        as I've explained in a comment above, if you want to use an
        interface you just have to implement all it's properties.
        Or you can't have generics, but we have a special language
        construct called maps, where you kind of can mimick
        genericks but it is not safe and may break.Golang is a
        great language, but I think it expects all its users to
        think very rigidly in the same way their designers do.
        Basically, you have to explore the language's deficiencies
        yourself, read the designers' explanations, dive into the
        intrinsics of the language, understand it, make yourself
        believe and move on. I sometimes half-jokingly feel like
        Golang follows the principle of most obedience.
 
          kjksf - 1 hours ago
          For concurrency issues, -race flag is your friend.Don't
          blame the language for your buggy code.Unless otherwise
          stated, Go's data structures are not thread-safe. Maps
          are not thread safe.In that respect Go isn't different
          from any other mainstream language with pre-emptive
          threading (C++, Java, C#).
 
    qyv - 3 hours ago
    It is a vocal minority in the (probably correct) assumption
    that the majority of Go programmers are not part of that GitHub
    issue, nor any other group asking for Generics.
 
    nine_k - 3 hours ago
    I'm afraid not all votes are (and should be) considered equal
    by the project maintainers. A great number of casual Go users
    might want feature XYZ. OTOH a couple dozen of large Go
    projects, with combined millions MLOCs and hundreds of millions
    of end users, may have a different list of priorities, and
    these priorities might be catered first.Also, let's not forget
    that Go is created at Google, and definitely Google's internal
    projects, likely large-scale by both line count and users
    served metrics, must take priority.Frankly, there is a number
    of reasonably nice languages that do provide generics, good /
    great type systems, good / great package management, decent
    async features, and quite decent performance: Rust, Nim,
    Crystal, ... all the way down to Haskell. Go is not competing
    with them at their strongest features. Instead, it's in the
    sweet spot of simplicity, fast build times, reasonable hygiene,
    and trivial deployment. It's the "getting job done" mentality
    which worked so well for PHP and Perl back in the day. There is
    a considerable demand for that.
 
      coldtea - 1 hours ago
      >I'm afraid not all votes are (and should be) considered
      equal by the project maintainers. A great number of casual Go
      users might want feature XYZ. OTOH a couple dozen of large Go
      projects, with combined millions MLOCs and hundreds of
      millions of end users, may have a different list of
      priorities, and these priorities might be catered first.Many
      large users writing in company and project blogs have
      mentioned lack of Generics as a pain point, so that
      distinction doesn't go very far.>Also, let's not forget that
      Go is created at Google, and definitely Google's internal
      projects, likely large-scale by both line count and users
      served metrics, must take priority.Go was not created through
      some official decree to create a Google language, nor was it
      mandated to be used or to have some timeline to convert other
      stuff to it, etc.It's just a project started by some Go
      people with the idea "let's examine what a language
      appropriate for Google's programming would be" -- but using
      their personal ideas of what Google style programming would
      need, not something requested, researched etc by Google as an
      organization. In other words it started as a glorified 20%
      project, and today it's not any more official in Google than
      C++ or Java is.
 
        nine_k - 27 minutes ago
        I suspect that Rob Pike's and Russ Cox's work is paid for
        by Google.But even if it were not, I suspect that
        heavyweight users like Google do have a weighty say, just
        because of the sheer amount of practical experience they
        have with developing and running software using the
        language. Just like Mozilla, I suppose, do have a say in
        the development of Rust.
 
          steveklabnik - 3 minutes ago
          We?ve actually worked a lot to ensure that Mozilla can?t
          dictate what happens with Rust; we run a consensus based
          process, and while Mozilla has the largest single group
          of people involved in leadership, it?s still a very stark
          minority.As a huge production user, Mozilla?s needs are
          still important to us, but we think of Rust as an open
          source project Mozilla contributes to, not a Mozilla
          project per se.
 
    lossolo - 2 hours ago
    The most vocal group is the always the one that is not happy
    with someone. Doesn't mean this is majority and often it's not.
 
    freyir - 3 hours ago
    It's the biggest issue, but that doesn't mean the majority of
    Go developers support it. 1734 people reacted to the generics
    issue, most in favor, but there are many more Go developers
    than that.But the people who read the proposal and reacted to
    it may be the vocal minority who are concerned about generics.
    The majority may not spend their time reading or reacting to
    proposals they don't care about.
 
      coldtea - 1 hours ago
      >Also, let's not forget that Go is created at Google, and
      definitely Google's internal projects, likely large-scale by
      both line count and users served metrics, must take
      priority.And many more want Generics without having responded
      to the issue.Issues are representative as a sampling, not
      absolute numbers.
 
        skybrian - 17 minutes ago
        Unless you do random sampling, you still can't conclude
        anything one way or the other about whether it's a majority
        of users. Perhaps something like Google Surveys could be
        used to settle this?
 
    jhjwe888 - 2 hours ago
    It should be obvious to folks on HN why a Github issue that may
    go completely unseen by a large swath of the go community, or
    +1's which can be gamed/trolled, should not be taken as a valid
    measure.But it must be explained I guess.
 
brian-armstrong - 2 hours ago
Go is woefully missing some really key features, which you
encounter when tuning it for high performance. My list of
grievances:- Dep handling was never considered. Makes sense given
Google's monorepo but thats not how the world works.- Stdlib just
loosely wraps posix features with many C flags copied verbatim.
These APIs are old and could use a refresh but Go never bothered.-
No easy way to construct arenas/pools. Once you go down this route
you have a great headache of releasing in the right places. The GC
doesn't cut it, you need pools sometimes- Debugging basically
doesn't work on some OSes. No easy way to attach gdb and see what's
happening. Doubly so if you use Cgo- Similarly, Go doesnt bother to
hide the differences of different OSes. Up to you as the
programmer. Again not surprising for Google's all Linux world. If
everything is Linux then OS difference doesnt matter. But even
Python does a better job here.- Logging is poorly thought out as
evidenced by multitude of third-party log packages. Anemic compiler
means you can't get verbose logging without paying a performance
penalty.- No RAII. Defers are a lazy attempt at this, but they're
not even close to being as good as RAII. This is probably the
biggest point where you realize Go can't dethrone C++- Tricky
Close() semantics force you to architect entire program around who
will close() things at end of their lifetime. Lots of terrible
hacks ensue when people build something that works but realize
close ownership is ambiguous and rightfully don't want to rebuild
it all- Channels don't have a good way to deal with errors. You're
forced to come up with an ad hoc solution to deal with your graph
of goroutines/channels when one node errors- No supervision tree.
Erlang existed far before Go but they didn't learn from this key
feature. But it would greatly enhance Go to have it- Hacky
reflection semantics that cause subtle runtime bugs when a JSON
struct field's name starts with a lowercase letter. And of course,
there are no generics, the larger issue here.I was hopeful that Go
would fix some of these things before it went 1.0 and locked in its
syntax. Sadly that didn't happen as it was likely already locked in
at Google. Go is ultimately kind of brain dead, useful for some
very particular features but not so compelling that it can replace
any other language.
 
  Karrot_Kream - 2 hours ago
  I'm not disagreeing with you (I've previously criticized Go here)
  but I think it's helpful to think of Go as a more "modern" C. A
  lot of the warts you see here (Cludgey POSIX interfaces, no smart
  scheduling around channel error handling, bad reflection
  semantics, etc.) are the same as you'd find in C.
 
    brian-armstrong - 2 hours ago
    Except, it's not a compelling replacement of C. The type system
    doesn't give me good assurances about program behavior at
    compile time. Go inserts itself as a heavy unwanted additional
    layer for cases where I want C. Especially considering that now
    my program will have GC pauses.
 
  cannam - 2 hours ago
  > - No supervision tree. Erlang existed far before Go but they
  didn't learn from this key feature. But it would greatly enhance
  Go to have itThis is the one thing in your list that I don't
  recognise. What is a supervision tree? Can you (or another Erlang
  programmer) point to your favourite reference?
 
    nsm - 1 hours ago
    http://www.jerf.org/iri/post/2930 is a really nice blog post
    from an Erlang programmer attempting to bring supervisor trees
    to Go as https://github.com/thejerf/suture.
 
    brian-armstrong - 2 hours ago
    Here's the relevant chapter from Learn You Some
    Erlanghttp://learnyousomeerlang.com/supervisors
 
    masklinn - 1 hours ago
    A supervision tree would be a tree of goroutines where a
    "master" (supervisor) gets notified when children die (normally
    and more importantly abnormally).In Go, if a goroutine panics
    for some reason it just dies on its own and the world does not
    know unless you have some sort of ping service or you
    specifically send a notification from a defer.In Erlang, if a
    process faults and it has a supervisor, the supervisor gets a
    message that one of its children died with some additional
    metadata, it can then log the issue, restart a child, ? This
    also led to an interesting "let it crash" philosophy (since
    Erlang processes have isolated private heaps a process dying
    also cleans up any potential data corruption in the process's
    private state, this is often considered a feature, but at its
    core it mostly avoids processes dying unnoticed.Incidentally,
    supervision is actually the result of two individual features:
    linking and trapping. Linking means that when one process dies
    with an abnormal status (any reason other than regular process
    exit), all process linked to it will also die (the EXIT signal
    gets propagated through the link), which is repeated until all
    linked processes are killed, trapping lets a process handle the
    incoming exit signal in code rather than automatically
    suicideFinally, because supervisors and supervision trees are
    so common the Erlang standard library provides generic
    behaviours which let developers declaratively set up which
    strategies they want in their supervisor, the maximum restart
    frequency (beyond which the supervisor consider the system's
    broken and shuts down), ...
 
  cube2222 - 1 hours ago
  Why would you want a supervision tree?This would suggest using an
  actor-like model, which is pretty senseless for single-machine
  usage. It's totally understandable for Erlang, where the VM spans
  multiple machines, so everything is unreliable, but in Go, I take
  it for granted, that my goroutines won't "just crash".I'm not
  sure, but I think this also ends up being good for modelling
  interactions with good performance, as you know where you do
  network calls, where you have reliability, and where you have
  instant local calls. Though not to say that Erlang applications
  aren't blazingly fast too.
 
hellofunk - 4 hours ago
I find myself wondering how important the "fun facts" are in this
fascinating thread about
Go:https://twitter.com/pasiphae_goals/status/923820615022399488
 
  weberc2 - 3 hours ago
  They're not important. The author admitted she was just
  shitposting. It was an amusing thread, but rife with
  misinformation. If someone wanted valid criticisms of Go, I would
  not send them there.
 
  spraak - 4 hours ago
  Some of those things are true and annoying, while others are
  exaggerations, and the rest are just wrong. That thread is poor
  taste.
 
    vvanders - 4 hours ago
    Yeah, they are (and the author admits as much) but I found>
    Fact #38: go is supposedly a garbage collected language, but it
    has not once deleted itself nor any of my code.pretty
    hilarious.
 
      spraak - 2 hours ago
      Yeah actually that's really funny.
 
shkkmo - 3 hours ago
Go's biggest issues still seems to be the lack of a standard mature
dependency management system.
 
  tetraodonpuffer - 3 hours ago
  this is being addressed in dep, it's obviously not fully ready
  yet but works pretty well in my
  experiencehttps://github.com/golang/dep
 
    shkkmo - 2 hours ago
    Which is why I added the 'mature' qualifier.
 
  bpicolo - 1 hours ago
  Glide is great - it supported the most important feature I cared
  about, which was aliasing for forks where I had to fix bugs.
  "Standard" matters less because there's also no centrally-
  controlled repository of packages, unlike npm/maven/pip
 
  majewsky - 2 hours ago
  I don't know why people are so upset about this. Go standardizes
  enough things about imports and package structure that you can
  completely solve dependency management in literally a shell
  script: https://github.com/holocm/golangvend (I'm using this
  productively for the Go apps that I develop at work).
 
    _seemethere - 1 hours ago
    the issue becomes that there are so many solutions out there
    that going from project to project becomes a pain.Large
    projects use a litany of different tools like glide, dep,
    godeps, vndr, govendor, etc. that managing all of them is a
    pain.What makes it worse is that Golang's official solution
    seems half-baked when compared with other solutions out there.
 
mtgx - 4 hours ago
Can you do something about Golang's performance on Arm servers? It
seems to be terrible compared to x86
performance:https://blog.cloudflare.com/arm-takes-wing/This would
have a positive impact on Google, too, as the more server chip
competition there is, the cheaper it will be for Google to buy
those chips for its cloud services.
 
kown223 - 4 hours ago
For me Go is amazing, is my first language where I don't need a
virtual machine or interpreter to compile to machine code, C++ is
OK but not for day to day web.Changing something then having to
wait 40 seconds for java to recompile drive me crazy, also same for
tests. Yes would love to have a package system, but is coming.
 
  MrBuddyCasino - 4 hours ago
  Java has some flaws, but slow compilation is not one of them.
  Incremental compilers are available and pretty much eliminate
  pauses.
 
    dilap - 46 minutes ago
    Really? I've recently been recruited to pitch in on a Java
    project, they're using maven, and the compiles sure aren't
    incremental.What should we be using instead?
 
    kown223 - 4 hours ago
    I did worked with spring boot and intelijava, and I timed for a
    decent size project it was over 40 seconds, but I believe a lot
    of it was Intelijava compiling, anyway, in go is instant.
 
noncoml - 4 hours ago
Things I love about go:1. Probably the best ecosystem out there.2.
Go routines3. (Enabled by (2) actually) `defer`4. That I can add
interfaces implementations to structs I don?t own5. No
exceptions.Actually (5) is one of the few things I don?t like about
Haskell.If Go had ADTs and generics it would easily be my favorite
language.Edit: and of course the channels.Edit2: yeah, i have no
idea why i connected (2) and (3). Had just woken up. No idea what I
was thinking.
 
  camus2 - 3 hours ago
  Go has (inferior) exceptions, they are called panics. error as
  value is not a feature of the language, it's a convention.> 1.
  Probably the best ecosystem out there.it will when it gets an
  acceptable PDF library, better enterprise integration (SOAP and
  co) and an actual debugger (and no Delve isn't good enough given
  how it often fails at basic debugging).
 
  valarauca1 - 28 minutes ago
  >Actually (5) is one of the few things I don?t like about
  Haskell.Haskell has exceptions
  FYIhttps://wiki.haskell.org/Exception
 
  solox3 - 4 hours ago
  Novice here. Why is having no exceptions a good thing, in your
  opinion?
 
    tqkxzugoaupvwqr - 3 hours ago
    In Go?s philosophy most problems are not exceptional. File
    can?t be opened? This is to be expected on systems with file
    permissions. The common pattern is for functions to return an
    error type as last return argument (Go supports returning
    multiple arguments). Programmers can then handle the problem
    right then and there if the error is not nil. This approach
    also helps to keep control flow straight forward. The happy
    path flows from top to bottom. If an error occurs, it is
    typically handled in an if-block. There are no nested exception
    blocks or exception blocks that follow each other and do things
    far removed from the exception?s origin in the code. As a
    result Go code looks very clean and is easy to follow.
 
    cube2222 - 2 hours ago
    Because it makes you handle errors by value, which makes you
    handle them one by one, and not group everything into one try
    statement.This usually makes the error handling much better and
    better thought through.You can see the same thing happening in
    all the functional languages using the Either monad instead of
    exceptions.
 
    stcredzero - 4 hours ago
    Exceptions are one of those things which are really nifty when
    programming in the small. However, they can create outsize
    problems when programming in the large.
 
    nine_k - 4 hours ago
    For exceptional, unforeseen situations you do have exceptions,
    aka "panic".For signaling error conditions that the caller has
    to expect and handle, you have the `result, err = func(...)`
    idiom, and a compiler that would warn you if you forget to use
    the value of `err`.If Rob Pike's opinion on this is not enough,
    here's Martin Fowler saying essentially the same thing: https:/
    /martinfowler.com/articles/replaceThrowWithNotificati...In
    general: http://wiki.c2.com/?DontUseExceptionsForFlowControl
 
      pcwalton - 3 hours ago
      Go does not warn you if you forget to handle an error. It
      only does so if the function in question also returned a
      value that you're using. There exist important functions that
      don't return non-error values and report errors that you very
      much would like to avoid dropping on the floor: os.Chdir()
      for example.
 
        garfij - 31 minutes ago
        While this is technically true, I've considered `errcheck`
        to be standard tooling for what feels like forever now, and
        it does exactly this; make sure you're checking your
        errors.
 
      atmosx - 4 hours ago
      I?ve read the first article. It was eye opening, cause I am
      writing a bot right now and using exceptions to control input
      flow. Made me think about my design.That said, it does not
      argue against exceptions. So, I am not sure what your
      argument is.
 
        simon_o - 2 hours ago
        Exceptions are bad outside the "your computer just started
        burning" cases, but Go has replaced them with something
        even worse, "multiple return values".So instead of some
        imagined return of "int or throw Exception" you now have
        "(int, error)", which basically means that the result of a
        function call can be any of these four options:  - (
        value, no error)   - (no value,    error)   - (   value,
        error)   - (no value, no error)  And due to the lack of
        Generics you can't abstract over your error handling.And
        due to the lack of proper ADTs you can't even properly
        model "value OR error" manually.
 
  tonyedgecombe - 4 hours ago
  Lack of exceptions is the main reason I won't use it.
 
    [deleted]
 
    mohaine - 4 hours ago
    I thought this as for a long time.  Then I used go for awhile
    and I think I like the go way better.  It solves the issues I
    had with execptionless languages without all the noise.With
    exceptions you most often just let them trickle up the call
    chain, which is the same thing you often do with err, just
    return it.And the returning the err works much better when
    doing async.  Cross thread exceptions are a PITA and you are
    basically back to just returning an error obj.
 
      dualogy - 3 hours ago
      On the whole I agree that I prefer Go's explicit error
      returns over other languages implicit "alt-return paradigm"
      aka exceptions. But you're really well advised here to run a
      couple of linters occasionally that inform about
      ignored/unchecked/non-passed-on errors, it can happen all too
      easily while "rodeo-coding" prototypes/MVPs
 
  dualogy - 3 hours ago
  > If Go had ADTsIn the process of hacking on my PureScript2Golang
  "transcompiler", I've realized that under the hood ADTs, also
  known as "tagged unions", will likely more often than not be
  represented exactly as just that: a "tag flag" and a data
  pointer. (Of course if all of an ADT's ctors are nullary, an
  enumish int will do the trick just as well --- I doubt this gains
  anything over interface{}-boxed 0-size struct type-defs though in
  reality.)Now the natural "box"/container for this tag+content
  pattern in Go is the `interface{}` that can hold as 'content' any
  of your "constructors" (whether it be a struct or type-alias or
  prim type), plus your 'tag' pattern-matchings translate to Go's
  type-assertions. You see this also whenever ADTs are translated
  to JS or OOP languages, in some manner the "type" tag is carried
  along to be able to switch-case on.Anyway, you can do poor-man's
  ADTs as per above today. The catch is that you get fewer compile-
  time checks (won't check for pattern exhaustiveness in your
  switch-cases, or illegal/impossible/invalid (as per your custom
  "dumb" ADT layouts) type assertions).But anyone who's done some
  linked lists or devised parser ASTs in Go has written "ADTs" in
  this manner --- whether by intention or inadvertently
  =)Personally, I don't care about Generics now that I'm aiming to
  generate low-level Go code for PureScript's parametric
  polymorphism and higher-kinded types system.. --- expressive
  beyond the old-school oop/imperative "generics" band-aid  ;)>
  That I can add interfaces implementations to structs I don?t
  ownWait, did I miss out on some new feature only recently
  introduced? The way I parse your above statement, it sounds like
  you could define methods for receiver types imported from other
  packages, is that what you meant? Or did you simply have
  classical workarounds in mind, such as type-aliasing or set-
  the-"method"-as-a-struct's-func-typed-field?
 
  majewsky - 2 hours ago
  Defer is not enabled by goroutines. C++ has `defer` as well,
  although it's called "destructors" there.
 
  [deleted]
 
  nine_k - 4 hours ago
  I wonder how the presence of ADTs and absence of generic
  functions would mesh together.With ADTs, using a sum type instead
  of the `result, err = func(...)`, would be an obvious thing to
  do. But the next thing you'd consider would be `bind` / `>>=`.
 
    ori_b - 4 hours ago
    I'm not sure why the next thing you'd consider is bind. It
    seems like plenty of languages with ADTs and generics still
    either don't have it available in their libraries, or use it
    extremely lightly, in spite of being able to implement it.
 
      nine_k - 3 hours ago
      I'm referring specifically to the error-handling situation.If
      you replace the two-value assignment with an `Either`, it
      feels very natural to also eschew the constant `if (err !=
      nil) return err` lines, and adopt a continuation-passing
      style, the way you do with Futures in JavaScript. You could
      even consider some syntactic sugar around it, like the `?`
      operator of C# and Kotlin, or a full-on Haskell-like do-
      notation.
 
        ori_b - 2 hours ago
        Again, it doesn't seem like this is something that many
        communities do, in spite of having languages that support
        it. The '?' operators in the languages you cited, as far as
        I recall, are specific to null, and don't work on generic
        option types.
 
  sigzero - 4 hours ago
  #5 is not a positive thing.
 
    noncoml - 4 hours ago
    Depends IMHO. I love exceptions in Python, find them a bit ugly
    in Java and hate them in Haskell.
 
  oconnor663 - 4 hours ago
  What's the connection between `defer` and goroutines?
 
    shurcooL - 3 hours ago
    Not a strong connection, but both features are managed by the
    Go runtime.
 
    camus2 - 3 hours ago
    None, the feature that completely depends on defer is
    recovering from panics.The order in which defer statements are
    executed is predictable, unlike goroutines.
 
    noncoml - 2 hours ago
    Yeah, none. I wrote this while still in bed. No idea what I was
    thinking at the time :D
 
  wheaties - 4 hours ago
  The best ecosystem out there? Since when? I'd say that Java and
  Python have huge, wonderful and full ecosystems. Golang doesn't
  even come close to that, yet. Furthermore, Golang  doesn't even
  have a community standard (or several standards) dependency
  manager.
 
    pmoriarty - 3 hours ago
    Python's packaging is a nightmare of half-baked, incompatible
    approaches that puts the lie to the famous "Zen of Python" that
    "There should be one-- and preferably only one --obvious way to
    do it."
 
      freyir - 3 hours ago
      Bold choice.
 
      qaq - 3 hours ago
      and yet Pipenv is miles ahead of what Go has to offer.
 
      [deleted]
 
    noncoml - 2 hours ago
    Fair enough. I should have said one of the best. A bit of
    sensualism there.