9 ms·

What else is in Go 1.11?

141 points by ngaut 8y ago

wawhal 8y ago
Finally, I can keep my Go projects wherever I want.
- stplsd 8y ago
  Ech, I like to submit to GOPATH. One less thing to think about.
- geezerjay 8y ago
  I missed any reference to GOPATH. Does this release fixes Go's problem of forcing developers to specify source code directories through GOPATH?
  - stplsd 8y ago
    It is not covered here: - WebAssembly and Modules have already been covered. https://github.com/golang/go/wiki/Modules https://github.com/golang/go/wiki/Modules
  - agnivade 8y ago
    That is correct. Now you can clone and build Go repos anywhere. Note that support is still experimental, so if you want stability, it is advised to remain inside GOPATH for another release. This is a good post - https://systemdump.io/posts/2018-07-22-go-modules https://systemdump.io/posts/2018-07-22-go-modules However, do please feel free to try it out and file bugs.
    - geezerjay 8y ago
      The GOPATH nonsense was the reason why I've decided to take a hard pass on Golang, and instead pick up Rust. I'll stay away fron Golang until that braindead idea is officially dead and a thing of the past.
mappu 8y ago
Plaintext at https://github.com/mvdan/talks/blob/master/2018/go1.11.slide https://github.com/mvdan/talks/blob/master/2018/go1.11.slide if anyone else gets Chrome freezing for a few seconds navigating left/right.
- Insanity 8y ago
  Thanks! I am on my phone and it is impossible to read it.
- mchahn 8y ago
  It is sad when a website design is so bad it requires usage instructions on the home page.
kodablah 8y ago
A change to gofmt like that is going to require a large formatting commit to conform. Presumably/ideally there are CIs that fail on invalid format, so it's not like you can wait until you touch the file again. Not a big deal, but still worth noting.
- mappu 8y ago
  There was a change to gofmt in 1.10, too: https://golang.org/doc/go1.10#gofmt https://golang.org/doc/go1.10#gofmt """Note that these kinds of minor updates to gofmt are expected from time to time. In general, we recommend against building systems that check that source code matches the output of a specific version of gofmt. For example, a continuous integration test that fails if any code already checked into a repository is not “properly formatted” is inherently fragile and not recommended."""
  - kodablah 8y ago
    > For example, a continuous integration test that fails if any code already checked into a repository is not “properly formatted” is inherently fragile and not recommended. As a frequent repo/commit spelunker, I'm gonna have to disagree here. It is better to have this changed all in one commit instead of tacking on that formatting change along with an unrelated change elsewhere in the file and doing that all over the place at separate times. What's inherently fragile (formatting wise) is making a change to a file that does not meet the current formatting requirements and then having it format on save/commit, messing up blames, code review diffs, etc.
    - iainmerrick 8y ago
      Yep -- formatting for style is great iff it’s done rigorously and consistently on every commit (which is what a presubmit check is good for). Ad-hoc reformatting mingled in with real changes plays havoc with change tracking. Ideally the format would never change at all. An occasional change-the-world update is a reasonable compromise, but it should be done as a single commit with no logic changes.
- 8y ago
vesak 8y ago
Go is missing 2 things that I care about: 1) proper dependencies management system (the new module system might address this) and 2) gener... nah, just kidding -- actually null protection. I don't want to see another segfault or null pointer failure ever again. If it had these two features, I'd probably stop toying around with Rust and Crystal and just use Go. Unfortunately, 2) is probably impossible without seriously breaking old code, and they're not gonna break old code.
- invest_gc11 8y ago
  Why not try Kotlin. I don't understand why people use Rust for non System programming
- regecks 8y ago
  When have you seen segfaults in Go? I think 100% of the time, it is either a bug in the Go runtime, or you're using cgo (which is not really Go anymore). A language as simple as Go without nilable types would be great, though.
  - pknopf 8y ago
    nil pointers exist in Go. It is common to run into them, especially when using "&".
  - jdoliner 8y ago
    C programs tend to call nil-pointer panics "segfaults" even though go runtime doesn't print the word "segfault" anywhere. I'm guilty of the same thing.
    - regecks 8y ago
      Well, I think they're worth separating. I've seen a raw SIGSEGV in Go due to a runtime bug years ago, and the only safe outcome is process termination. On the other hand, dereferencing a nil value in Go in relatively safe (as in Java), all it does is crash the goroutine. For common cases like HTTP and RPC handlers, no big deal, safely recoverable. Edit: on second thought, forget that. I agree that it's not a good thing (not safe) for recovery from goroutine crash to be possible.
