10 ms·

Go: Planning the 1.5 release

191 points by kristianp 12y ago

jsnk 12y ago
"more complete support for Android" Will we be able to write at least a simple CRUD android app using pure Go?
- dsymonds 12y ago
  Per http://golang.org/s/go14android http://golang.org/s/go14android, apps that don't need the Android UI (e.g. if it's only using OpenGL) should not need Java and could be written in pure Go.
  - tonyhb 12y ago
    In fact, there's a user on Reddit that built an entire Android app with a UI using a webview: https://github.com/MarinX/godroid https://github.com/MarinX/godroid and http://www.reddit.com/r/golang/comments/2kv0s1/go_14_on_android/clpuscd http://www.reddit.com/r/golang/comments/2kv0s1/go_14_on_andr... It's entirely possible right now — we just need it to mature.
    - pjmlp 12y ago
      Webview != pure Go, which is what the OP was asking for.
      - tonyhb 12y ago
        My point was that even apps that do need a UI can be written without Java using Go.
        pjmlp 12y ago
        Faire enough.
- pjmlp 12y ago
  No, if you want to use Android UI. The NDK doesn't offer support for the Android APIs besides graphics, sensors and audio. POSIX is also only partially available. So you will need to either use JNI or write your own UI with OpenGL.
- izacus 12y ago
  Go Android support won't magically rewrite Android Java APIs (which is most of them, including whole UI toolkit).
  - sandGorgon 12y ago
    even if Android is running on ART binary rather than Dalvik ? I have been debating whether you can write code in Go that will work in the JVM GC and is linked through ART... not sure if it is possible.
    - pjmlp 12y ago
      Go semantics are too different from Java. So unless the Android team implements something like Windows Phone language projections (APIs metadata), it won't happen.
nonuby 12y ago
Not being an expert on language design, but these improvements "compiler, assembler, linker, and runtime for 1.5 will be entirely in Go" look like they could lead the to large enhancements in 2.0..... puts on trollface.. possibly even generics :)
edwinnathaniel 12y ago
I played with Go a bit and I like the idea of Go replacing C/C++ to write *NIX tools (no, not the GUI ones, the command-line ones, the daemons, the utilities, the server/collectors).
- Animats 12y ago
  It would be a big step forward to have everything that runs as root written in something safer than C/C++. (Screams come from the Old UNIX Admins.)
  - tene 12y ago
    The biggest stumbling block there, for me, is that it's impossible to write shared libraries in go. You can't write libraries in go that can be used from anything other than go, so until you've converted everything over to go, you'll still need to write libssl.so and friends in C. Go is a great application language, but it doesn't play well enough with others to really be a systems language as long as you can't write libraries other languages can use in it.
    - jzelinskie 12y ago
      While totally unsuited for the aforementioned hypothetical situation, Go has also supported SWIG for a few years now.
    - colin_mccabe 12y ago
      Shared libraries are coming for Go. https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ/edit# https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGh... But shared libraries aren't the only way or even (often) the best way to share code. Especially when we're talking about UNIX tools, it's pretty easy to have one process run another process. Go has a really quick startup time which makes that practical.
      - tene 12y ago
        There are absolutely some scenarios that can be adequately (or better) handled by communicating with another process! I completely agree with you. There's still a large volume of use cases where linking code in-process is a very good fit for the problem. I am looking forward to go someday being suitable for producing native shared libraries. If they ever prioritize and complete that work, that's something I'll absolutely be taking advantage of, and will extend the situations where I'm able to reasonably use go.
mostafah 12y ago
Interesting that a lot of serious and important tools of today are being written in Go (like Docker and Rocket which made another news today). Very impressive for a young programming language which is still at version 1.3.
- Dewie 12y ago
  http://blog.codinghorror.com/the-magpie-developer/ http://blog.codinghorror.com/the-magpie-developer/
  - zaphar 12y ago
    Except that Docker and probably Rocket work really well. And the speed of development on the projects looks to have benefitted from using Go. Speed of development is the killer feature that Go has. For me and most people I know who enjoy the language it provides an almost frictionless development experience that makes us more productive than any other language I know. I'm a language geek so I totally get the whole "Why doesn't go have {Generics,Typeclasses,Hindley-Milner Type Inference,...}" arguments. Sometimes I miss them too. But then I remember how I literally cut months off a personal project's development time using Go. That's when I remember to be greatful for the core teams approach to making a purely pragmatic language that is geared toward frictionless development above all else.
    - Dewie 12y ago
      > Except that Docker and probably Rocket work really well. And the speed of development on the projects looks to have benefitted from using Go. By this you mean that people adopted Go because it is good (in a technical sense), and because of the speed of development rather than because it was "new and shiny"? Fair point. > I'm a language geek so I totally get the whole "Why doesn't go have {Generics,Typeclasses,Hindley-Milner Type Inference,...}" arguments. Why do you bring this up?
      - zaphar 12y ago
        While it was slightly off topic I was trying to head off the inevitable thread about how Go sucks because it doesn't have favorite language feature X.
