12 ms·

Go: Don't Change the Libraries in 1.18

183 points by dbattaglia 5y ago

sph 5y ago
tl;dr: We're shipping generics in 1.18, it's a huge release so let's wait a little bit until they stabilise and they're used in production before changing our stdlib. Good call in my book, and I'm extremely excited to have generics finally. I thought they were going to ship with 2.0, but the sooner the better! It's cool to hate on Go, it's taken over the system programming space for a reason, like it or not, and after working full time on Elixir it's hard not to think in map/reduce and other generic constructs, which were unreasonably verbose before in Go. Now the haters will have to focus on the "if err != nil" statement to pile on the language — though to be fair I'll expect some ergonomic improvement on that aspect as well, eventually. With generics, Go will be my new Python, but with a decent dependency and deployment story, and I'll just need Zig for my low-level manual memory management needs. What's Rust? EDIT: indeed being a bit cheeky with HN's favourite language isn't well received in this place.
- pjmlp 5y ago
  Go has taken over kuberbetes related stuff, that is all. Although I like it being used for systems programming stuff like TinyGo on embedded or F-Secure TamaGo unikernel, that is hardly taking over the domain where C and C++ still rule, and will keep to do so for decades to come, despite the increasing usage of Rust on the domain.
- EdwardDiego 5y ago
  At least now we can write a generic set that supports all the things you want a set to do, instead of using map[T]interface{} and a lot of for loops.
  - everybodyknows 5y ago
    >map[T]interface{} If the semantics desired are merely those of a simple set, why instantiate storage for the value side of the map? An interface{} consumes 16 bytes. Instantiating a struct{}, i.e. with no fields inside, consumes 0 bytes.
    - Shish2k 5y ago
      Because when a language doesn’t supply common features out of the box, users implement them for themselves, and inevitably a lot of them do a bad job of it :)
    - EdwardDiego 5y ago
      Ah yeah, that's right, it was map[T]struct{} - it's been a bit since I had to do it. I knew it was something with curly brackets instead of the map[T]bool I started using.
    - vips7L 5y ago
      More reasons to have a generic Set type in the standard library. That way you know the implementation is correct every time.
- paedubucher 5y ago
  Brad Fitzpatrick stated in one of his talks, that a version of Go coming with generics will be called 2.0 eventually. Maybe they do the version jump if there are backward-incompatible changes done to the library in 1.19.
  - leaveyou 5y ago
    When was that ? IIRC that was the general feeling then but the impression has changed in the mean time ?
- cageface 5y ago
  Lack of null safety is still a major shortcoming in my book compared to Rust/Swift/Typescript.
  - everybodyknows 5y ago
    null safety: Can you provide us a reference to a working definition of the term?
    - cageface 5y ago
      For example in Typescript, you can specify whether a parameter is allowed to be null in the signature of a function. If you do the compiler will make sure that you don't accidentally pass a null value to that function. function foo(x: number) { return x + 1; } let y = null; foo(y); // compiler will flag this
      - drvd 5y ago
        In Go func foo(x int) { return x + 1 } var y *int = nil foo(y) // compiler will flag thi
        Gwypaas 5y ago
        Now add an error to foo and have x=0 as a valid return value, or even worse, having to deal differently with different errors.
        cy_hauser 5y ago
        That wasn't the greatest example as Go doesn't really have any way to represent it. If it did it might be something like this. type MyStruct struct { Name string } var-not-nil myStruct = &MyStruct{"Hello"} // this is a "not-nil" pointer variable myStruct = nil // compiler would catch this The idea being to allow variables to hold and pass pointers to structs like now but ensure they are never nil.
    - Macha 5y ago