ancarda 8y ago
>Last release where godoc has a command-line interface What? Are they removing “godoc <pkg>”? I used that a lot as a man page. It’s especially useful when you don’t have internet access Edit: it’ll still be available in `go doc`, just that `godoc` will only be a web server. https://tip.golang.org/doc/go1.11#godoc https://tip.golang.org/doc/go1.11#godoc
fenollp 8y ago
> Some crypto funcs now randomly read an extra byte Can someone explain how this is a feature?
- mirekrusin 8y ago
  Timing attack prevention?
- ancarda 8y ago
  It’s so tests don’t rely on behavior that may change. See this commit message for a full explanation: https://github.com/golang/go/commit/6269dcdc24d74379d8a609ce886149811020b2cc https://github.com/golang/go/commit/6269dcdc24d74379d8a609ce...
- kibibu 8y ago
  It's to stop people misusing the crypto APIs, or making assumptions about them that the Go maintainers don't want to be stuck supporting. https://go-review.googlesource.com/c/go/+/64451 https://go-review.googlesource.com/c/go/+/64451 > Code has ended up depending on things like RSA's key generation being deterministic given a fixed random Reader. This was never guaranteed and would prevent us from ever changing anything about it.
  - rauhl 8y ago
    I respect agl a lot, but this really doesn’t make sense to me. Should I be able to rely on the RSA keygen being deterministic between versions, given a fixed random Reader? No. But should I be able to rely on it being deterministic between runs with the same version? IMHO, yes. This changes the signature of key generation from (Reader) to (Reader, internal random).
iainmerrick 8y ago
Huh, a change to spacing in gofmt? Won’t that cause extra source control churn in a lot of projects?
- Cthulhu_ 8y ago
  I like to think it's OK because gofmt reduces formatting churn overall.
  - masklinn 8y ago
    In this specific case it doesn't do that: any time you add or remove a field from a structure, if it's one of the "extremes" gofmt might re-pad the entire thing, churning the entire structure.
    - eyko 8y ago
      I actually dislike the new heuristic as it becomes difficult to read `key: value` pair when value is, say, 20 white-spaces padded to the right. I remember having to turn on the "highlight current line" setting in my editor just to do that on some codebases.
      - iainmerrick 8y ago
        Whether you like or dislike it, I don’t understand why it’s changing at all. I thought the main point of gofmt (which I applaud) was to avoid wasting any time whatsoever over formatting issues. It seems counterproductive for the golden formatting spec to be a moving target.
- cyphar 8y ago
  It actually could cause bigger problems than that. Most Go projects I've seen have CI runs that check whether 'gofmt' complains -- and fail builds if they do. Ultimately though I don't really care all that much. Everyone will fix it in a few commands, and everything will be green again.
Animats 8y ago
The "prove pass" is a nice step forward. As that is improved, more subscript checks will be optimized out.
gok 8y ago
> Kernel calls on macOS and iOS now go through libSystem.so Well it’s called libSystem.dylib :) but, still, good. It looks like this was only done in “runtime” but hopefully the rest can come in 1.12. [1] [1] https://github.com/golang/go/issues/17490 https://github.com/golang/go/issues/17490
trulyrandom 8y ago
Is there a good way to view these Go presentations on mobile? I find them almost impossible to navigate on my smartphone.
- nostalgeek 8y ago
  Yes it's bad UX on mobile, here you go: https://raw.githubusercontent.com/mvdan/talks/master/2018/go1.11.slide https://raw.githubusercontent.com/mvdan/talks/master/2018/go...
mvdan 8y ago
If anyone wants the recording, this is the timestamp in the meetup recording before an edited version is available: https://youtu.be/RGeHsqj2RWo?t=2h16m11s https://youtu.be/RGeHsqj2RWo?t=2h16m11s I can see that the slides alone aren't self-explanatory in some points, for example with the random byte reading or gofmt. I'll make sure to link to the issues/CLs in the slides next time :)
eadmund 8y ago
> Last release to support GOCACHE=off That's a bit disturbing, since Go's test caching can be a bit of a nuisance. I did some quick Googling, but couldn't find an explanation.
- komuW 8y ago
  If you want to disable test caching, you can still do; go test -count 1 if you want to rebuild without cache; go clean -cache && go build
thoeni 8y ago
Here’s a video of the talk by Daniel where you can see these slides explained: https://youtu.be/mQYjjVCGVJ8 https://youtu.be/mQYjjVCGVJ8

