5 ms·

Go 1.11 Rc1 released

59 points by soroso 8y ago

chx 8y ago
Extremely relevant: We need to talk about Go modules https://www.youtube.com/watch?v=7GGr3S41gjM https://www.youtube.com/watch?v=7GGr3S41gjM
benesch 8y ago
Release notes are available at: https://tip.golang.org/doc/go1.11 https://tip.golang.org/doc/go1.11 Headline features (as judged by me) are: * A new WebAssembly backend, js/wasm, for the gc compiler. * Preliminary support for modules, i.e., the first step towards a package manager built into the Go command. * Improved support for debuggers, especially Delve. * Removal of many direct system calls from the macOS runtime. Unlike on Linux, the macOS system call interface is not considered stable. Go 1.11 binaries are now less likely to break when you upgrade your macOS version because system calls are made through the proper channel (libc).
kjeetgill 8y ago
To get a test of what's actually in the release candidate check out https://github.com/golang/go/milestone/62 https://github.com/golang/go/milestone/62 A lot of new stuff with the new go modules work including vgo and some interesting wasm work.
shawn 8y ago
Go is still one of the most difficult and counter intuitive build systems ever devised. Usually you’d expect a project to build out of the box. Go seems to take a stance of “Haha nope, get ready to figure out which version of the standard library this 4 month old project was written against, then have fun trying to update it to the latest.” I like the language though. Their green threads are still the best.
- Walkman 8y ago
  Can you tell at least one specific example where they broke the standard library?
  - shawn 8y ago
    It figures that my critique would be undermined by the choice of a single word. Look, maybe the stdlib is rock solid. But every time I try to build a Go project, `go build` finds ten ways not to work. Case in point: https://github.com/cretz/tor-dht-poc https://github.com/cretz/tor-dht-poc Try building this. I have no idea what's wrong with it, but it doesn't work. It's cool tech, I want it, but I don't want to immerse myself in the world of hurt^WGo just to get it. I did however at least attempt to fix the problem: https://github.com/cretz/tor-dht-poc/pull/2 https://github.com/cretz/tor-dht-poc/pull/2
    - latchkey 8y ago
      The 'problem' is that the authors did not use dep (soon to be modules) and add the Gopkg.[toml|lock] files.
      - mathw 8y ago
        Or that such tools aren't shipped and part of the standard Go experience. Fortunately that's changing.
        latchkey 8y ago
        ant, maven and gradle are not shipped with the JVM, yet the java community figures out how to do a build system somehow.
        Karunamon 8y ago
        in fairness, Java has an excuse that it’s ancient in language terms and expectations were different then. Go, not so much - it came out in 2012. Pip and CPAN and Gem had been around for years. Go’s lack of a sane packaging solution this far into its lifetime remains a serious weakness of an otherwise solid platform.
        latchkey 8y ago
- alyandon 8y ago
  For what it is worth, I agree 100% and dependency management tools like Glide have been indispensable for me.
- pknopf 8y ago
  > Go is still one of the most difficult and counter intuitive build systems ever devised. I'm currently working on building all the coreclr/corefx repos for .NET Core. Their build system is incredibly convoluted.
- deleted 8y ago
  [deleted]
- irfansharif 8y ago
  From Go's 1.0 compatibility guarantee[0]: > It is intended that programs written to the Go 1 specification will continue to compile and run correctly, unchanged, over the lifetime of that specification. [...] Go programs that work today should continue to work even as future "point" releases of Go 1 arise (Go 1.1, Go 1.2, etc.). I've found this to be upheld in practice, especially so for the standard library. I have yet to come across a case where I was concerned with which "version" of the standard library some project was written against. Are you perhaps talking about non-stdlib packages? [0]: https://golang.org/doc/go1compat https://golang.org/doc/go1compat
  - ovao 8y ago
    My experience has been the same, so it’s hard to understand where shawn is coming from. There have been impressively few breaking changes to the Go standard library since 1.0. Even when bringing in a number of third-party packages, the only trouble I’ve had building Go projects has been in Windows (which is often treated by Gophers as a second-class platform).
mlevental 8y ago
does it have generics yet? yes I'm sure someone will call me a troll.
agnivade 8y ago
There has been some tremendous improvements for ARM architecture. If you run some serious code on raspberry PIs, get ready to be amazed.
- imrehg 8y ago
  I skimmed the release notes, and only a little mention there ARM specific changes, can you elaborate on what tremendous improvements are made? Very curious!
  - agnivade 8y ago
    Yes, the release notes are a bit humble about it. Specifically, optimized assembly instructions are used now in crypto code and also lot of optimizations have gone into the ARM assembler. One example - https://gist.github.com/carlosedp/f85274ef2a9bacc773cf8ddeedaee821 https://gist.github.com/carlosedp/f85274ef2a9bacc773cf8ddeed....
vesak 8y ago
What is the current recommendation for dependency management in Go for a new project?
- azhenley 8y ago
  dep was the tool I used. There are a few other solutions but this one was most popular when I last looked. https://github.com/golang/dep https://github.com/golang/dep
- akmittal 8y ago
  Go modules are the future but use dep as of now