mostafah 12y ago
Interesting that a lot of serious and important tools of today are being written in Go (like Docker and Rocket which made another news today). Very impressive for a young programming language which is still at version 1.3.
sbt 12y ago
I have mixed feelings about this roadmap. On the one hand it's refreshing to see that they are not pushing new features recklessly and rather focus on core improvements. On the other hand, I think many would agree that the language is ripe for a little bit of innovation at this point.
- notduncansmith 12y ago
  Obligatory comment regarding generics. God I can't wait - if they add generics and a decent package manager, I'm gonna be pushing hard for Go at our shop.
  - cpfohl 12y ago
    What sort of "decent package manger" do you mean? `go get` is pretty solid as far as I can tell, the only thing it's missing is the ability to lock to a particular version...
    - jbooth 12y ago
      It's missing the ability to publish or lock to a particular version, which is a game breaker for shops with >5 people, and the go maintainers don't seem to see it as a problem, making it a permanent game breaker.
      - MoOmer 12y ago
        The idea is that there are a few community-developed and supported dependency managers that do this for you to choose from: https://code.google.com/p/go-wiki/wiki/PackageManagementTools https://code.google.com/p/go-wiki/wiki/PackageManagementTool...
        jezclaremurugan 12y ago
        Been using godeps for a while, and absolutely no complaints so far.
      - 12y ago
mrcwinn 12y ago
Really exciting to hear a focus on stability and performance improvements. The GC improvements are absolutely necessary first and before anything else, in my opinion. Go is new and it doesn't have the benefit of all the hard work and learning that happened in other languages, particularly Java and the JVM. We're playing catch-up there, to be sure. For what it's worth to those new to Go, it's well-worth learning. It's not a perfect language but I've thoroughly enjoyed working with it. It strikes a lot of balances very well.
disputin 12y ago
"the goal is to eliminate C from the source tree so that—except for programs that use cgo" What does the future hold for cgo? Yesterday I ran into erratic DNS success with a cross compiled program, win to lin. Haven't had a chance to look further, but I'm wondering when I'll run into similar snags again.
- axaxs 12y ago
  Can you please raise bug report or let me know what you find here? I work on go native dns library for linux, which iirc is used when crosscompiling rather than libc.
  - disputin 12y ago
    Not sure it's a bug, may be "a well-known limitation" (unknown to me) - https://inconshreveable.com/04-30-2014/cross-compiling-golang-programs-with-native-libraries/ https://inconshreveable.com/04-30-2014/cross-compiling-golan... Have a Go: package main import ( "fmt" "net" "os" ) func main() { hostname := "feeds.feedburner.com" if len(os.Args) > 1 { hostname = os.Args[1] } addr, err := net.LookupHost(hostname) if err != nil { fmt.Printf("err: %v", err.Error()) } else { fmt.Printf("addr: %v", addr) } } set GOOS=linux set GOARCH=amd64 set CGO_ENABLED=0
    - axaxs 12y ago
      Hi, I do not have windows box to crosscompile any longer. I did test go 1.4 rc2 with CGO_ENABLED=0, which builds a static binary, and it gives - addr: [74.125.192.118 2607:f8b0:4001:c00::76] Are you seeing different behavior? Please describe...I'll see if I can look into it.
      - disputin 12y ago
        Hi, $ ./dns-win-xc.bin err: lookup feeds.feedburner.com on [178.22.66.167]:53: no such host $ ./dns-lin.bin addr: [173.194.116.64 173.194.116.69 173.194.116.71 173.194.116.65 173.194.116.73 173.194.116.70 173.194.116.67 173.194.116.66 173.194.116.72 173.194.116.78 173.194.116.68 2a00:1450:400c:c0a::76] Win 8.1, go1.3.3., Centos 7. There's a downvoter for some reason, maybe they have something to add...? Don't let me lead you astray - I haven't yet read that article I linked to, but a quick glimpse suggested to me that this isn't a bug.