- throw_m239339 5y ago
  > It's cool to hate on Go, criticism =/= hate Nobody "hates" on Go for the sake of it. If some people were not critical of that language, generics would have never been added at first place. I'm glad the Go team acknowledged the flaw instead of the gaslighting that has been going on for years in the go community from a few go users.
  - 1_player 5y ago
    Calling it "gaslighting" is exactly what a hater would do. It's not very constructive. Generics were a pain point, but people have been crapping on Go on this forum while people out there are using it to build stuff. It's not a perfect language, but if you read any HN thread about it it's like it's impossible for people to go past the lack of generics or the existence of nil.
    - sanderjd 5y ago
      It is a good use of the word "gaslighting", which I think can be defined as "an effort to convince someone that they do not know a thing that they do know". In this case, a lot of people know from lots of experience that writing type safe generic code is extremely useful, but the go community spent a long time arguing that people could not have had that experience because writing generic code isn't actually useful. This isn't really my impression of what the go team was saying, which I interpreted as more like "parametric polymorphism is useful but we aren't sure it is a good fit with the simple language design we are seeking to maintain". That's totally reasonable, everything is trade offs, but that's not the prevailing pushback you would get from the go community, you'd instead hear a message more like "if you'd rather write generic code instead of copy pasting constantly, you're a bad programmer who doesn't get it", which is not helpful and yes, I think gaslighting is a reasonable description. The existence of nil is also a design flaw. But you're right that no language is perfect and neither of these flaws keeps people from building tons of useful stuff with the language. I think there is definitely gaslighting in the other direction too, which is what you're highlighting: lots of people know from experience that go is a super useful language, but then people come of as saying "your experience does not exist, it is not a useful language because of these big design flaws".
- the_duke 5y ago
  > it's taken over the system programming space for a reason I'm curious what you define as systems programming, because Go certainly isn't a systems programming language by the classic definition. Go has a complicated runtime and GC. It's really not in the same category as C/C++/Rust, but more like Java/C# , just without a JIT. The only domain where Go is a go-to language is the Kubernetes ecosystem. It's also decently popular for networking heavy applications / microservices / server applications, because the runtime is well suited for those domains.
  - Zababa 5y ago
    Go is basically a systems programming language if you consider """the cloud""" a system, a big part of the ecosystem is built on it. It is basically between C/C++/Rust and Java/C#, which is "good enough".
    - fsociety 5y ago
      In that case JavaScript is a systems programming language if you consider the web a system. Golang having GC and a heavy runtime make it unsuitable for systems programming IMO.
      - pjmlp 5y ago
        It isn't unsuitable per se, but it definitly lacks the knobs of something better like D, C# or Nim. https://www.packtpub.com/product/creative-diy-microcontroller-projects-with-tinygo-and-webassembly/9781800560208 https://www.packtpub.com/product/creative-diy-microcontrolle... https://www.f-secure.com/en/consulting/foundry/usb-armory https://www.f-secure.com/en/consulting/foundry/usb-armory
      - Zababa 5y ago
        Not exactly, the web runs on browsers and web engines that are written in C++, and servers that are mostly C and/or C++. On the other hand, "the could" runs (partially) on k8s and friends, which are written in Go (which runs on servers, written in C and/or C++).
  - 5y ago
- stjohnswarts 5y ago
  That's because you can put out there why you like a language and people will upvote you. Dump on other people's choice in a systems language and you will likely suffer some down votes. Cheeky has a price.
- another_Hans_M 5y ago
  No need to disrespect Rust. I like both. And certainly they both have their proper use cases.
nine_k 5y ago
A good call, and probably the most reasonable decision in their situation. OTOH this removes much of the point to use generics, and makes working with stdlib from type-parametric code more painful. Still great to see things improving. It took mere 11 years.
- throw_m239339 5y ago
  > Still great to see things improving. It took mere 11 years. Took that much time because of little clique of people outside the go team had way too much influence in the Go community. Let see if they dump the language like they threatened to, as the result of adding generics. Of course they won't. Generics are there if one wants to, and they aren't like Java, but ADA. ADA got a lot of things right decades ago including the way tasks work from which Go routines should have taken a bit more inspiration . Congrats to the Go time anyhow.
  - stevekemp 5y ago
    I suspect a lot of people outside the go-team made comments, suggestions, and proposals. But honestly, thinking back damn few of them resulted in changes to the language. If you'll recall back in the day there were several different vendoring approaches, but ultimately the go-team proposed and implemented their preferred solution. Similarly there have been a million generics & error-handling suggestions but none of them were introduced. It's basically lots of distracting discussions, and it doesn't feel so much like a community project that is actually seeking outside discussion and ideas. (No shame in that, but the pretense is disappointing). Personally I'm waiting for the fuzzing-support to land in 1.18. Fuzz testing is basically magical, and amazing in reporting problems even in code with "high coverage". The generics might be nice, but off-hand I don't see that I'll be needing them in the immediate future in any of my personal projects - but I fuzz-test the hell out of a lot of my projects (which largely revolve around interpreters and compilers).
    - ithkuil 5y ago
      Those community efforts may have not been have adopted, but that doesn't mean their existence hasn't informed the Go team's solution
