10 ms·

> Go type system is not a traditional type system and it was not possible just to bring an existing generics implementation from other language and be done. I

• verdverm 5y ago
  While not necessarily part of the language, but arguably part of Go, something novel is the dep mgmt system. I have not encountered the MVS algorithm in another language. CUE is intending to adopt it.
  • pxc 5y ago
    Where can non-Go (for now!) developers read about this to get a sense of what makes it interesting?
• randomdata 5y ago
  Go's generics have been in development (by the same person) since the pre-1.0 days, with various proposals submitted for their inclusion. Are you suggesting that those earlier proposals failed for frivolous reasons rather than real technical concerns? It seems to me that that it was less about active pushback and more that people who cared about having generics in Go was limited to an exceedingly small group of people who weren't necessarily experts in the subject matter. In fact, the Go team hired an external expert to lay the groundwork for what became the winning proposal.
• anonymoushn 5y ago
  A great innovation of Go is that it includes a built-in reference type with both inner nils and outer nils.
  • kubb 5y ago
    It is a bit like void *outer = 0; // outer can be nil int val = 5; int *inner = &val; // inner can also be nil outer = (void*)(&inner) // can have an inner value, inner nil or outer nil
    • masklinn 5y ago
      It's not really like that, this is two nested but different values which can be nil (not exactly independently but close). typed nils are a single value which is both nil and non-nil at the same time.
      • throwaway894345 5y ago
        You're mistaken. An interface is simply a reference type--like other reference types, it may refer to a type which is itself a reference type. The outer reference may be not-nil while the inner reference may be nil, which confuses people who don't understand references into believing that there is a single value which is both nil and not-nil at once. It's no different than `var x **int` (a variable called "x" whose type is a pointer to a pointer to an int). If you want to safely access the underlying integer data, it's not sufficient to check that the outermost reference is not nil--you must also verify that the inner reference is not nil. We run into this in every language with nullable reference types, including C, Java, Python, JavaScript, etc. EDIT: `*int` -> `**int`. TIL HN converts two asterisks into one.
        • masklinn 5y ago
          > An interface is simply a reference type--like other reference types, it may refer to a type which is itself a reference type. The outer reference may be not-nil while the inner reference may be nil, which confuses people who don't understand references into believing that there is a single value which is both nil and not-nil at once. None of that is correct. The value-part of the fat pointer is the exact same in both situations: nil. It is a single value which is both nil and non-nil. > It's no different than `var x **int` I assume you meant that rather than what you actually wrote. It is in fact quite different. > If you want to safely access the underlying integer data, it's not sufficient to check that the outermost reference is not nil--you must also verify that the inner reference is not nil. Something a typed nil does not let you do, unless you know (or reflect) the underlying concrete type in order to downcast the interface back to a regular pointer. > We run into this in every language with nullable reference types, including C, Java, Python, JavaScript, etc. We really don't. In "every language" you have to actually create a double indirection for something within the same heavenly realm (but is not at all the same thing) to occur.
• throwaway894345 5y ago
  This seems like a straw man. I don't think anyone has claimed Go's type system has novel features. > the reason it took so long was because it came out of an environment with actors (including a part of the community) pushing against the feature. The reason it took so long is because it simply wasn't the biggest fish to fry. Generics are a massive feature, and there were a lot of other opportunities to deliver more value for considerably less work. Of course, there was a healthy amount of pushback against rushing generics, considering generics must interact with every other feature in the type system even if those features aren't novel. Frankly, people make too big a deal about generics. It will be a neat quality of life improvement for certain kinds of code, and a lot of additional code will enter the ecosystem which is gratuitously abstract. Builds will probably get a fair bit slower on average while still being fast relative to most other languages. Frankly, no type system feature will ever impact a language as significantly as things like tooling quality, ecosystem, runtime performance, static+native compilation, iteration loop time, learning curve, etc.
  • masklinn 5y ago
    > I don't think anyone has claimed Go's type system has novel features. The third phrase of the linked essay is: > Go type system is not a traditional type system "non-traditional" is generally read as "novel" in some way.
    • Vendan 5y ago
      That's a bit of a stretch... If someone made a language that directly copied Haskell's type system, I'd 100% call it a non-traditional type system, but there would be nothing novel about it.
    • throwaway894345 5y ago
      You're mistaken here. "non-traditional" doesn't mean "novel", it just means "something that isn't traditional". For example, eating cereal for dinner is non-traditional, but that doesn't mean no one has done it before.
  • kubb 5y ago
• deleted 5y ago
  [deleted]
• phillipcarter 5y ago
  > You might disagree, I'm curious what original features of Go you will point out to me. I think only insiders on the Go team during that time period can really say for sure what the deal is. But I will say that retrofitting generics onto a language and standard library is a project of enormous scope and incredible difficulty. So I'm pretty sympathetic to the idea that it took them a while.
  • krzat 5y ago
    Thoughts and prayers to the Go team. I suspect they got kinda forced into implementing this, otherwise generics would be available from the start.
    • phillipcarter 5y ago
      I would say - congratulations to the Go team! It's a huge accomplishment and a testament to the quality of their software engineering process.
  • eweise 5y ago
    Guess there's a downside to making a too simple language and then trying to bring it up to modern day standards over time.
• jjtheblunt 5y ago
  to your point, isn't Go just the Google-funded continuation of Bell Labs' Limbo, with essentially the same people? If so, it's curious how sparsely mentioned the origin at Bell Labs pre Google is. https://en.wikipedia.org/wiki/Limbo_(programming_language) https://en.wikipedia.org/wiki/Limbo_(programming_language)
• 1_player 5y ago
  What is the point of going into Go generics posts on HN and making a point to mention that core Go developers were against the feature, which is incorrect, but also shows there's some axe to grind against that team. Is that to show they're less smart then they think they are? I swear there's at least one top-level comment such as yours in every thread, for no reason other than just to discredit people's work. I find it disgraceful.
• skybrian 5y ago
  Unusual doesn't mean unique or better, just different enough to make doing a straight port harder. For example, Go's interface types and its lack of constructors seem different from most languages you might borrow from.