191 points by kristianp 12y ago

jsnk 12y ago

"more complete support for Android" Will we be able to write at least a simple CRUD android app using pure Go?

dsymonds 12y ago
Per http://golang.org/s/go14android http://golang.org/s/go14android, apps that don't need the Android UI (e.g. if it's only using OpenGL) should not need Java and could be written in pure Go.
- tonyhb 12y ago
  In fact, there's a user on Reddit that built an entire Android app with a UI using a webview: https://github.com/MarinX/godroid https://github.com/MarinX/godroid and http://www.reddit.com/r/golang/comments/2kv0s1/go_14_on_android/clpuscd http://www.reddit.com/r/golang/comments/2kv0s1/go_14_on_andr... It's entirely possible right now — we just need it to mature.
  - pjmlp 12y ago
    Webview != pure Go, which is what the OP was asking for.
    - tonyhb 12y ago
      My point was that even apps that do need a UI can be written without Java using Go.
      - pjmlp 12y ago
        Faire enough.
pjmlp 12y ago
No, if you want to use Android UI. The NDK doesn't offer support for the Android APIs besides graphics, sensors and audio. POSIX is also only partially available. So you will need to either use JNI or write your own UI with OpenGL.
izacus 12y ago
Go Android support won't magically rewrite Android Java APIs (which is most of them, including whole UI toolkit).
- sandGorgon 12y ago
  even if Android is running on ART binary rather than Dalvik ? I have been debating whether you can write code in Go that will work in the JVM GC and is linked through ART... not sure if it is possible.
  - pjmlp 12y ago
    Go semantics are too different from Java. So unless the Android team implements something like Windows Phone language projections (APIs metadata), it won't happen.

nonuby 12y ago

Not being an expert on language design, but these improvements "compiler, assembler, linker, and runtime for 1.5 will be entirely in Go" look like they could lead the to large enhancements in 2.0..... puts on trollface.. possibly even generics :)

edwinnathaniel 12y ago

I played with Go a bit and I like the idea of Go replacing C/C++ to write *NIX tools (no, not the GUI ones, the command-line ones, the daemons, the utilities, the server/collectors).

Animats 12y ago
It would be a big step forward to have everything that runs as root written in something safer than C/C++. (Screams come from the Old UNIX Admins.)
- tene 12y ago
  The biggest stumbling block there, for me, is that it's impossible to write shared libraries in go. You can't write libraries in go that can be used from anything other than go, so until you've converted everything over to go, you'll still need to write libssl.so and friends in C. Go is a great application language, but it doesn't play well enough with others to really be a systems language as long as you can't write libraries other languages can use in it.
  - jzelinskie 12y ago
    While totally unsuited for the aforementioned hypothetical situation, Go has also supported SWIG for a few years now.
  - colin_mccabe 12y ago
    Shared libraries are coming for Go. https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ/edit# https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGh... But shared libraries aren't the only way or even (often) the best way to share code. Especially when we're talking about UNIX tools, it's pretty easy to have one process run another process. Go has a really quick startup time which makes that practical.
    - tene 12y ago
      There are absolutely some scenarios that can be adequately (or better) handled by communicating with another process! I completely agree with you. There's still a large volume of use cases where linking code in-process is a very good fit for the problem. I am looking forward to go someday being suitable for producing native shared libraries. If they ever prioritize and complete that work, that's something I'll absolutely be taking advantage of, and will extend the situations where I'm able to reasonably use go.

mostafah 12y ago

Interesting that a lot of serious and important tools of today are being written in Go (like Docker and Rocket which made another news today). Very impressive for a young programming language which is still at version 1.3.

Dewie 12y ago
http://blog.codinghorror.com/the-magpie-developer/ http://blog.codinghorror.com/the-magpie-developer/
- zaphar 12y ago
  Except that Docker and probably Rocket work really well. And the speed of development on the projects looks to have benefitted from using Go. Speed of development is the killer feature that Go has. For me and most people I know who enjoy the language it provides an almost frictionless development experience that makes us more productive than any other language I know. I'm a language geek so I totally get the whole "Why doesn't go have {Generics,Typeclasses,Hindley-Milner Type Inference,...}" arguments. Sometimes I miss them too. But then I remember how I literally cut months off a personal project's development time using Go. That's when I remember to be greatful for the core teams approach to making a purely pragmatic language that is geared toward frictionless development above all else.
  - Dewie 12y ago
    > Except that Docker and probably Rocket work really well. And the speed of development on the projects looks to have benefitted from using Go. By this you mean that people adopted Go because it is good (in a technical sense), and because of the speed of development rather than because it was "new and shiny"? Fair point. > I'm a language geek so I totally get the whole "Why doesn't go have {Generics,Typeclasses,Hindley-Milner Type Inference,...}" arguments. Why do you bring this up?
    - zaphar 12y ago
      While it was slightly off topic I was trying to head off the inevitable thread about how Go sucks because it doesn't have favorite language feature X.

