12 ms·

Upcoming Features in Go 1.18

152 points by dcu 5y ago

qaq 5y ago
1.18 shaping up to be a great release! My only remaining desired features: * sum types (would be really nice) * some equivalent of ? in Rust (can live without but would be nice) After playing with a ton of languages have settled on Go for most projects.
- masklinn 5y ago
  > * sum types (would be really nice) That seems really difficult to retrofit, and to not really fit the language either. I've been thinking something like sealed interfaces would fit better: Go already has fallible downcasts (and RTTI which takes the role of discriminant), and type switches can play the role of your `case` statement: func do[T any](i option[T]) { switch v := i.(type) { case T: fmt.Printf("Got a %v", v) case nothing: // or `nil` could be a (pseudo)-type fmt.Printf("was empty!") // no default necessary because the check is complete } } The only pieces missing are a way to "seal in" a set of types, and add completeness check to type switches for those.
  - Zababa 5y ago
    This with exhaustiveness checking and a way to apply that to errors would be great.
  - nicoburns 5y ago
    Why would it be difficult to retrofit? It’s just a new set of types. Is it that existing APIs wouldn’t be using them?
    - masklinn 5y ago
      > Why would it be difficult to retrofit? It’s just a new set of types. Is it that existing APIs wouldn’t be using them? It's a brand new kind which wouldn't necessarily work the way existing types do, and it's a whole lot of extra syntax. Plus previous retrofits have not exactly panned out great, C++ and Java's native "type safe enumerations" are pretty crummy as they're closer to enumerated sets of constants than sum types. Sealed classes/interfaces/traits/… fit well in the machinery and aesthetics of RTTI-heavy products-types-based languages and slot nicely into the "niche" of sum types.
    - tialaramex 5y ago
      One problem beyond the technical "How" is that culturally Go didn't have Sum types, so there are existing APIs where, if a Sum type was possible that's what you'd do, but it wasn't, so they didn't. This isn't so different from the problem Generics introduce (why isn't this API generic, oh, it pre-dates that feature). And it might similarly be worth it for Sum types, but it's certainly an extra consideration. On the technical side, Sum types kinda suck unless you have niches. If your Optional sum type is always actually bigger than the Some type it is wrapping then why even bother? So then you're also adding promises about niches in your implementation.
  - jerf 5y ago
    "I've been thinking something like sealed interfaces would fit better:" You can have "sealed interfaces" today; you put an unexportable method name in the interface. Then no legal external implementation can exist. (Not even if someone "guesses" the method name; the compiler will not consider them to have the same name.) What you still don't get is completeness checking even so. In theory a linter could do it even without compiler support, I don't know if one exists. You can use this in Go today to get, oh, say, 1/3rd of the feature of 'sum types' today. But you don't get much of the "sum types" bang for that 1/3rd of the buck. Basically, you can use them, and you don't need to do the fully manual type of thing you need to do in C with unions and tags, you can lean on the interfaces carrying type information around to handle that, but you get no additional compiler or syntax support, nor any sort of pattern matching on them.
    - tjalfi 5y ago
      go-sumtype[0] has completeness checking for sealed interfaces. [0] https://github.com/BurntSushi/go-sumtype https://github.com/BurntSushi/go-sumtype
    - masklinn 5y ago
      I'm not quite sure what you're trying to express, because all I'm reading in your comment is "you can get none of the benefits today with no changes", which doesn't seem like a very interesting statement? I don't understand why you insist on quoting "sum types" when literally just mentioning them.
      - jerf 5y ago
        "I'm not quite sure what you're trying to express, because all I'm reading in your comment is "you can get none of the benefits today with no changes", which doesn't seem like a very interesting statement?" You can get some of the benefits today with no changes to Go. You can create a package-level sealed interface: http://www.jerf.org/iri/post/2917 http://www.jerf.org/iri/post/2917 "I don't understand why you insist on quoting "sum types" when literally just mentioning them." Because they aren't literally sum types, in that they have every feature that everyone associates with sum types, and people are very sensitive about that. So I don't need anyone replying with "but those aren't really sum types", either for my previous HN post or the blog post I just linked. Yes, I know they don't check every check box. But they do check a few of them, and, arguably the most essential one which is that you can indeed implement type ASumType interface { unexportedMethod() } func SomeFunction(thing ASumType) { ... } and ASumType can be any of several types, closed and limited at compile time to only be things defined in this particular package in a way that can not be extended by any other external package.
rmanolis 5y ago
Now with generics, it will eat the pie from Java market.
- politician 5y ago
  I'm a fan of Go, but, let's be real, Java's not going anywhere.
  - mekster 5y ago
    I like many daemons are written in go instead of java these days and they start up instantly and take fer less resource. Java will fade out as old systems fade out in a few decades as ecosystems catch up in other languages.
  - yjftsjthsd-h 5y ago
    In all fairness, I expect that Go did eat some of Java's market share (since Go is popular and targets a similar part of the market), but yeah I doubt that generics are going to make a real difference in that direction; I expect that (mostly) anyone who was going to switch has done.
    - geodel 5y ago
      Besides more than switch, it is new or new kind software that getting written often in newer languages which may eventually replace old stacks.
- eweise 5y ago
  With loom, Java will eat the pie from the Go market.
- cute_boi 5y ago
  well cobol hasn't gone anywhere so I don't expect Java to go anywhere. Although I dislike Java I think lots and lots of legacy apps are made in Java and isn't going anywhere. And many university still teaches Java which mean it is just as strong. And andriod etc relies on Java which means it will last for centuries.
Zababa 5y ago
Generics will be nice, and fuzzing is great too. I'm not a huge fan of Go itself, but it works well for my use case, websites and CLI tools. The integrated tooling (test, fuzz, race detector, benchmark, format, vet, package management, building) is very nice.
shakezula 5y ago
Something I don’t see the Go team get enough praise for is their ability to bring major language changes like generics into the language in an actually backwards compatible minor version update. If nothing else, I find myself choosing Go frequently because it’s not going anywhere and it’s not changing.
- Zababa 5y ago
  Many people seem to think that the language could and should have included them from the beginning. Java followed the same exact history 15 years before Go, C# too. Many of the people that didn't think that Go should have generics may not really care or be happy that they are now in the language. That may explain the reaction.
- handrous 5y ago
  I wish vendoring in deps and/or monorepos were better-supported. That's the only thing that gives me pause with Go. Everything else about it is great from a "can this easily be built a couple years from now, if it's not been touched in the meantime?" perspective, but the defaults there strongly favor future breakage and last I checked make it a huge pain to take measures to avoid that problem, which is weird. [EDIT] oh, they added a command for that, "go mod vendor", I guess, and I just missed it somehow. Nice. [EDIT EDIT] On further reading the feature's practically built of rough edges and you're probably gonna want 3rd party tools to manage it if you value your sanity. Hmph. Well, that sucks.
  - jatone 5y ago
    ive been trying to get them to fix vendoring and modules. they've been incredibly obtuse about the whole situation. =/
  - shakezula 5y ago
    They do appear to be addressing some of those rough edges in 1.18 with the ability to specify a working mod file separate from the normal go.mod file, but you're not wrong, vendoring has some rough edges for sure.
- 5y ago
bithavoc 5y ago
wow I didn't know about the workspace file, replace directives are messy. It seems like I'm going to remove 149 replace directives of my own, what a nightmare. grep -rnw '.' --include=\*.mod -e 'replace' | grep "" -c 149
- deleted 5y ago
  [deleted]
- akavel 5y ago
  Not 100% tested, but should hopefully work: find . -name go.mod | xargs gawk -i inplace '/^replace \(/{d=1}; (!d && !/^replace/); /^\)/{d=0}' Explanation of gawk arguments: — -i inplace — https://stackoverflow.com/a/16531920 https://stackoverflow.com/a/16531920 — /^replace \(/{d=1} — on lines starting with `replace (`, set a variable named `d` (any var name would work, 'd' is my mental shortcut for 'delete' here) to value `1` (i.e. "true"); Note: in awk, unset variables default to 0 ("false") value — (!d && !/^replace/) — on lines where `d` is 0 (which is default value of unset variables in awk), and which don't start with `replace` pattern, print the line. Default action when unspecified in awk is `{print}`, this entry is a shortcut of: (!d && !/^replace/) {print} — /^\)/{d=0} — on lines starting with `)`, reset `d` variable back to 0 ("false") In other words, this encodes: "delete any lines between `replace (` and nearest `)`, and also delete any other lines starting with `replace`"
  - bithavoc 5y ago
    Nice, learned a few things about awk here.
woah 5y ago
Generics will be insanely useful for me. I work in an environment that uses a huge Golang KV store for all persistence. This means we write all of our own indexing code etc. None of it is reusable because of the lack of generics, so each module has much of the same boilerplate for building second indexes, etc, often written in slightly different styles because it was written by different people. Generics will let us build a set of tools for DB access and indexing tools which can be reused across all types.
- maccard 5y ago
  Why are generics more usable than codegen in that use case?
  - vlowther 5y ago
    ... writing the code required to write the code needed to implement indexes is more fragile than letting the compiler do it for you, most likely. I maintain a reflect-based indexing implementation for in-memory data, and look forward to seeing what I can do with generics to get rid of reflect based overhead.
    - janderland 5y ago
      :shrug: I’ve tried doing it both ways in other languages and found that code gen is less fragile than I expected, though I needed to carefully consider the interface between generated & manually written code.
  - woah 5y ago
    Someone is working on an "ORM" that uses codegen from proto files, which we are already using for serialization. Not sure when it will be done. Compiler level generics are just a lot quicker and easier for anyone to use without requiring a whole code generation framework
PaulKeeble 5y ago
We need a shortcut for the if x,err = f(); err!=nil { return _,err } pattern that is so common in go code. This is my biggest daily gripe and I work around it with a snippet but so much of integration code is this or a variant of it which captures the stack trace and it constantly distracts from the main flow of algorithm.
- dullgiulio 5y ago
  Please no. I am still fighting the battle of adding contextual information to the error using fmt.Errorf. I am tired of seeing SocketException: hostname.com as full error message.
  - AYBABTME 5y ago
    This, errors that are bubbled up should have some context added to them. Otherwise every error ends up being totally meaningless.
    - stouset 5y ago
      I repeatedly fail to understand why golang proponents insist on flogging themselves into becoming human stacktrace authors. This is a solved problem the computer can do better than you, automatically, on your behalf. Certainly any shortcut syntax should not prevent you from adding human-curated context to your errors. But the current situation comes at an enormous cost, and I truly think there's a bit of Stockholm Syndrome going on here.
      - kevinmgranger 5y ago
        Not that I agree with how Go handles it, but the computer is not always better at it. It's a tradeoff, a compromise, or a catch-22. If you use the full stacktrace, you could get 50 frames of irrelevant library code worsening the signal:noise ratio, hiding what the real issue is. If you write your own context, then when it _is_ a problem with library code, you're hopelessly lost. I think we need better tooling: the ability to add your own contextual information, to propagate errors explicitly but without boilerplate, and the ability to _choose_ the level of information you see afterward. We have log viewers that can filter out by severity level, why don't we have a standardization for stack traces to let you filter to what you want?
superbaconman 5y ago
Wow the IP stuff looks awesome! Generating ranges of IP addresses should have been in the stdlib for a long time.
marcus_holmes 5y ago
Dreading the wave of shitty badly-thought-out library "updates" to include generics (and the wave of shitty new libraries from people who never learned how to use interfaces and now think they know how to use generics). It's going to be a year or so before the community settles down again after this.
- narraturgy 5y ago
  As someone who has recently decided to learn Go, this is a rather intimidating change. What is a good way to know that I am learning from sources who are using these new tools responsibly, rather than applying them in the messy fashion which you seem concerned about?
  - jerf 5y ago
    Stick close to the standard library and the extended libraries (https://pkg.go.dev/golang.org/x https://pkg.go.dev/golang.org/x ), track a community list where a lot of discussion will be occurring very quickly after release. I don't want to recommend "don't use generics", but generally think about whether or not you can solve the problem without them without immediately reaching for them. There are patterns in Go that work just fine today, which is why despite the fact that clearly some people are just flabberghasted at the idea that Go is useful without generics, it demonstrably is. Interfaces are quite a lot of what you need out of "generics". Don't just give up and copy and paste; it is necessary way less than some people who were trying to write C++ in Go claim it is.
    - marcus_holmes 5y ago
      this. Interfaces do 90% of what generics are used for in other languages. The remaining 10% had been solved by boilerplate/generation. Yes, it will be nice to have a better answer for that 10%. But we'll probably end up with generics being used (badly) for 90% of cases instead. As always in Go, follow the standard library. If they're hesitating to use generics, then that's solid advice.
  - KarlKode 5y ago
2pEXgD0fZ5cF 5y ago
Been a while since I worked with Go but I'm considering it for an upcoming project. Is there any word on a new, updated version of "The Go Programming Language" (Donovan, Kernighan) to cover all the new features since then? I really enjoyed working through that book. If not: Any tips for a good resource to really get up to date with the new additions/changes since ~2015?
- ar_lan 5y ago
  I think there is a need for this. I use it daily and still find myself relegated back to pretty much the features that were available when I first picked it up - would love somewhat of a refresher book that is updated for 2021/2022.
- pageandrew 5y ago
  The Go Programming Language is still pretty much up to date. Most of the recent updates have involved improvements to tooling (Go modules), improvements to the standard library, and internal optimizations. The big changes I'd point out are `context.Context` and `go mod`. I might be forgetting some things, but those are most notable to me.
  - morelisp 5y ago
    Error handling with Is/As/%w I think is the biggest library change other than Context.
Andys 5y ago
> With Go 1.17 it took 56 seconds to format all files This sounded extremely slow to me - go fmt is normally instant. Granted, cockroachdb is a big project But I had to download and try, and on my computer (Ryzen 5950X) it only took ~3.1s on Go 1.17. I didn't bother trying tip.
- ayanamist 5y ago
  In my laptop(ThinkPad P1 Gen3 w/ Intel i7-10750H), i run the same command in WSL2 env after executing `make`: real 0m5.321s user 0m25.747s sys 0m3.276s So i doubt if macOS has some magic for Intel CPU to make it slow?
gauchojs 5y ago
Can generic sorting be implemented now ?

152 points by dcu 5y ago

qaq 5y ago

1.18 shaping up to be a great release! My only remaining desired features: * sum types (would be really nice) * some equivalent of ? in Rust (can live without but would be nice) After playing with a ton of languages have settled on Go for most projects.

masklinn 5y ago
> * sum types (would be really nice) That seems really difficult to retrofit, and to not really fit the language either. I've been thinking something like sealed interfaces would fit better: Go already has fallible downcasts (and RTTI which takes the role of discriminant), and type switches can play the role of your `case` statement: func do[T any](i option[T]) { switch v := i.(type) { case T: fmt.Printf("Got a %v", v) case nothing: // or `nil` could be a (pseudo)-type fmt.Printf("was empty!") // no default necessary because the check is complete } } The only pieces missing are a way to "seal in" a set of types, and add completeness check to type switches for those.
- Zababa 5y ago
  This with exhaustiveness checking and a way to apply that to errors would be great.
- nicoburns 5y ago
  Why would it be difficult to retrofit? It’s just a new set of types. Is it that existing APIs wouldn’t be using them?
  - masklinn 5y ago
    > Why would it be difficult to retrofit? It’s just a new set of types. Is it that existing APIs wouldn’t be using them? It's a brand new kind which wouldn't necessarily work the way existing types do, and it's a whole lot of extra syntax. Plus previous retrofits have not exactly panned out great, C++ and Java's native "type safe enumerations" are pretty crummy as they're closer to enumerated sets of constants than sum types. Sealed classes/interfaces/traits/… fit well in the machinery and aesthetics of RTTI-heavy products-types-based languages and slot nicely into the "niche" of sum types.
  - tialaramex 5y ago
    One problem beyond the technical "How" is that culturally Go didn't have Sum types, so there are existing APIs where, if a Sum type was possible that's what you'd do, but it wasn't, so they didn't. This isn't so different from the problem Generics introduce (why isn't this API generic, oh, it pre-dates that feature). And it might similarly be worth it for Sum types, but it's certainly an extra consideration. On the technical side, Sum types kinda suck unless you have niches. If your Optional sum type is always actually bigger than the Some type it is wrapping then why even bother? So then you're also adding promises about niches in your implementation.
- jerf 5y ago
  "I've been thinking something like sealed interfaces would fit better:" You can have "sealed interfaces" today; you put an unexportable method name in the interface. Then no legal external implementation can exist. (Not even if someone "guesses" the method name; the compiler will not consider them to have the same name.) What you still don't get is completeness checking even so. In theory a linter could do it even without compiler support, I don't know if one exists. You can use this in Go today to get, oh, say, 1/3rd of the feature of 'sum types' today. But you don't get much of the "sum types" bang for that 1/3rd of the buck. Basically, you can use them, and you don't need to do the fully manual type of thing you need to do in C with unions and tags, you can lean on the interfaces carrying type information around to handle that, but you get no additional compiler or syntax support, nor any sort of pattern matching on them.
  - tjalfi 5y ago
    go-sumtype[0] has completeness checking for sealed interfaces. [0] https://github.com/BurntSushi/go-sumtype https://github.com/BurntSushi/go-sumtype
  - masklinn 5y ago
    I'm not quite sure what you're trying to express, because all I'm reading in your comment is "you can get none of the benefits today with no changes", which doesn't seem like a very interesting statement? I don't understand why you insist on quoting "sum types" when literally just mentioning them.
    - jerf 5y ago
      "I'm not quite sure what you're trying to express, because all I'm reading in your comment is "you can get none of the benefits today with no changes", which doesn't seem like a very interesting statement?" You can get some of the benefits today with no changes to Go. You can create a package-level sealed interface: http://www.jerf.org/iri/post/2917 http://www.jerf.org/iri/post/2917 "I don't understand why you insist on quoting "sum types" when literally just mentioning them." Because they aren't literally sum types, in that they have every feature that everyone associates with sum types, and people are very sensitive about that. So I don't need anyone replying with "but those aren't really sum types", either for my previous HN post or the blog post I just linked. Yes, I know they don't check every check box. But they do check a few of them, and, arguably the most essential one which is that you can indeed implement type ASumType interface { unexportedMethod() } func SomeFunction(thing ASumType) { ... } and ASumType can be any of several types, closed and limited at compile time to only be things defined in this particular package in a way that can not be extended by any other external package.

rmanolis 5y ago

Now with generics, it will eat the pie from Java market.

politician 5y ago
I'm a fan of Go, but, let's be real, Java's not going anywhere.
- mekster 5y ago
  I like many daemons are written in go instead of java these days and they start up instantly and take fer less resource. Java will fade out as old systems fade out in a few decades as ecosystems catch up in other languages.
- yjftsjthsd-h 5y ago
  In all fairness, I expect that Go did eat some of Java's market share (since Go is popular and targets a similar part of the market), but yeah I doubt that generics are going to make a real difference in that direction; I expect that (mostly) anyone who was going to switch has done.
  - geodel 5y ago
    Besides more than switch, it is new or new kind software that getting written often in newer languages which may eventually replace old stacks.
eweise 5y ago
With loom, Java will eat the pie from the Go market.
cute_boi 5y ago
well cobol hasn't gone anywhere so I don't expect Java to go anywhere. Although I dislike Java I think lots and lots of legacy apps are made in Java and isn't going anywhere. And many university still teaches Java which mean it is just as strong. And andriod etc relies on Java which means it will last for centuries.

Zababa 5y ago

Generics will be nice, and fuzzing is great too. I'm not a huge fan of Go itself, but it works well for my use case, websites and CLI tools. The integrated tooling (test, fuzz, race detector, benchmark, format, vet, package management, building) is very nice.

shakezula 5y ago

Something I don’t see the Go team get enough praise for is their ability to bring major language changes like generics into the language in an actually backwards compatible minor version update. If nothing else, I find myself choosing Go frequently because it’s not going anywhere and it’s not changing.

Zababa 5y ago
Many people seem to think that the language could and should have included them from the beginning. Java followed the same exact history 15 years before Go, C# too. Many of the people that didn't think that Go should have generics may not really care or be happy that they are now in the language. That may explain the reaction.
handrous 5y ago
I wish vendoring in deps and/or monorepos were better-supported. That's the only thing that gives me pause with Go. Everything else about it is great from a "can this easily be built a couple years from now, if it's not been touched in the meantime?" perspective, but the defaults there strongly favor future breakage and last I checked make it a huge pain to take measures to avoid that problem, which is weird. [EDIT] oh, they added a command for that, "go mod vendor", I guess, and I just missed it somehow. Nice. [EDIT EDIT] On further reading the feature's practically built of rough edges and you're probably gonna want 3rd party tools to manage it if you value your sanity. Hmph. Well, that sucks.
- jatone 5y ago
  ive been trying to get them to fix vendoring and modules. they've been incredibly obtuse about the whole situation. =/
- shakezula 5y ago
  They do appear to be addressing some of those rough edges in 1.18 with the ability to specify a working mod file separate from the normal go.mod file, but you're not wrong, vendoring has some rough edges for sure.
5y ago

bithavoc 5y ago

wow I didn't know about the workspace file, replace directives are messy. It seems like I'm going to remove 149 replace directives of my own, what a nightmare. grep -rnw '.' --include=\*.mod -e 'replace' | grep "" -c 149

deleted 5y ago
[deleted]
akavel 5y ago
Not 100% tested, but should hopefully work: find . -name go.mod | xargs gawk -i inplace '/^replace \(/{d=1}; (!d && !/^replace/); /^\)/{d=0}' Explanation of gawk arguments: — -i inplace — https://stackoverflow.com/a/16531920 https://stackoverflow.com/a/16531920 — /^replace \(/{d=1} — on lines starting with `replace (`, set a variable named `d` (any var name would work, 'd' is my mental shortcut for 'delete' here) to value `1` (i.e. "true"); Note: in awk, unset variables default to 0 ("false") value — (!d && !/^replace/) — on lines where `d` is 0 (which is default value of unset variables in awk), and which don't start with `replace` pattern, print the line. Default action when unspecified in awk is `{print}`, this entry is a shortcut of: (!d && !/^replace/) {print} — /^\)/{d=0} — on lines starting with `)`, reset `d` variable back to 0 ("false") In other words, this encodes: "delete any lines between `replace (` and nearest `)`, and also delete any other lines starting with `replace`"
- bithavoc 5y ago
  Nice, learned a few things about awk here.

woah 5y ago

Generics will be insanely useful for me. I work in an environment that uses a huge Golang KV store for all persistence. This means we write all of our own indexing code etc. None of it is reusable because of the lack of generics, so each module has much of the same boilerplate for building second indexes, etc, often written in slightly different styles because it was written by different people. Generics will let us build a set of tools for DB access and indexing tools which can be reused across all types.

maccard 5y ago
Why are generics more usable than codegen in that use case?
- vlowther 5y ago
  ... writing the code required to write the code needed to implement indexes is more fragile than letting the compiler do it for you, most likely. I maintain a reflect-based indexing implementation for in-memory data, and look forward to seeing what I can do with generics to get rid of reflect based overhead.
  - janderland 5y ago
    :shrug: I’ve tried doing it both ways in other languages and found that code gen is less fragile than I expected, though I needed to carefully consider the interface between generated & manually written code.
- woah 5y ago
  Someone is working on an "ORM" that uses codegen from proto files, which we are already using for serialization. Not sure when it will be done. Compiler level generics are just a lot quicker and easier for anyone to use without requiring a whole code generation framework

PaulKeeble 5y ago

We need a shortcut for the if x,err = f(); err!=nil { return _,err } pattern that is so common in go code. This is my biggest daily gripe and I work around it with a snippet but so much of integration code is this or a variant of it which captures the stack trace and it constantly distracts from the main flow of algorithm.

dullgiulio 5y ago
Please no. I am still fighting the battle of adding contextual information to the error using fmt.Errorf. I am tired of seeing SocketException: hostname.com as full error message.
- AYBABTME 5y ago
  This, errors that are bubbled up should have some context added to them. Otherwise every error ends up being totally meaningless.
  - stouset 5y ago
    I repeatedly fail to understand why golang proponents insist on flogging themselves into becoming human stacktrace authors. This is a solved problem the computer can do better than you, automatically, on your behalf. Certainly any shortcut syntax should not prevent you from adding human-curated context to your errors. But the current situation comes at an enormous cost, and I truly think there's a bit of Stockholm Syndrome going on here.
    - kevinmgranger 5y ago
      Not that I agree with how Go handles it, but the computer is not always better at it. It's a tradeoff, a compromise, or a catch-22. If you use the full stacktrace, you could get 50 frames of irrelevant library code worsening the signal:noise ratio, hiding what the real issue is. If you write your own context, then when it _is_ a problem with library code, you're hopelessly lost. I think we need better tooling: the ability to add your own contextual information, to propagate errors explicitly but without boilerplate, and the ability to _choose_ the level of information you see afterward. We have log viewers that can filter out by severity level, why don't we have a standardization for stack traces to let you filter to what you want?

superbaconman 5y ago

Wow the IP stuff looks awesome! Generating ranges of IP addresses should have been in the stdlib for a long time.

marcus_holmes 5y ago

Dreading the wave of shitty badly-thought-out library "updates" to include generics (and the wave of shitty new libraries from people who never learned how to use interfaces and now think they know how to use generics). It's going to be a year or so before the community settles down again after this.

narraturgy 5y ago
As someone who has recently decided to learn Go, this is a rather intimidating change. What is a good way to know that I am learning from sources who are using these new tools responsibly, rather than applying them in the messy fashion which you seem concerned about?
- jerf 5y ago
  Stick close to the standard library and the extended libraries (https://pkg.go.dev/golang.org/x https://pkg.go.dev/golang.org/x ), track a community list where a lot of discussion will be occurring very quickly after release. I don't want to recommend "don't use generics", but generally think about whether or not you can solve the problem without them without immediately reaching for them. There are patterns in Go that work just fine today, which is why despite the fact that clearly some people are just flabberghasted at the idea that Go is useful without generics, it demonstrably is. Interfaces are quite a lot of what you need out of "generics". Don't just give up and copy and paste; it is necessary way less than some people who were trying to write C++ in Go claim it is.
  - marcus_holmes 5y ago
    this. Interfaces do 90% of what generics are used for in other languages. The remaining 10% had been solved by boilerplate/generation. Yes, it will be nice to have a better answer for that 10%. But we'll probably end up with generics being used (badly) for 90% of cases instead. As always in Go, follow the standard library. If they're hesitating to use generics, then that's solid advice.
- KarlKode 5y ago

2pEXgD0fZ5cF 5y ago

Been a while since I worked with Go but I'm considering it for an upcoming project. Is there any word on a new, updated version of "The Go Programming Language" (Donovan, Kernighan) to cover all the new features since then? I really enjoyed working through that book. If not: Any tips for a good resource to really get up to date with the new additions/changes since ~2015?

ar_lan 5y ago
I think there is a need for this. I use it daily and still find myself relegated back to pretty much the features that were available when I first picked it up - would love somewhat of a refresher book that is updated for 2021/2022.
pageandrew 5y ago
The Go Programming Language is still pretty much up to date. Most of the recent updates have involved improvements to tooling (Go modules), improvements to the standard library, and internal optimizations. The big changes I'd point out are `context.Context` and `go mod`. I might be forgetting some things, but those are most notable to me.
- morelisp 5y ago
  Error handling with Is/As/%w I think is the biggest library change other than Context.

Andys 5y ago

> With Go 1.17 it took 56 seconds to format all files This sounded extremely slow to me - go fmt is normally instant. Granted, cockroachdb is a big project But I had to download and try, and on my computer (Ryzen 5950X) it only took ~3.1s on Go 1.17. I didn't bother trying tip.

ayanamist 5y ago
In my laptop(ThinkPad P1 Gen3 w/ Intel i7-10750H), i run the same command in WSL2 env after executing `make`: real 0m5.321s user 0m25.747s sys 0m3.276s So i doubt if macOS has some magic for Intel CPU to make it slow?

gauchojs 5y ago

Can generic sorting be implemented now ?