cube2222 5y ago
Also think this is a good call. Though the second comment has merit too, I think it would be good to have some common abstraction right away, like we had io.Writer, io.Reader, etc. so everybody doesn't define their own, as it'll take time to crawl out of that. Although in practice it did work out well with error wrapping which was first in libraries and then the stdlib defined an interface for them, which resulted in all libraries adopting that. > Similarly, if constraints isn’t part of 1.18, there will be a lot of independent redefinitions of orderable types. I don’t think we’re going to learn from experience much that could change that package now.
qaq 5y ago
Yes let's fracture the ecosystem with a bunch of libs doing generic map, slice etc. Cause there is no way to figure out how to do it right as this is a very novel feature that no other lang has
- Strom 5y ago
  Go is not in the business of copy-pasting other language designs. That much should be obvious by now. The questions aren't around the algorithms. They're about Go specific things like how to deal with legacy std library parts that are made obsolete by generics.
  - qaq 5y ago
    Yes NIH at Google is on the level of it's own. Look at any ecosystem that used this logic to push something off and you will see a badly fractured community that never fully reconsolidates. I'd rather depend on std lib with warts than have my deps depend on 3 incompatible versions of generic map from 3 dif. libs.
    - marcus_holmes 5y ago
      Simple solution: don't use a dep that uses generics until the fracturing is gone. Take the same approach as the Go team and let the use of generics mature and a consensus build on where/how they should be used. There's no need for generics in the short term. We've survived for 11 years without them, we can manage another couple while we work out how to best use them.
      - qaq 5y ago
        So you will drop any existing dep your project has that adopts generics ?
        yalue 5y ago
        Fortunately, they fixed dependency management first, so you can simply stop updating any dependency that adopts generics!
The_rationalist 5y ago
How can people still use this toy language..
dathinab 5y ago
Hm, shouldn't they first update the (most important/interesting) libraries in a fork before stabilizing generics? I mean designing a feature in a clean room is one think, but using it a the standard library would be a good way to know if they messed up the design in some way.
- spockz 5y ago
  Yes that would be a good idea. However, they could already have a generic collection lib in the same place (branch/repo) where the generics feature is created.
  - lbhdc 5y ago
    This is what Rob proposes in this issue. > I propose we still design, build, test, and use new libraries for slices, maps, channels, and so on, but start by putting them in the golang/x/exp repository.
kubb 5y ago
What will likely happen is that the users will design generic libraries themselves. There will likely be a couple, and eventually they will converge on the most useful features. Then the Go team can just get inspiration from that I guess. I'm excited about the prospect of having iterators. It will enable a different, more consistent programming style. I'm also hoping for immutable collections, even though the lack of specialization will make it more difficult to implement them efficiently. They would enable a more robust way to build concurrent systems.
- cy_hauser 5y ago
  Or, if history is a guide, there will be a few really nice generic libraries written and a sizable minority of developers will adopt them as pseudo standard to fill the void. Then the Go team will do what they want, fracture the community, and alienate those who expected your described path to be the one taken.
  - chrsig 5y ago
    I think they've been worse about this w.r.t. tooling (dep comes to mind. The closest thing I can think of along this path for the standard library would be how they've handled errors, and deciding to go their own way instead of adopting dave cheney's pkg/errors[0] they do definitely seem to have some NIH syndrome at times, but I can't say that as time has progressed that I haven't come to appreciate the decisions they've made that seemed controversial at the time. [0] https://github.com/pkg/errors https://github.com/pkg/errors
    - SPascareli13 5y ago
      Wait, isn't Wrap and other pkg/errors proposals used in the current stdlib? I thought they officially accepted that package as the default errors package.
      - chrsig 5y ago
        No, they didn't adopt pkg/errors into the stdlib. pkg/errors did get updated to work nicely with the changes that they did incorporate https://pkg.go.dev/errors https://pkg.go.dev/errors