mostafah 12y ago

sbt 12y ago

I have mixed feelings about this roadmap. On the one hand it's refreshing to see that they are not pushing new features recklessly and rather focus on core improvements. On the other hand, I think many would agree that the language is ripe for a little bit of innovation at this point.

notduncansmith 12y ago
Obligatory comment regarding generics. God I can't wait - if they add generics and a decent package manager, I'm gonna be pushing hard for Go at our shop.
- cpfohl 12y ago
  What sort of "decent package manger" do you mean? `go get` is pretty solid as far as I can tell, the only thing it's missing is the ability to lock to a particular version...
  - jbooth 12y ago
    It's missing the ability to publish or lock to a particular version, which is a game breaker for shops with >5 people, and the go maintainers don't seem to see it as a problem, making it a permanent game breaker.
    - MoOmer 12y ago
      The idea is that there are a few community-developed and supported dependency managers that do this for you to choose from: https://code.google.com/p/go-wiki/wiki/PackageManagementTools https://code.google.com/p/go-wiki/wiki/PackageManagementTool...
      - jezclaremurugan 12y ago
        Been using godeps for a while, and absolutely no complaints so far.
    - 12y ago

mrcwinn 12y ago

Really exciting to hear a focus on stability and performance improvements. The GC improvements are absolutely necessary first and before anything else, in my opinion. Go is new and it doesn't have the benefit of all the hard work and learning that happened in other languages, particularly Java and the JVM. We're playing catch-up there, to be sure. For what it's worth to those new to Go, it's well-worth learning. It's not a perfect language but I've thoroughly enjoyed working with it. It strikes a lot of balances very well.

disputin 12y ago

"the goal is to eliminate C from the source tree so that—except for programs that use cgo" What does the future hold for cgo? Yesterday I ran into erratic DNS success with a cross compiled program, win to lin. Haven't had a chance to look further, but I'm wondering when I'll run into similar snags again.

axaxs 12y ago
Can you please raise bug report or let me know what you find here? I work on go native dns library for linux, which iirc is used when crosscompiling rather than libc.
- disputin 12y ago
  Not sure it's a bug, may be "a well-known limitation" (unknown to me) - https://inconshreveable.com/04-30-2014/cross-compiling-golang-programs-with-native-libraries/ https://inconshreveable.com/04-30-2014/cross-compiling-golan... Have a Go: package main import ( "fmt" "net" "os" ) func main() { hostname := "feeds.feedburner.com" if len(os.Args) > 1 { hostname = os.Args[1] } addr, err := net.LookupHost(hostname) if err != nil { fmt.Printf("err: %v", err.Error()) } else { fmt.Printf("addr: %v", addr) } } set GOOS=linux set GOARCH=amd64 set CGO_ENABLED=0
  - axaxs 12y ago
    Hi, I do not have windows box to crosscompile any longer. I did test go 1.4 rc2 with CGO_ENABLED=0, which builds a static binary, and it gives - addr: [74.125.192.118 2607:f8b0:4001:c00::76] Are you seeing different behavior? Please describe...I'll see if I can look into it.
    - disputin 12y ago
      Hi, $ ./dns-win-xc.bin err: lookup feeds.feedburner.com on [178.22.66.167]:53: no such host $ ./dns-lin.bin addr: [173.194.116.64 173.194.116.69 173.194.116.71 173.194.116.65 173.194.116.73 173.194.116.70 173.194.116.67 173.194.116.66 173.194.116.72 173.194.116.78 173.194.116.68 2a00:1450:400c:c0a::76] Win 8.1, go1.3.3., Centos 7. There's a downvoter for some reason, maybe they have something to add...? Don't let me lead you astray - I haven't yet read that article I linked to, but a quick glimpse suggested to me that this isn't a bug.