141 points by ngaut 8y ago

wawhal 8y ago

Finally, I can keep my Go projects wherever I want.

stplsd 8y ago
Ech, I like to submit to GOPATH. One less thing to think about.
geezerjay 8y ago
I missed any reference to GOPATH. Does this release fixes Go's problem of forcing developers to specify source code directories through GOPATH?
- stplsd 8y ago
  It is not covered here: - WebAssembly and Modules have already been covered. https://github.com/golang/go/wiki/Modules https://github.com/golang/go/wiki/Modules
- agnivade 8y ago
  That is correct. Now you can clone and build Go repos anywhere. Note that support is still experimental, so if you want stability, it is advised to remain inside GOPATH for another release. This is a good post - https://systemdump.io/posts/2018-07-22-go-modules https://systemdump.io/posts/2018-07-22-go-modules However, do please feel free to try it out and file bugs.
  - geezerjay 8y ago
    The GOPATH nonsense was the reason why I've decided to take a hard pass on Golang, and instead pick up Rust. I'll stay away fron Golang until that braindead idea is officially dead and a thing of the past.

mappu 8y ago

Plaintext at https://github.com/mvdan/talks/blob/master/2018/go1.11.slide https://github.com/mvdan/talks/blob/master/2018/go1.11.slide if anyone else gets Chrome freezing for a few seconds navigating left/right.

Insanity 8y ago
Thanks! I am on my phone and it is impossible to read it.
mchahn 8y ago
It is sad when a website design is so bad it requires usage instructions on the home page.

kodablah 8y ago

A change to gofmt like that is going to require a large formatting commit to conform. Presumably/ideally there are CIs that fail on invalid format, so it's not like you can wait until you touch the file again. Not a big deal, but still worth noting.

mappu 8y ago
There was a change to gofmt in 1.10, too: https://golang.org/doc/go1.10#gofmt https://golang.org/doc/go1.10#gofmt """Note that these kinds of minor updates to gofmt are expected from time to time. In general, we recommend against building systems that check that source code matches the output of a specific version of gofmt. For example, a continuous integration test that fails if any code already checked into a repository is not “properly formatted” is inherently fragile and not recommended."""
- kodablah 8y ago
  > For example, a continuous integration test that fails if any code already checked into a repository is not “properly formatted” is inherently fragile and not recommended. As a frequent repo/commit spelunker, I'm gonna have to disagree here. It is better to have this changed all in one commit instead of tacking on that formatting change along with an unrelated change elsewhere in the file and doing that all over the place at separate times. What's inherently fragile (formatting wise) is making a change to a file that does not meet the current formatting requirements and then having it format on save/commit, messing up blames, code review diffs, etc.
  - iainmerrick 8y ago
    Yep -- formatting for style is great iff it’s done rigorously and consistently on every commit (which is what a presubmit check is good for). Ad-hoc reformatting mingled in with real changes plays havoc with change tracking. Ideally the format would never change at all. An occasional change-the-world update is a reasonable compromise, but it should be done as a single commit with no logic changes.
8y ago

vesak 8y ago

Go is missing 2 things that I care about: 1) proper dependencies management system (the new module system might address this) and 2) gener... nah, just kidding -- actually null protection. I don't want to see another segfault or null pointer failure ever again. If it had these two features, I'd probably stop toying around with Rust and Crystal and just use Go. Unfortunately, 2) is probably impossible without seriously breaking old code, and they're not gonna break old code.

invest_gc11 8y ago
Why not try Kotlin. I don't understand why people use Rust for non System programming
regecks 8y ago
When have you seen segfaults in Go? I think 100% of the time, it is either a bug in the Go runtime, or you're using cgo (which is not really Go anymore). A language as simple as Go without nilable types would be great, though.
- pknopf 8y ago
  nil pointers exist in Go. It is common to run into them, especially when using "&".
- jdoliner 8y ago
  C programs tend to call nil-pointer panics "segfaults" even though go runtime doesn't print the word "segfault" anywhere. I'm guilty of the same thing.
  - regecks 8y ago
    Well, I think they're worth separating. I've seen a raw SIGSEGV in Go due to a runtime bug years ago, and the only safe outcome is process termination. On the other hand, dereferencing a nil value in Go in relatively safe (as in Java), all it does is crash the goroutine. For common cases like HTTP and RPC handlers, no big deal, safely recoverable. Edit: on second thought, forget that. I agree that it's not a good thing (not safe) for recovery from goroutine crash to be possible.