olingern 5y ago
JavaScript/TypeScript changes so much that a codebase will look very different from one year to the next. JS/TS has come a long way and needed to make substantial change, but I appreciate the slow moving, methodical nature in which the Go team moves the language and environment forward.
- shp0ngle 5y ago
  The negative is that some issues are really hard to fix, because you don’t want to break the backwards compatibility guarantee. For example, there is a bug in go’s built-in HTML templating, that it misrepresent javascript backticks. If you do <script> var string = `http://google.com http://google.com` </script> in HTML template, it will interpret // as a comment and return <script>var string = `http:</script> This is now really hard to fix; it means either rewriting the JS parser from scratch, but that is a giant change (currently the JS parser is really simple, backticks are hard to do properly without reimplementing all from scratch); the more reasonable choice would be to just ban backticks in HTML templates, but that would break backward compat. So there is basically an unfixable bug sitting in go html templates. https://github.com/golang/go/issues/9200 https://github.com/golang/go/issues/9200
  - rytill 5y ago
    If it’s bad enough, why not release a v2 of the library?
    - jen20 5y ago
      The standard library seems to only be versioned with the language. An external v2 could work, but I’m not sure there’s any precedent for a v2 of a standard library package.
      - theli0nheart 5y ago
        > I’m not sure there’s any precedent for a v2 of a standard library package. urllib/urllib2 in Python is one example. There are others; it's not really unprecedented.
crnkofe 5y ago
I was really looking forward to getting some basic generic standard library funcs. Guess what I'm getting now is a a ton of std libraries each with a slightly different approach, slightly different bugs and update cycles which will nicely inflate the amount of tech debt in existing codebases. I guess from the standpoint of a language designer it makes life a bit easier not to do anything and just cherry pick the winners of the various generic attempts that the community will create but as an app. developer I find this disturbing. Also I question the rush to a release all of a sudden. Generics took years to come to fruition. Another year for a decent stdlib won't really hurt anyone and for those that really really want it they can enable it through build constraints.
nyanpasu64 5y ago
C++17 introduced std::optional and std::variant, but they're not used by the standard library in 2021, as far as I've seen (unlike Rust which is better off for using them). It feels quite like a missed opportunity to produce more ergonomic APIs (though the inability to produce an optional<T&> is limiting, and std::variant is inefficient at compile and possibly runtime and apparently can't be fixed because ABI). I'm not a Go user, but I dislike multiple competing approaches to problems without clear guidance or fully embracing newer approaches.

183 points by dbattaglia 5y ago

sph 5y ago

tl;dr: We're shipping generics in 1.18, it's a huge release so let's wait a little bit until they stabilise and they're used in production before changing our stdlib. Good call in my book, and I'm extremely excited to have generics finally. I thought they were going to ship with 2.0, but the sooner the better! It's cool to hate on Go, it's taken over the system programming space for a reason, like it or not, and after working full time on Elixir it's hard not to think in map/reduce and other generic constructs, which were unreasonably verbose before in Go. Now the haters will have to focus on the "if err != nil" statement to pile on the language — though to be fair I'll expect some ergonomic improvement on that aspect as well, eventually. With generics, Go will be my new Python, but with a decent dependency and deployment story, and I'll just need Zig for my low-level manual memory management needs. What's Rust? EDIT: indeed being a bit cheeky with HN's favourite language isn't well received in this place.

pjmlp 5y ago
Go has taken over kuberbetes related stuff, that is all. Although I like it being used for systems programming stuff like TinyGo on embedded or F-Secure TamaGo unikernel, that is hardly taking over the domain where C and C++ still rule, and will keep to do so for decades to come, despite the increasing usage of Rust on the domain.
EdwardDiego 5y ago
At least now we can write a generic set that supports all the things you want a set to do, instead of using map[T]interface{} and a lot of for loops.
- everybodyknows 5y ago
  >map[T]interface{} If the semantics desired are merely those of a simple set, why instantiate storage for the value side of the map? An interface{} consumes 16 bytes. Instantiating a struct{}, i.e. with no fields inside, consumes 0 bytes.
  - Shish2k 5y ago
    Because when a language doesn’t supply common features out of the box, users implement them for themselves, and inevitably a lot of them do a bad job of it :)
  - EdwardDiego 5y ago
    Ah yeah, that's right, it was map[T]struct{} - it's been a bit since I had to do it. I knew it was something with curly brackets instead of the map[T]bool I started using.
  - vips7L 5y ago
    More reasons to have a generic Set type in the standard library. That way you know the implementation is correct every time.