- alyandon 8y ago
  I was using dep but recently switched back to Glide since dep's future is uncertain.

59 points by soroso 8y ago

chx 8y ago

Extremely relevant: We need to talk about Go modules https://www.youtube.com/watch?v=7GGr3S41gjM https://www.youtube.com/watch?v=7GGr3S41gjM

benesch 8y ago

Release notes are available at: https://tip.golang.org/doc/go1.11 https://tip.golang.org/doc/go1.11 Headline features (as judged by me) are: * A new WebAssembly backend, js/wasm, for the gc compiler. * Preliminary support for modules, i.e., the first step towards a package manager built into the Go command. * Improved support for debuggers, especially Delve. * Removal of many direct system calls from the macOS runtime. Unlike on Linux, the macOS system call interface is not considered stable. Go 1.11 binaries are now less likely to break when you upgrade your macOS version because system calls are made through the proper channel (libc).

kjeetgill 8y ago

To get a test of what's actually in the release candidate check out https://github.com/golang/go/milestone/62 https://github.com/golang/go/milestone/62 A lot of new stuff with the new go modules work including vgo and some interesting wasm work.

shawn 8y ago

Go is still one of the most difficult and counter intuitive build systems ever devised. Usually you’d expect a project to build out of the box. Go seems to take a stance of “Haha nope, get ready to figure out which version of the standard library this 4 month old project was written against, then have fun trying to update it to the latest.” I like the language though. Their green threads are still the best.

Walkman 8y ago
Can you tell at least one specific example where they broke the standard library?
- shawn 8y ago
  It figures that my critique would be undermined by the choice of a single word. Look, maybe the stdlib is rock solid. But every time I try to build a Go project, `go build` finds ten ways not to work. Case in point: https://github.com/cretz/tor-dht-poc https://github.com/cretz/tor-dht-poc Try building this. I have no idea what's wrong with it, but it doesn't work. It's cool tech, I want it, but I don't want to immerse myself in the world of hurt^WGo just to get it. I did however at least attempt to fix the problem: https://github.com/cretz/tor-dht-poc/pull/2 https://github.com/cretz/tor-dht-poc/pull/2
  - latchkey 8y ago
    The 'problem' is that the authors did not use dep (soon to be modules) and add the Gopkg.[toml|lock] files.
    - mathw 8y ago
      Or that such tools aren't shipped and part of the standard Go experience. Fortunately that's changing.
      - latchkey 8y ago
        ant, maven and gradle are not shipped with the JVM, yet the java community figures out how to do a build system somehow.
        Karunamon 8y ago
        in fairness, Java has an excuse that it’s ancient in language terms and expectations were different then. Go, not so much - it came out in 2012. Pip and CPAN and Gem had been around for years. Go’s lack of a sane packaging solution this far into its lifetime remains a serious weakness of an otherwise solid platform.
        latchkey 8y ago
alyandon 8y ago
For what it is worth, I agree 100% and dependency management tools like Glide have been indispensable for me.
pknopf 8y ago
> Go is still one of the most difficult and counter intuitive build systems ever devised. I'm currently working on building all the coreclr/corefx repos for .NET Core. Their build system is incredibly convoluted.
deleted 8y ago
[deleted]
irfansharif 8y ago
From Go's 1.0 compatibility guarantee[0]: > It is intended that programs written to the Go 1 specification will continue to compile and run correctly, unchanged, over the lifetime of that specification. [...] Go programs that work today should continue to work even as future "point" releases of Go 1 arise (Go 1.1, Go 1.2, etc.). I've found this to be upheld in practice, especially so for the standard library. I have yet to come across a case where I was concerned with which "version" of the standard library some project was written against. Are you perhaps talking about non-stdlib packages? [0]: https://golang.org/doc/go1compat https://golang.org/doc/go1compat
- ovao 8y ago
  My experience has been the same, so it’s hard to understand where shawn is coming from. There have been impressively few breaking changes to the Go standard library since 1.0. Even when bringing in a number of third-party packages, the only trouble I’ve had building Go projects has been in Windows (which is often treated by Gophers as a second-class platform).

mlevental 8y ago

does it have generics yet? yes I'm sure someone will call me a troll.

agnivade 8y ago

There has been some tremendous improvements for ARM architecture. If you run some serious code on raspberry PIs, get ready to be amazed.

imrehg 8y ago
I skimmed the release notes, and only a little mention there ARM specific changes, can you elaborate on what tremendous improvements are made? Very curious!
- agnivade 8y ago
  Yes, the release notes are a bit humble about it. Specifically, optimized assembly instructions are used now in crypto code and also lot of optimizations have gone into the ARM assembler. One example - https://gist.github.com/carlosedp/f85274ef2a9bacc773cf8ddeedaee821 https://gist.github.com/carlosedp/f85274ef2a9bacc773cf8ddeed....

vesak 8y ago

What is the current recommendation for dependency management in Go for a new project?

azhenley 8y ago
dep was the tool I used. There are a few other solutions but this one was most popular when I last looked. https://github.com/golang/dep https://github.com/golang/dep
akmittal 8y ago
Go modules are the future but use dep as of now
alyandon 8y ago
I was using dep but recently switched back to Glide since dep's future is uncertain.