ancarda 8y ago

>Last release where godoc has a command-line interface What? Are they removing “godoc <pkg>”? I used that a lot as a man page. It’s especially useful when you don’t have internet access Edit: it’ll still be available in `go doc`, just that `godoc` will only be a web server. https://tip.golang.org/doc/go1.11#godoc https://tip.golang.org/doc/go1.11#godoc

fenollp 8y ago

> Some crypto funcs now randomly read an extra byte Can someone explain how this is a feature?

mirekrusin 8y ago
Timing attack prevention?
ancarda 8y ago
It’s so tests don’t rely on behavior that may change. See this commit message for a full explanation: https://github.com/golang/go/commit/6269dcdc24d74379d8a609ce886149811020b2cc https://github.com/golang/go/commit/6269dcdc24d74379d8a609ce...
kibibu 8y ago
It's to stop people misusing the crypto APIs, or making assumptions about them that the Go maintainers don't want to be stuck supporting. https://go-review.googlesource.com/c/go/+/64451 https://go-review.googlesource.com/c/go/+/64451 > Code has ended up depending on things like RSA's key generation being deterministic given a fixed random Reader. This was never guaranteed and would prevent us from ever changing anything about it.
- rauhl 8y ago
  I respect agl a lot, but this really doesn’t make sense to me. Should I be able to rely on the RSA keygen being deterministic between versions, given a fixed random Reader? No. But should I be able to rely on it being deterministic between runs with the same version? IMHO, yes. This changes the signature of key generation from (Reader) to (Reader, internal random).

iainmerrick 8y ago

Huh, a change to spacing in gofmt? Won’t that cause extra source control churn in a lot of projects?

Cthulhu_ 8y ago
I like to think it's OK because gofmt reduces formatting churn overall.
- masklinn 8y ago
  In this specific case it doesn't do that: any time you add or remove a field from a structure, if it's one of the "extremes" gofmt might re-pad the entire thing, churning the entire structure.
  - eyko 8y ago
    I actually dislike the new heuristic as it becomes difficult to read `key: value` pair when value is, say, 20 white-spaces padded to the right. I remember having to turn on the "highlight current line" setting in my editor just to do that on some codebases.
    - iainmerrick 8y ago
      Whether you like or dislike it, I don’t understand why it’s changing at all. I thought the main point of gofmt (which I applaud) was to avoid wasting any time whatsoever over formatting issues. It seems counterproductive for the golden formatting spec to be a moving target.
cyphar 8y ago
It actually could cause bigger problems than that. Most Go projects I've seen have CI runs that check whether 'gofmt' complains -- and fail builds if they do. Ultimately though I don't really care all that much. Everyone will fix it in a few commands, and everything will be green again.

Animats 8y ago

The "prove pass" is a nice step forward. As that is improved, more subscript checks will be optimized out.

gok 8y ago

> Kernel calls on macOS and iOS now go through libSystem.so Well it’s called libSystem.dylib :) but, still, good. It looks like this was only done in “runtime” but hopefully the rest can come in 1.12. [1] [1] https://github.com/golang/go/issues/17490 https://github.com/golang/go/issues/17490

trulyrandom 8y ago

Is there a good way to view these Go presentations on mobile? I find them almost impossible to navigate on my smartphone.

nostalgeek 8y ago
Yes it's bad UX on mobile, here you go: https://raw.githubusercontent.com/mvdan/talks/master/2018/go1.11.slide https://raw.githubusercontent.com/mvdan/talks/master/2018/go...

mvdan 8y ago

If anyone wants the recording, this is the timestamp in the meetup recording before an edited version is available: https://youtu.be/RGeHsqj2RWo?t=2h16m11s https://youtu.be/RGeHsqj2RWo?t=2h16m11s I can see that the slides alone aren't self-explanatory in some points, for example with the random byte reading or gofmt. I'll make sure to link to the issues/CLs in the slides next time :)

eadmund 8y ago

> Last release to support GOCACHE=off That's a bit disturbing, since Go's test caching can be a bit of a nuisance. I did some quick Googling, but couldn't find an explanation.

komuW 8y ago
If you want to disable test caching, you can still do; go test -count 1 if you want to rebuild without cache; go clean -cache && go build

thoeni 8y ago

Here’s a video of the talk by Daniel where you can see these slides explained: https://youtu.be/mQYjjVCGVJ8 https://youtu.be/mQYjjVCGVJ8