paedubucher 5y ago
Brad Fitzpatrick stated in one of his talks, that a version of Go coming with generics will be called 2.0 eventually. Maybe they do the version jump if there are backward-incompatible changes done to the library in 1.19.
- leaveyou 5y ago
  When was that ? IIRC that was the general feeling then but the impression has changed in the mean time ?
cageface 5y ago
Lack of null safety is still a major shortcoming in my book compared to Rust/Swift/Typescript.
- everybodyknows 5y ago
  null safety: Can you provide us a reference to a working definition of the term?
  - cageface 5y ago
    For example in Typescript, you can specify whether a parameter is allowed to be null in the signature of a function. If you do the compiler will make sure that you don't accidentally pass a null value to that function. function foo(x: number) { return x + 1; } let y = null; foo(y); // compiler will flag this
    - drvd 5y ago
      In Go func foo(x int) { return x + 1 } var y *int = nil foo(y) // compiler will flag thi
      - Gwypaas 5y ago
        Now add an error to foo and have x=0 as a valid return value, or even worse, having to deal differently with different errors.
      - cy_hauser 5y ago
        That wasn't the greatest example as Go doesn't really have any way to represent it. If it did it might be something like this. type MyStruct struct { Name string } var-not-nil myStruct = &MyStruct{"Hello"} // this is a "not-nil" pointer variable myStruct = nil // compiler would catch this The idea being to allow variables to hold and pass pointers to structs like now but ensure they are never nil.
  - Macha 5y ago
throw_m239339 5y ago
> It's cool to hate on Go, criticism =/= hate Nobody "hates" on Go for the sake of it. If some people were not critical of that language, generics would have never been added at first place. I'm glad the Go team acknowledged the flaw instead of the gaslighting that has been going on for years in the go community from a few go users.
- 1_player 5y ago
  Calling it "gaslighting" is exactly what a hater would do. It's not very constructive. Generics were a pain point, but people have been crapping on Go on this forum while people out there are using it to build stuff. It's not a perfect language, but if you read any HN thread about it it's like it's impossible for people to go past the lack of generics or the existence of nil.
  - sanderjd 5y ago
    It is a good use of the word "gaslighting", which I think can be defined as "an effort to convince someone that they do not know a thing that they do know". In this case, a lot of people know from lots of experience that writing type safe generic code is extremely useful, but the go community spent a long time arguing that people could not have had that experience because writing generic code isn't actually useful. This isn't really my impression of what the go team was saying, which I interpreted as more like "parametric polymorphism is useful but we aren't sure it is a good fit with the simple language design we are seeking to maintain". That's totally reasonable, everything is trade offs, but that's not the prevailing pushback you would get from the go community, you'd instead hear a message more like "if you'd rather write generic code instead of copy pasting constantly, you're a bad programmer who doesn't get it", which is not helpful and yes, I think gaslighting is a reasonable description. The existence of nil is also a design flaw. But you're right that no language is perfect and neither of these flaws keeps people from building tons of useful stuff with the language. I think there is definitely gaslighting in the other direction too, which is what you're highlighting: lots of people know from experience that go is a super useful language, but then people come of as saying "your experience does not exist, it is not a useful language because of these big design flaws".
the_duke 5y ago
> it's taken over the system programming space for a reason I'm curious what you define as systems programming, because Go certainly isn't a systems programming language by the classic definition. Go has a complicated runtime and GC. It's really not in the same category as C/C++/Rust, but more like Java/C# , just without a JIT. The only domain where Go is a go-to language is the Kubernetes ecosystem. It's also decently popular for networking heavy applications / microservices / server applications, because the runtime is well suited for those domains.
- Zababa 5y ago
  Go is basically a systems programming language if you consider """the cloud""" a system, a big part of the ecosystem is built on it. It is basically between C/C++/Rust and Java/C#, which is "good enough".
  - fsociety 5y ago
    In that case JavaScript is a systems programming language if you consider the web a system. Golang having GC and a heavy runtime make it unsuitable for systems programming IMO.
    - pjmlp 5y ago
      It isn't unsuitable per se, but it definitly lacks the knobs of something better like D, C# or Nim. https://www.packtpub.com/product/creative-diy-microcontroller-projects-with-tinygo-and-webassembly/9781800560208 https://www.packtpub.com/product/creative-diy-microcontrolle... https://www.f-secure.com/en/consulting/foundry/usb-armory https://www.f-secure.com/en/consulting/foundry/usb-armory
    - Zababa 5y ago
      Not exactly, the web runs on browsers and web engines that are written in C++, and servers that are mostly C and/or C++. On the other hand, "the could" runs (partially) on k8s and friends, which are written in Go (which runs on servers, written in C and/or C++).
- 5y ago
stjohnswarts 5y ago
That's because you can put out there why you like a language and people will upvote you. Dump on other people's choice in a systems language and you will likely suffer some down votes. Cheeky has a price.
another_Hans_M 5y ago
No need to disrespect Rust. I like both. And certainly they both have their proper use cases.

nine_k 5y ago

A good call, and probably the most reasonable decision in their situation. OTOH this removes much of the point to use generics, and makes working with stdlib from type-parametric code more painful. Still great to see things improving. It took mere 11 years.

throw_m239339 5y ago
> Still great to see things improving. It took mere 11 years. Took that much time because of little clique of people outside the go team had way too much influence in the Go community. Let see if they dump the language like they threatened to, as the result of adding generics. Of course they won't. Generics are there if one wants to, and they aren't like Java, but ADA. ADA got a lot of things right decades ago including the way tasks work from which Go routines should have taken a bit more inspiration . Congrats to the Go time anyhow.
- stevekemp 5y ago
  I suspect a lot of people outside the go-team made comments, suggestions, and proposals. But honestly, thinking back damn few of them resulted in changes to the language. If you'll recall back in the day there were several different vendoring approaches, but ultimately the go-team proposed and implemented their preferred solution. Similarly there have been a million generics & error-handling suggestions but none of them were introduced. It's basically lots of distracting discussions, and it doesn't feel so much like a community project that is actually seeking outside discussion and ideas. (No shame in that, but the pretense is disappointing). Personally I'm waiting for the fuzzing-support to land in 1.18. Fuzz testing is basically magical, and amazing in reporting problems even in code with "high coverage". The generics might be nice, but off-hand I don't see that I'll be needing them in the immediate future in any of my personal projects - but I fuzz-test the hell out of a lot of my projects (which largely revolve around interpreters and compilers).
  - ithkuil 5y ago
    Those community efforts may have not been have adopted, but that doesn't mean their existence hasn't informed the Go team's solution

cube2222 5y ago

Also think this is a good call. Though the second comment has merit too, I think it would be good to have some common abstraction right away, like we had io.Writer, io.Reader, etc. so everybody doesn't define their own, as it'll take time to crawl out of that. Although in practice it did work out well with error wrapping which was first in libraries and then the stdlib defined an interface for them, which resulted in all libraries adopting that. > Similarly, if constraints isn’t part of 1.18, there will be a lot of independent redefinitions of orderable types. I don’t think we’re going to learn from experience much that could change that package now.

qaq 5y ago

Yes let's fracture the ecosystem with a bunch of libs doing generic map, slice etc. Cause there is no way to figure out how to do it right as this is a very novel feature that no other lang has

Strom 5y ago
Go is not in the business of copy-pasting other language designs. That much should be obvious by now. The questions aren't around the algorithms. They're about Go specific things like how to deal with legacy std library parts that are made obsolete by generics.
- qaq 5y ago
  Yes NIH at Google is on the level of it's own. Look at any ecosystem that used this logic to push something off and you will see a badly fractured community that never fully reconsolidates. I'd rather depend on std lib with warts than have my deps depend on 3 incompatible versions of generic map from 3 dif. libs.
  - marcus_holmes 5y ago
    Simple solution: don't use a dep that uses generics until the fracturing is gone. Take the same approach as the Go team and let the use of generics mature and a consensus build on where/how they should be used. There's no need for generics in the short term. We've survived for 11 years without them, we can manage another couple while we work out how to best use them.
    - qaq 5y ago
      So you will drop any existing dep your project has that adopts generics ?
      - yalue 5y ago
        Fortunately, they fixed dependency management first, so you can simply stop updating any dependency that adopts generics!

The_rationalist 5y ago

How can people still use this toy language..

dathinab 5y ago

Hm, shouldn't they first update the (most important/interesting) libraries in a fork before stabilizing generics? I mean designing a feature in a clean room is one think, but using it a the standard library would be a good way to know if they messed up the design in some way.

spockz 5y ago
Yes that would be a good idea. However, they could already have a generic collection lib in the same place (branch/repo) where the generics feature is created.
- lbhdc 5y ago
  This is what Rob proposes in this issue. > I propose we still design, build, test, and use new libraries for slices, maps, channels, and so on, but start by putting them in the golang/x/exp repository.

kubb 5y ago

What will likely happen is that the users will design generic libraries themselves. There will likely be a couple, and eventually they will converge on the most useful features. Then the Go team can just get inspiration from that I guess. I'm excited about the prospect of having iterators. It will enable a different, more consistent programming style. I'm also hoping for immutable collections, even though the lack of specialization will make it more difficult to implement them efficiently. They would enable a more robust way to build concurrent systems.

cy_hauser 5y ago
Or, if history is a guide, there will be a few really nice generic libraries written and a sizable minority of developers will adopt them as pseudo standard to fill the void. Then the Go team will do what they want, fracture the community, and alienate those who expected your described path to be the one taken.
- chrsig 5y ago
  I think they've been worse about this w.r.t. tooling (dep comes to mind. The closest thing I can think of along this path for the standard library would be how they've handled errors, and deciding to go their own way instead of adopting dave cheney's pkg/errors[0] they do definitely seem to have some NIH syndrome at times, but I can't say that as time has progressed that I haven't come to appreciate the decisions they've made that seemed controversial at the time. [0] https://github.com/pkg/errors https://github.com/pkg/errors
  - SPascareli13 5y ago
    Wait, isn't Wrap and other pkg/errors proposals used in the current stdlib? I thought they officially accepted that package as the default errors package.
    - chrsig 5y ago
      No, they didn't adopt pkg/errors into the stdlib. pkg/errors did get updated to work nicely with the changes that they did incorporate https://pkg.go.dev/errors https://pkg.go.dev/errors

olingern 5y ago

JavaScript/TypeScript changes so much that a codebase will look very different from one year to the next. JS/TS has come a long way and needed to make substantial change, but I appreciate the slow moving, methodical nature in which the Go team moves the language and environment forward.

shp0ngle 5y ago
The negative is that some issues are really hard to fix, because you don’t want to break the backwards compatibility guarantee. For example, there is a bug in go’s built-in HTML templating, that it misrepresent javascript backticks. If you do <script> var string = `http://google.com http://google.com` </script> in HTML template, it will interpret // as a comment and return <script>var string = `http:</script> This is now really hard to fix; it means either rewriting the JS parser from scratch, but that is a giant change (currently the JS parser is really simple, backticks are hard to do properly without reimplementing all from scratch); the more reasonable choice would be to just ban backticks in HTML templates, but that would break backward compat. So there is basically an unfixable bug sitting in go html templates. https://github.com/golang/go/issues/9200 https://github.com/golang/go/issues/9200
- rytill 5y ago
  If it’s bad enough, why not release a v2 of the library?
  - jen20 5y ago
    The standard library seems to only be versioned with the language. An external v2 could work, but I’m not sure there’s any precedent for a v2 of a standard library package.
    - theli0nheart 5y ago
      > I’m not sure there’s any precedent for a v2 of a standard library package. urllib/urllib2 in Python is one example. There are others; it's not really unprecedented.

crnkofe 5y ago

I was really looking forward to getting some basic generic standard library funcs. Guess what I'm getting now is a a ton of std libraries each with a slightly different approach, slightly different bugs and update cycles which will nicely inflate the amount of tech debt in existing codebases. I guess from the standpoint of a language designer it makes life a bit easier not to do anything and just cherry pick the winners of the various generic attempts that the community will create but as an app. developer I find this disturbing. Also I question the rush to a release all of a sudden. Generics took years to come to fruition. Another year for a decent stdlib won't really hurt anyone and for those that really really want it they can enable it through build constraints.

nyanpasu64 5y ago

C++17 introduced std::optional and std::variant, but they're not used by the standard library in 2021, as far as I've seen (unlike Rust which is better off for using them). It feels quite like a missed opportunity to produce more ergonomic APIs (though the inability to produce an optional<T&> is limiting, and std::variant is inefficient at compile and possibly runtime and apparently can't be fixed because ABI). I'm not a Go user, but I dislike multiple competing approaches to problems without clear guidance or fully embracing newer approaches.