16 ms·

Go 1.6 is Released

562 points by geetarista 11y ago

robbles 11y ago
There was some discussion leading up to the release about whether to merge the "SSA" branch, which seems to be a refactor that allows for easier compile time optimisations but also slows compile times for the time being. Does anyone know if that was included in this release?
- nathany 11y ago
  The SSA branch is for a future version of Go, possibly Go 1.7.
- zenlikethat 11y ago
  IIRC from the e-mail thread, the idea being discussed was to potentially merge the SSA branch immediately after the release (in order to have as much time as possible to test it), so I'd be surprised to find it in this release. There were concerns about the compiler slowdown but I didn't see the end result of the thread.
- dsymonds 11y ago
  The SSA changes are not in Go 1.6. They're expected to be in Go 1.7.
andreamichi 11y ago
A draft for the 1.6 release notes: https://tip.golang.org/doc/go1.6 https://tip.golang.org/doc/go1.6
enneff 11y ago
Binaries are up but not everything is fully updated yet. Announcement blog post coming shortly. Edit: Blog post up: https://blog.golang.org/go1.6 https://blog.golang.org/go1.6 maybe change the article link to that?
- dang 11y ago
  Ok, we changed from https://golang.org/dl/#go1.6 https://golang.org/dl/#go1.6 to that.
niccaluim 11y ago
Not officially. "Go 1.6 is soon (but not yet)." - commit message from today.
- deleted 11y ago
  [deleted]
- JDazzle 11y ago
  The front page of golang.org announces the release of Go 1.6. It has been officially released
- bsg75 11y ago
  I just got this email: "Hello gophers, We just released Go 1.6. You can read the announcement blog post here: https://blog.golang.org/go1.6 https://blog.golang.org/go1.6 ..."
sinatra 11y ago
Go checks a lot of boxes for my ideal language for developing web services: Static type, C derived, has garbage collection, generates a single binary, supports concurrency very well, is opinionated, is small/simple, its community prefers to just use standard lib for most work, etc. Yes, Generics is an issue and so is debugging. But, overall, I can't think of many other options that check so many boxes. EDIT: I must highlight the point about checking lot of boxes. In many discussions about features of programming languages, we get responses like, "language Y does that too. Why not choose that language?" Well, because we don't pick languages for one specific feature. We pick them for the combination of features.
- zelcon5 11y ago
  > generics Go makes it easy for third party applications to parse the language,so generics are possible with pre-processing/codegen; e.g., https://clipperhouse.github.io/gen/ https://clipperhouse.github.io/gen/
- bigdubs 11y ago
  The more I dig into type coercion and interfaces the less I miss generics. Still not 100% there, but for day to day the things I used to use generics for have been replaced by alternates. I still wish I never had to write `interface{}` though. Debugging absolutely needs work though.
  - xyproto 11y ago
    Even with the delve debugger?
    - CSDude 11y ago
      Despite being a great work, delve is slow and sometimes might skip some of my breakpoints and have problems in debugging goroutines.
      - icholy 11y ago
        Yeah, it can get pretty confusing. It would nice if there was a way to define a breakpoint that only gets tripped by a specific goroutine.
Cyph0n 11y ago
I can't wait to see what's new in 1.6! I really had a pleasure working with Go for my senior project last year. If I need to write either a server (HTTP or TCP/UDP), or a client application that must be easy to build and distribute, Go is my first choice. What Go is lacking at this moment in my opinion is: 1) A comprehensive and mature web framework. Play w/ Scala is my go-to choice now, with Django a very close second. 2) A decent cross-platform GUI toolkit; heck, I'd settle with Qt and/or .NET bindings for Go. The power of Go is statically linked binaries, and I think the area of desktop applications will be easy to target if a good solution emerges.
- ue_ 11y ago
  >A comprehensive and mature web framework. Call me old fashioned, but I've only ever used the stuff from Gorilla (mux and sessions) and before that plain CGI with Go, and running behind uriel's cgd to hook it up with nginx. I've never been fond of web frameworks that try to hide a lot of stuff from you.
- golergka 11y ago
  Why GUI though? Go shines for servers, but I would never want to write a desktop application with it though. Especially if I could do it in C#.
  - rhodysurf 11y ago
    Because a C# GUI on Linux or Mac is not very native looking. Also for the same reason some like Go over Java, static binaries instead of requiring JVM or CLR be installed. On another note, because writing programs in Go is much faster than say C++ or C for most use cases.
    - pjmlp 11y ago
      There is this thing called AOT compilation for Java and .NET.
  - Cyph0n 11y ago
    The way I see it: 1) Go produces 100% portable code. I absolutely suffered doing the same for a very basic C++ program that used C++11's std::regex. Compiled fine on clang-3.5 on OS X, fails on clang on Linux. It took me hours of searching online to find and install the exact version of GCC that actually fills in std::regex instead of just keeping it empty. Trust me, there are some versions that do that! No errors during compilation, but still doesn't run. 2) Statically compiled binaries. I can be confident that the absence of some essential library from the user's end won't break my app. 3) Cross-platform, especially with something like Qt. Write once, compile for each OS, then run - done!
golergka 11y ago
I just recently started with go, but I love how simple (apart from horrible $GOPATH) and effective that is. Still can't get over the moment I realized that in order to deploy my web server on an empty virtual box all I had to so was to build and upload. After all the languages and frameworks that required endless customization and setting up it was a true eureka moment.
- sigjuice 11y ago
  What is horrible about $GOPATH?
  - golergka 11y ago
    The notion that you can't put the codebase wherever you want to on your own computer. A "project", as a folder, should be atomic and work regardless of where it is moved; the $GOPATH convention just breaks this encapsulation completely. For example, when I create client-server projects, sometimes I put both client and server under the same git repository, in the same folder (whether it is a good or bad decision is another discussion). $GOPATH forces me, therefore, to put a client project in the $GOPATH tree, and this just feels ugly. Of course, you can change $GOPATH per project, and I end up with `export $GOPATH` in makefiles, but this is rather ugly too.
    - sigjuice 11y ago
      I completely agree that a developer should have the freedom to put the "project" folder anywhere. As a golang newbie, I went through the motions of setting up GOPATH, but did not give it too much consideration. It also isn't clear to me how one might have multiple copies of the same project.
      - golergka 11y ago
        > It also isn't clear to me how one might have multiple copies of the same project. A lot of technologies employ temporary, cache data storage to build for specific platforms and/or configurations. This data is derived from the actual project, and is not saved in the repo, but it often takes significant time to generate. For example, I work with Unity3d. Unity3d has a great graphics pipeline; if you release the same project for different platforms, you still have the original PSD textures in source control, and they are automatically exported to relevant graphic formats when you switch between different platforms. However, this generation takes a LONG time on different projects, and you usually have several copies of the project on your hard drive, each with a different platform selected. git even introduced a feature that is usable precisely for that scenario, worktree.
CSDude 11y ago
I would just love some IDE-debug love and better packaging. More packages I use and more I distribute my files, compilation takes considerably longer. Maybe I do not know, but is there some process to compile some parts before hand and link only the changed resulting binary?
nathany 11y ago
There is a Go AMA on reddit for the next 24 hours. https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_the_go_contributors_ask_us_anything/ https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_t...
- lsllc 11y ago
  OK Go are also doing a reddit AMA! https://www.reddit.com/r/IAmA/comments/46asrt/we_are_ok_go_were_here_to_talk_reddit_so_ask_us/ https://www.reddit.com/r/IAmA/comments/46asrt/we_are_ok_go_w...
deleted 11y ago
[deleted]
jonesb6 11y ago
The reason I love Go is that every time I pull it out, I write a small amount of it and it runs beautifully. For example my company has a critical micro-service implemented in ~300 lines of Go, it's been running for six months now without a single hiccup, highly performant, very sexy. The reason I will almost never use Go for web apps is because interaction with databases is limited (almost entirely) to raw queries. Maybe I'm spoiled by the likes of Active Record, Sequelize, Mini-mongo, Sql-alchemy, etc, but it's a huge drop in efficiency to spin my own SQL. The point to take away here is that Go, more so then many other languages IMO, has its strengths and weaknesses. If you use Go in one of it's weaker use-cases you're gonna have a bad time. If you use Go for one of it's strengths you're gonna have a great time. See you guys and gals in n weeks when we need to rehash the pros and cons of Golang again.
- Cshelton 11y ago
  Exactly. I love how every release of Go, or Rust, mainly those two, turns into so much rehashing...it hurts. Little discussion about the release changes happens...a simple google search will return all the discussions of pros and cons you would ever want to read in a life time...
- no1youknowz 11y ago
  > The reason I will almost never use Go for web apps is because interaction with databases is limited > but it's a huge drop in efficiency to spin my own SQL. Sorry, I have to disagree. I come from PHP, where when you sneeze an ORM appears. I actually am a DBA also. I am very familiar with SQL and I love writing out raw SQL. I don't see this as a limiting feature. It doesn't affect me at all. There are ORMs for Go as well. But I don't know how good they are. YMMV! Last point. I have shipped into production a web app using GIN framework. I ported from PHP to Go. I didn't feel I was losing anything. Go is amazing. It hasn't let me down yet. I doubt it will.
  - xrstf 11y ago
    > I come from PHP, where when you sneeze an ORM appears. YMMD.
  - 11y ago
eddiezane 11y ago
I've really enjoyed the time I've spent with Go but feel like the state of dependency management has kept me away. Am I being stubborn in my longing for an npm, Ruby Gems, or pip? Is there a reason why one of these hasn't emerged/been adopted by the community? (I'm aware of the 1.5 experiment with vendoring.) Semver and pinning versions has always just made sense to me. I can easily adopt new features and fixes automatically without worrying about things breaking. How does the community feel this far along?
- kasey_junk 11y ago
  Dependency management is a huge weakness in golang and there isn't much point in debating it. That said, my time in golang has crystalized something I'd been leaning towards anyway, that is dependencies are way more dangerous than we think they are. I find all of my code now (golang or otherwise) less likely to have dependencies, and therefore dependency management weaknesses are mitigated (not solved).
  - majormjr 11y ago
    Agreed, Go's strong standard library also helps avoid dependencies.
- munificent 11y ago
  > Is there a reason why one of these hasn't emerged/been adopted by the community? Personally, I believe package management is one of those things that really does need an official blessed solution. Otherwise, you have a nasty bootstrapping problem: if there are ten competing package managers, how do you install them, and how do package developers know which one to put their packages in? Collection types have the same problem. You basically need to put some collections in a blessed core library, otherwise it's virtually impossible to reliably share code. Any function that wants to return a list ends up having to pick one of N list implementations and which ever one they pick means their library is hard for users of the other N-1 lists to consume. The Go team hasn't blessed a package manager, I think, because it's not that relevant to them: they mostly live within Google's own infrastructure which obviates the need for something like version management. They probably don't feel the pain acutely and/or might not have the expertise to design one that would work well outside Google.
helper 11y ago
Rebuilding our integration docker image right now. If all our tests pass I expect to have go 1.6 binaries in production by this evening.
Exuma 11y ago
I upgraded and it broke our app, something to do with the way it handles https has changed, not sure what
- mholt 11y ago
  What do your tests reveal?
- in_me_i_trust 11y ago
  yes, they've been asking people to test https for awhile as it now uses http/2
- nathany 11y ago
  If it works in Go 1.5.3 but not Go 1.6, definitely consider filing an issue. https://github.com/golang/go/blob/master/CONTRIBUTING.md https://github.com/golang/go/blob/master/CONTRIBUTING.md
obelisk_ 11y ago
Release notes: https://golang.org/doc/go1.6 https://golang.org/doc/go1.6 Mods, maybe change OP link to this?
- enneff 11y ago
  This is the better link target: https://blog.golang.org/go1.6 https://blog.golang.org/go1.6
bmh_ca 11y ago
Go has a lot going for it. That said, there were a few points I noted, based on a recent go I gave it (pardon the pun), at least in relation to my style of development for this project: 1. It's hard to tinker, mostly because it's fussy about what variables are defined or used. This is a strength in the usual course, but when one is trying to posit what a poorly documented 3rd party API is doing it can be a serious pain. By tinkering, I found that I often had to comment out or uncomment lines, or handle or ignore errors. There was a lot of flipping up to the beginning of the file. I would spend so much time fiddling with the lines that I would at times forget what I was even trying to do. I might just have memory problems, I acknowledge. :) However, what would make sense is a go "mode" where it runs in a non-strict way, with what would ordinarily be errors being warnings. A "tinker" or "whirl" mode, so to speak, that softened the requirements so one could get a better sense of what was happening before committing to a design. An interpreter mode might also be quite valuable, to address this problem and the ones below. 2. Error propagation - I see the point of errors being returned and the lack of a "throw/catch" style, and its benefit, but I feel it's a lot of typing for marginal gain. I usually end up with an error propagating a set of strings that ultimately conclude as: "Database error: transaction error: processing error: http error: reason", which is to say: equivalent but less information than a stack trace would give. I see the mandatory error acknowledgement simultaneously as a strength and a waste of time, and I admit being on the fence about it. 3. The next point I am not on the fence about: Debugging. It is not apparent how to get a stack trace, and the best option looks like including a third party application that generated errors. For the obvious and reasons below, this is a problem. 4. Package management: This was fussy and could be time-consuming. It is not apparent to me why one needs a GOROOT and a GOPATH. I think Python's virtualenv gets it right, by comparison. A second but related problem is package versions. Maybe I'm missing something, but making sure you get the latest semantically equivalent version (in the semver sense) was not apparent. 5. Package debugging: If you include a 3rd party package, and it's broken in any way, it's a veritable quagmire to identify and fix the problem. My experience was that the best way to debug a third party package was to block and copy all its bits and then debug it as a local source in your own. Obviously this is bad for a long number of reasons, and I might be missing something, but no more apparent option appeared when I investigated on how to tell what is even happening inside third packages. 6. Automated testing: I've not seen a test runner that reloads when source files change, particularly one that might be used with goapp from AppEngine, meaning go auto-testing can be quite a bit of patient thumb-twiddling as the binary reloads. Which is all to say that there are some concerns about developing a larger project in this language, particularly if there is quite a bit of complexity that needs lots of testing or potential debugging and/or inclusion of many third party packages. I've not reviewed the 1.6 notes, so perhaps these are addressed to some extent there. In any case, none of the issues above is insurmountable, and overall I give the Go design a lot of credit for experimentation and interesting choices, but the issues I've seen above give me pause before committing a team to the language – for the moment.
dh997 11y ago
Go CSP is minimal and ortongonal, I just wish it did three things: 0. could lto optimize or link against a shared library to reduce the titanic size of compiled programs and cut down on duplication of instruction. Therue is no practical sense in wasting memory and storage on systems with dynamic linkers: edge cases of including the world for rare situations but YAGNI in real production systems. 1. could output flat binaries and self-host runtime (panics) for practical kernel development in Go 2. Generics (both types and immutable constraints), I think C++1z has the right approach to this (and constexpr and constant arrays are nice and are able to provide more hints to the compiler). I also wonder why Go wasnt developed as an IR compiler / llvm frontend, because it would've levered an existing debug and portability ecosystem with much less work.
- hacknat 11y ago
  0. It does dynamic linking on most stdlibs (libc, etc) 1. What do you mean self-hosted runtime? Anyways, golang will likely never be a good candidate for kernel development, but in theory you could do it (go supports assembly) 2. Generics would be nice. Who knows, maybe they'll be in 2.0? Go wasn't developed in llvm, because they wanted to build something very fast, and they were planning on writing the compiler in golang from the start (so that it could be part of the libs). Also having your own scheduler kind of breaks debugging, you can build go programs with gccgo, but gdb doesn't work because it has no concept of what a "go routine" is. Delve (https://github.com/derekparker/delve https://github.com/derekparker/delve) will eventually fill the hole of the missing debugger, imo. Edit: Formatting
  - aikah 11y ago
    > 2. Generics would be nice. Who knows, maybe they'll be in 2.0? There will be no 2.0 and there will be no generics, at all.In fact there will never be any changes to the type system, cause it's impossible at this point.
    - hacknat 11y ago
      Not that I even care that much, but that's total crap. Compile-time generics, which is what most people seem to be referring to when they say they want generics in Go, are eminently doable. It would not be hard to implement. Runtime generics are probably possible as well. What are you even basing your assertion on? Edit: What do you mean, "there will never be a 2.0"? Do you have a crystal ball?
ukd1 11y ago
https://golang.org/doc/go1.6 https://golang.org/doc/go1.6 - lists the changes
protomyth 11y ago
Can someone give a decent explanation of the following: 1) Supposed I have a library that was written in C that receives a security update which is used in a Go program. Under what conditions do I need to get a recompiled version of the Go program. 2) Supposed I have a library that was written in Go that receives a security update which is used in a Go program. Under what conditions do I need to get a recompiled version of the Go program. 3) Is there a way to tell from the binary that the program was written in Go? Trying to figure this out for my Sys Admin dealing with Vendors role.
- skybrian 11y ago
  Best to assume that you will need to recompile a Go program yourself. If you don't have the source and know how to build it, you're in trouble.
  - protomyth 11y ago
    I am a bit worried about accepting software from vendors written in Go given those circumstances. For example, the recent OpenSSL patches would be an example. Are the Go programs fine if I update OpenSSL or did they include OpenSSL's libraries statically? If someone writes a Go replacement for OpenSSL does that change the scenario. Given a lot of software makes it to my door written by government contractors for grant management / compliance, I don't have the source code.
    - skybrian 11y ago
      Go has its own crypto library that's maintained by a real crypto expert so that might not be the best example. Still, if they do find a bug, there will be a new release of Go and you (or your supplier) should be prepared to recompile. Running unmaintainable, unfixable binaries may be standard practice in other places but for Go it's not really viable. It's a different culture with different practices.
      - protomyth 11y ago
        > Running unmaintainable, unfixable binaries may be standard practice in other places but for Go it's not really viable. It's a different culture with different practices. Well, since I cannot just patch a library, I am a lot more worried about the implications of Go programs being the "unmaintainable, unfixable binaries".
dominotw 11y ago
I've been writing some gocode recently and huge chunk of code is if err != nil ... I know you can do if ; err!=nil but that not that much better and you end up in deeply nested if blocks. i have to mentally block out err !=nil to read any gocode linearly. How is this acceptable, I don't get it. https://blog.golang.org/errors-are-values https://blog.golang.org/errors-are-values We recently scanned all the open source projects we could find and discovered that this snippet occurs only once per page or two This seems false from my experience, def way more than 1 or 2 instances per page.
- sergiotapia 11y ago
  I agree, it's exactly why I stopped using the language. err != nil checks all over the place gave me a headache. I since moved on to Elixir and it's really great. I just wish that it would allow me to have just a single deployable binary. That's something I really miss about Go.
  - ocean3 11y ago
    exrm provides a deployable tar file. Granted its not single binary.
- jimjimjim 11y ago
  No point in raising an error if you aren't going to do something about it. If you don't care about an error then don't check it. If you do care then handle it. and you don't need massive if blocks, you can use more early returns as part of the err checks.
  - dominotw 11y ago
    I don't exactly understand what you are suggesting. Ofcourse, I care about error and want them to be handled. Problem often is that method I am in doesn't know how to handle the error and have to bubble it up to a place where there is knowledge about how to handle it. Here is Erik Meijer talking about golang exception handling https://www.youtube.com/watch?v=a2ihmMmSfwk&t=577 https://www.youtube.com/watch?v=a2ihmMmSfwk&t=577 The golang guy doesn't answer the question properly and repeats "exceptions are not for control flow". Really disappointing answer and cringeworthy interview.
alblue 11y ago
Release notes are here: https://golang.org/doc/go1.6 https://golang.org/doc/go1.6 Notably new this time is transparent http/2 support and tighter rules for integration with C.
zenlikethat 11y ago
Congratulations to the Go team! There are many excellent folks working on the Go language and it's been an absolute joy to work with in my experience.
fuddle 11y ago
Go is great, but I wish they would add terany operator support.
- oofabz 11y ago
  They won't. The Go authors value simplicity. Many people dislike ternary syntax and find it hard to read. Go errs on the side of verbosity and readability. It is sort of the opposite of Perl in that respect.
  - fuddle 11y ago
    Which is more simple, an if/else block or a terany operator? if/else: if i == 0 { return "foo" } else { return "bar" } terany: return i == 0 ? "foo" : "bar"
jay_kyburz 11y ago
Can anybody tell me if you can run Go in Chrome using the NaCL stuff? I remember there was talking of it a few years ago but I don't know if anything ever came of it. A google seach show that you could build for NaCal in Go 1.3 but only run it in special builds not Chrome itself.
- iso-8859-1 11y ago
  As you can see on https://github.com/golang/go/wiki/NativeClient https://github.com/golang/go/wiki/NativeClient , there is no PNaCl support, which means it is only available in the Chrome Web Store.
  - jay_kyburz 11y ago
    Thanks for the heads up.
kiril-me 11y ago
Do you know any framework using http2 on go lang?
pori 11y ago
Seen a lot of Erlang mentions in this thread. Is that the native alternative to Go? Personally, I prefer to write code in a functional manner. While I've always thought Go looked like an amazing platform for programming in general, I haven't been keen on moving to another imperative language. It seems the landscape for functional alternatives are mainly Scala and Clojure which are both based on the JVM and require a bit of time to learn the tooling. I am not a Java or JVM export, so I haven't been too inspired by this either.
- cies 11y ago
  > It seems the landscape for functional alternatives are mainly Scala and Clojure Cannot talk about functional alternatives without mentioning Haskell. OCaml (when abstaining from the "O", as many OCaml'ers do; similarly Scala'ers often abstain from the "O" in Scala) is also an interesting option. Finally there's Rust, which is besides being a bit more functional also more low-level than Go. While being fairly young, Frege[1] also deserves a mention. Very similar to Haskell, but on the JVM. 1: https://github.com/Frege/frege https://github.com/Frege/frege
  - pori 11y ago
    Well, I was tempted to mention Haskell. Problem is, I haven't found a practical use for it. Of all the FP languages, this is actually the one I am most tempted by. I had forgotten about Rust. Are there major projects being used for this yet? I've heard it's picking up quite a bit.
    - codygman 11y ago
      > Well, I was tempted to mention Haskell. Problem is, I haven't found a practical use for it. That's the same as saying: Well, I was tempted to mention Go. Problem is, I haven't found a practical use for it. That is to say, just pick a problem and try to use Haskell to solve it. 90% chance it will fit your niche fine.
    - steveklabnik 11y ago
      Depends on how you define "major". Dropbox is currently running Rust in production, at the core of their product. Has been for about six weeks now. That's probably the largest, most serious use. There are also tiny bits in Firefox, that will be included starting with the next release. There's a lot of other usage too, it all depends on how you define "major".
jernfrost 11y ago
Read the debate with Go vs Java here with interest. I'd like to add a point I think is missed by the Java crowd in favor of Go. Complexity isn't free. Java might have and abundance of tools, IDE's, language features etc, but you can't claim that matching up every Go feature or tool with something superior found among the huge Java universe makes Java superior in every way. I find that there is an unfair assumption being used by the Java advocates, here which is that every software developer has a deep knowledge of Java. As one of those people who can certainly write Java code, but who is not familiar with the Java eco system and has not spend a lot of time with I must say that Go to me is a clear winner. My exposure to professional Java development has been quite frustrating compared to writing Go code. Every Java project I have gotten has used some different built tool: Ant, Maven or Gradle. They have also all seem to use different IDE's. The complexity of each of these tools is staggering. Considerable time has to be spend learning these tools. Go in comparison is laughably simple. You can get productive in less than a week without ever having used the dam thing. The tools and the libraries are very quick to get into. In fact I find Go code so easy to read that although I am an iOS developer by trade, I frequently read Go code to understand how various algorithms and network stuff works. An organization would easily be able to add people to a Go project without much previous exposure to the language. Adding people with limited Java knowledge to a Java project however would be far more expensive. Considerable time would be needed for training. There is a lot of money to be saved from having a well thought out standard library combined with a simple language with simple well thought out tools. As a Swift/Objective-C developer, my major gripes with my development process is actually the complexity of the tooling. Both Swift and Objective-C are fairly straightforward languages IMHO. In this regard I greatly envy Go developers although I do enjoy the strong typing and generics in Swift.
kampsy 11y ago
I fell in love with python because it was clean and easy to work with. Like most developers, I used to use c when I needed a performance boast. Then I got fade up and decided to learn a new language that could give me the feel of python and the performance of c. Two languages from a list of 10 passed the above criteria Go and Rust. Java did not even make the list because I Don't use languages that are owned by evil empire's(Oracle). I went with Go because it was easy to use and understand. I could read other people's code easily( Even with a large code base, I have never found myself scratching my head trying to figure out my own code does), could set up my workspace in less than a minute and all the text editors I used (sublime, Atom, Vim) supported it. I Don't really care about the fancy IDE's. Just syntax highlighting and code completion is good for me. I started learning go on September 2015. And I have managed to implement the porter stemmer algorithm and an inverted index in it. Miss generics but LOVE interfaces. The fact that any concrete type that implements method 1 satisfies interface 8 is awesome. You can easily reuse code from different package without changing anything.
sriram_malhar 11y ago
Have been using Go since its release, and like the deployment experience, the feeling of solidity of putting together a tight system. The toolchain is great. 1.6 is yet another Solid release in that direction. Thank you all. However, the _language_ doesn't give me much programming pleasure alas. Since there is plenty of time for Christmas, here's my syntax wish list :) '?': C's if-then-else operator. Block-syntax for closures ala Ruby. Unifying blocks and closures makes creating DSLs easy, but doesn't add to cognitive load (no more than using anon funcs) Pattern matching like Scala, ML, Rust. Sum types -- (Yeah, I lied. Not just syntax enhancements), or at least discriminated unions. I'd like to see an example (in the FAQ entry on the topic) on why support for it is troublesome. For 2017 Christmas, ------------------- Macros ala Nim. Systemic support for Goroutines, including detection of conditions where a goroutine would never get scheduled. Erlang-like tools for built-in goroutine insight. ------ My ideal language would be an intersection of Nim+Go
- sacado2 11y ago
  Sum types don't play well with zeroed values by default. What is the zero value of a sum type ? Pattern matching doesn't work well without sum types. So don't hold your breath.
rphlx 11y ago
> Source trees that contain a directory named “vendor” that is not used in accordance with the new feature will require changes to avoid broken builds That seems a little bit distasteful.

562 points by geetarista 11y ago

There was some discussion leading up to the release about whether to merge the "SSA" branch, which seems to be a refactor that allows for easier compile time optimisations but also slows compile times for the time being. Does anyone know if that was included in this release?

nathany 11y ago
The SSA branch is for a future version of Go, possibly Go 1.7.
zenlikethat 11y ago
IIRC from the e-mail thread, the idea being discussed was to potentially merge the SSA branch immediately after the release (in order to have as much time as possible to test it), so I'd be surprised to find it in this release. There were concerns about the compiler slowdown but I didn't see the end result of the thread.
dsymonds 11y ago
The SSA changes are not in Go 1.6. They're expected to be in Go 1.7.

andreamichi 11y ago

A draft for the 1.6 release notes: https://tip.golang.org/doc/go1.6 https://tip.golang.org/doc/go1.6

enneff 11y ago

Binaries are up but not everything is fully updated yet. Announcement blog post coming shortly. Edit: Blog post up: https://blog.golang.org/go1.6 https://blog.golang.org/go1.6 maybe change the article link to that?

dang 11y ago
Ok, we changed from https://golang.org/dl/#go1.6 https://golang.org/dl/#go1.6 to that.

niccaluim 11y ago

Not officially. "Go 1.6 is soon (but not yet)." - commit message from today.

deleted 11y ago
[deleted]
JDazzle 11y ago
The front page of golang.org announces the release of Go 1.6. It has been officially released
bsg75 11y ago
I just got this email: "Hello gophers, We just released Go 1.6. You can read the announcement blog post here: https://blog.golang.org/go1.6 https://blog.golang.org/go1.6 ..."

sinatra 11y ago

Go checks a lot of boxes for my ideal language for developing web services: Static type, C derived, has garbage collection, generates a single binary, supports concurrency very well, is opinionated, is small/simple, its community prefers to just use standard lib for most work, etc. Yes, Generics is an issue and so is debugging. But, overall, I can't think of many other options that check so many boxes. EDIT: I must highlight the point about checking lot of boxes. In many discussions about features of programming languages, we get responses like, "language Y does that too. Why not choose that language?" Well, because we don't pick languages for one specific feature. We pick them for the combination of features.

zelcon5 11y ago
> generics Go makes it easy for third party applications to parse the language,so generics are possible with pre-processing/codegen; e.g., https://clipperhouse.github.io/gen/ https://clipperhouse.github.io/gen/
bigdubs 11y ago
The more I dig into type coercion and interfaces the less I miss generics. Still not 100% there, but for day to day the things I used to use generics for have been replaced by alternates. I still wish I never had to write `interface{}` though. Debugging absolutely needs work though.
- xyproto 11y ago
  Even with the delve debugger?
  - CSDude 11y ago
    Despite being a great work, delve is slow and sometimes might skip some of my breakpoints and have problems in debugging goroutines.
    - icholy 11y ago
      Yeah, it can get pretty confusing. It would nice if there was a way to define a breakpoint that only gets tripped by a specific goroutine.

Cyph0n 11y ago

I can't wait to see what's new in 1.6! I really had a pleasure working with Go for my senior project last year. If I need to write either a server (HTTP or TCP/UDP), or a client application that must be easy to build and distribute, Go is my first choice. What Go is lacking at this moment in my opinion is: 1) A comprehensive and mature web framework. Play w/ Scala is my go-to choice now, with Django a very close second. 2) A decent cross-platform GUI toolkit; heck, I'd settle with Qt and/or .NET bindings for Go. The power of Go is statically linked binaries, and I think the area of desktop applications will be easy to target if a good solution emerges.

ue_ 11y ago
>A comprehensive and mature web framework. Call me old fashioned, but I've only ever used the stuff from Gorilla (mux and sessions) and before that plain CGI with Go, and running behind uriel's cgd to hook it up with nginx. I've never been fond of web frameworks that try to hide a lot of stuff from you.
golergka 11y ago
Why GUI though? Go shines for servers, but I would never want to write a desktop application with it though. Especially if I could do it in C#.
- rhodysurf 11y ago
  Because a C# GUI on Linux or Mac is not very native looking. Also for the same reason some like Go over Java, static binaries instead of requiring JVM or CLR be installed. On another note, because writing programs in Go is much faster than say C++ or C for most use cases.
  - pjmlp 11y ago
    There is this thing called AOT compilation for Java and .NET.
- Cyph0n 11y ago
  The way I see it: 1) Go produces 100% portable code. I absolutely suffered doing the same for a very basic C++ program that used C++11's std::regex. Compiled fine on clang-3.5 on OS X, fails on clang on Linux. It took me hours of searching online to find and install the exact version of GCC that actually fills in std::regex instead of just keeping it empty. Trust me, there are some versions that do that! No errors during compilation, but still doesn't run. 2) Statically compiled binaries. I can be confident that the absence of some essential library from the user's end won't break my app. 3) Cross-platform, especially with something like Qt. Write once, compile for each OS, then run - done!

golergka 11y ago

I just recently started with go, but I love how simple (apart from horrible $GOPATH) and effective that is. Still can't get over the moment I realized that in order to deploy my web server on an empty virtual box all I had to so was to build and upload. After all the languages and frameworks that required endless customization and setting up it was a true eureka moment.

sigjuice 11y ago
What is horrible about $GOPATH?
- golergka 11y ago
  The notion that you can't put the codebase wherever you want to on your own computer. A "project", as a folder, should be atomic and work regardless of where it is moved; the $GOPATH convention just breaks this encapsulation completely. For example, when I create client-server projects, sometimes I put both client and server under the same git repository, in the same folder (whether it is a good or bad decision is another discussion). $GOPATH forces me, therefore, to put a client project in the $GOPATH tree, and this just feels ugly. Of course, you can change $GOPATH per project, and I end up with `export $GOPATH` in makefiles, but this is rather ugly too.
  - sigjuice 11y ago
    I completely agree that a developer should have the freedom to put the "project" folder anywhere. As a golang newbie, I went through the motions of setting up GOPATH, but did not give it too much consideration. It also isn't clear to me how one might have multiple copies of the same project.
    - golergka 11y ago
      > It also isn't clear to me how one might have multiple copies of the same project. A lot of technologies employ temporary, cache data storage to build for specific platforms and/or configurations. This data is derived from the actual project, and is not saved in the repo, but it often takes significant time to generate. For example, I work with Unity3d. Unity3d has a great graphics pipeline; if you release the same project for different platforms, you still have the original PSD textures in source control, and they are automatically exported to relevant graphic formats when you switch between different platforms. However, this generation takes a LONG time on different projects, and you usually have several copies of the project on your hard drive, each with a different platform selected. git even introduced a feature that is usable precisely for that scenario, worktree.

CSDude 11y ago

I would just love some IDE-debug love and better packaging. More packages I use and more I distribute my files, compilation takes considerably longer. Maybe I do not know, but is there some process to compile some parts before hand and link only the changed resulting binary?

nathany 11y ago

There is a Go AMA on reddit for the next 24 hours. https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_the_go_contributors_ask_us_anything/ https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_t...

lsllc 11y ago
OK Go are also doing a reddit AMA! https://www.reddit.com/r/IAmA/comments/46asrt/we_are_ok_go_were_here_to_talk_reddit_so_ask_us/ https://www.reddit.com/r/IAmA/comments/46asrt/we_are_ok_go_w...

deleted 11y ago

[deleted]

jonesb6 11y ago

The reason I love Go is that every time I pull it out, I write a small amount of it and it runs beautifully. For example my company has a critical micro-service implemented in ~300 lines of Go, it's been running for six months now without a single hiccup, highly performant, very sexy. The reason I will almost never use Go for web apps is because interaction with databases is limited (almost entirely) to raw queries. Maybe I'm spoiled by the likes of Active Record, Sequelize, Mini-mongo, Sql-alchemy, etc, but it's a huge drop in efficiency to spin my own SQL. The point to take away here is that Go, more so then many other languages IMO, has its strengths and weaknesses. If you use Go in one of it's weaker use-cases you're gonna have a bad time. If you use Go for one of it's strengths you're gonna have a great time. See you guys and gals in n weeks when we need to rehash the pros and cons of Golang again.

Cshelton 11y ago
Exactly. I love how every release of Go, or Rust, mainly those two, turns into so much rehashing...it hurts. Little discussion about the release changes happens...a simple google search will return all the discussions of pros and cons you would ever want to read in a life time...
no1youknowz 11y ago
> The reason I will almost never use Go for web apps is because interaction with databases is limited > but it's a huge drop in efficiency to spin my own SQL. Sorry, I have to disagree. I come from PHP, where when you sneeze an ORM appears. I actually am a DBA also. I am very familiar with SQL and I love writing out raw SQL. I don't see this as a limiting feature. It doesn't affect me at all. There are ORMs for Go as well. But I don't know how good they are. YMMV! Last point. I have shipped into production a web app using GIN framework. I ported from PHP to Go. I didn't feel I was losing anything. Go is amazing. It hasn't let me down yet. I doubt it will.
- xrstf 11y ago
  > I come from PHP, where when you sneeze an ORM appears. YMMD.
- 11y ago

eddiezane 11y ago

I've really enjoyed the time I've spent with Go but feel like the state of dependency management has kept me away. Am I being stubborn in my longing for an npm, Ruby Gems, or pip? Is there a reason why one of these hasn't emerged/been adopted by the community? (I'm aware of the 1.5 experiment with vendoring.) Semver and pinning versions has always just made sense to me. I can easily adopt new features and fixes automatically without worrying about things breaking. How does the community feel this far along?

kasey_junk 11y ago
Dependency management is a huge weakness in golang and there isn't much point in debating it. That said, my time in golang has crystalized something I'd been leaning towards anyway, that is dependencies are way more dangerous than we think they are. I find all of my code now (golang or otherwise) less likely to have dependencies, and therefore dependency management weaknesses are mitigated (not solved).
- majormjr 11y ago
  Agreed, Go's strong standard library also helps avoid dependencies.
munificent 11y ago
> Is there a reason why one of these hasn't emerged/been adopted by the community? Personally, I believe package management is one of those things that really does need an official blessed solution. Otherwise, you have a nasty bootstrapping problem: if there are ten competing package managers, how do you install them, and how do package developers know which one to put their packages in? Collection types have the same problem. You basically need to put some collections in a blessed core library, otherwise it's virtually impossible to reliably share code. Any function that wants to return a list ends up having to pick one of N list implementations and which ever one they pick means their library is hard for users of the other N-1 lists to consume. The Go team hasn't blessed a package manager, I think, because it's not that relevant to them: they mostly live within Google's own infrastructure which obviates the need for something like version management. They probably don't feel the pain acutely and/or might not have the expertise to design one that would work well outside Google.

helper 11y ago

Rebuilding our integration docker image right now. If all our tests pass I expect to have go 1.6 binaries in production by this evening.

Exuma 11y ago

I upgraded and it broke our app, something to do with the way it handles https has changed, not sure what

mholt 11y ago
What do your tests reveal?
in_me_i_trust 11y ago
yes, they've been asking people to test https for awhile as it now uses http/2
nathany 11y ago
If it works in Go 1.5.3 but not Go 1.6, definitely consider filing an issue. https://github.com/golang/go/blob/master/CONTRIBUTING.md https://github.com/golang/go/blob/master/CONTRIBUTING.md

obelisk_ 11y ago

Release notes: https://golang.org/doc/go1.6 https://golang.org/doc/go1.6 Mods, maybe change OP link to this?

enneff 11y ago
This is the better link target: https://blog.golang.org/go1.6 https://blog.golang.org/go1.6

bmh_ca 11y ago

Go has a lot going for it. That said, there were a few points I noted, based on a recent go I gave it (pardon the pun), at least in relation to my style of development for this project: 1. It's hard to tinker, mostly because it's fussy about what variables are defined or used. This is a strength in the usual course, but when one is trying to posit what a poorly documented 3rd party API is doing it can be a serious pain. By tinkering, I found that I often had to comment out or uncomment lines, or handle or ignore errors. There was a lot of flipping up to the beginning of the file. I would spend so much time fiddling with the lines that I would at times forget what I was even trying to do. I might just have memory problems, I acknowledge. :) However, what would make sense is a go "mode" where it runs in a non-strict way, with what would ordinarily be errors being warnings. A "tinker" or "whirl" mode, so to speak, that softened the requirements so one could get a better sense of what was happening before committing to a design. An interpreter mode might also be quite valuable, to address this problem and the ones below. 2. Error propagation - I see the point of errors being returned and the lack of a "throw/catch" style, and its benefit, but I feel it's a lot of typing for marginal gain. I usually end up with an error propagating a set of strings that ultimately conclude as: "Database error: transaction error: processing error: http error: reason", which is to say: equivalent but less information than a stack trace would give. I see the mandatory error acknowledgement simultaneously as a strength and a waste of time, and I admit being on the fence about it. 3. The next point I am not on the fence about: Debugging. It is not apparent how to get a stack trace, and the best option looks like including a third party application that generated errors. For the obvious and reasons below, this is a problem. 4. Package management: This was fussy and could be time-consuming. It is not apparent to me why one needs a GOROOT and a GOPATH. I think Python's virtualenv gets it right, by comparison. A second but related problem is package versions. Maybe I'm missing something, but making sure you get the latest semantically equivalent version (in the semver sense) was not apparent. 5. Package debugging: If you include a 3rd party package, and it's broken in any way, it's a veritable quagmire to identify and fix the problem. My experience was that the best way to debug a third party package was to block and copy all its bits and then debug it as a local source in your own. Obviously this is bad for a long number of reasons, and I might be missing something, but no more apparent option appeared when I investigated on how to tell what is even happening inside third packages. 6. Automated testing: I've not seen a test runner that reloads when source files change, particularly one that might be used with goapp from AppEngine, meaning go auto-testing can be quite a bit of patient thumb-twiddling as the binary reloads. Which is all to say that there are some concerns about developing a larger project in this language, particularly if there is quite a bit of complexity that needs lots of testing or potential debugging and/or inclusion of many third party packages. I've not reviewed the 1.6 notes, so perhaps these are addressed to some extent there. In any case, none of the issues above is insurmountable, and overall I give the Go design a lot of credit for experimentation and interesting choices, but the issues I've seen above give me pause before committing a team to the language – for the moment.

dh997 11y ago

Go CSP is minimal and ortongonal, I just wish it did three things: 0. could lto optimize or link against a shared library to reduce the titanic size of compiled programs and cut down on duplication of instruction. Therue is no practical sense in wasting memory and storage on systems with dynamic linkers: edge cases of including the world for rare situations but YAGNI in real production systems. 1. could output flat binaries and self-host runtime (panics) for practical kernel development in Go 2. Generics (both types and immutable constraints), I think C++1z has the right approach to this (and constexpr and constant arrays are nice and are able to provide more hints to the compiler). I also wonder why Go wasnt developed as an IR compiler / llvm frontend, because it would've levered an existing debug and portability ecosystem with much less work.

hacknat 11y ago
0. It does dynamic linking on most stdlibs (libc, etc) 1. What do you mean self-hosted runtime? Anyways, golang will likely never be a good candidate for kernel development, but in theory you could do it (go supports assembly) 2. Generics would be nice. Who knows, maybe they'll be in 2.0? Go wasn't developed in llvm, because they wanted to build something very fast, and they were planning on writing the compiler in golang from the start (so that it could be part of the libs). Also having your own scheduler kind of breaks debugging, you can build go programs with gccgo, but gdb doesn't work because it has no concept of what a "go routine" is. Delve (https://github.com/derekparker/delve https://github.com/derekparker/delve) will eventually fill the hole of the missing debugger, imo. Edit: Formatting
- aikah 11y ago
  > 2. Generics would be nice. Who knows, maybe they'll be in 2.0? There will be no 2.0 and there will be no generics, at all.In fact there will never be any changes to the type system, cause it's impossible at this point.
  - hacknat 11y ago
    Not that I even care that much, but that's total crap. Compile-time generics, which is what most people seem to be referring to when they say they want generics in Go, are eminently doable. It would not be hard to implement. Runtime generics are probably possible as well. What are you even basing your assertion on? Edit: What do you mean, "there will never be a 2.0"? Do you have a crystal ball?

ukd1 11y ago

https://golang.org/doc/go1.6 https://golang.org/doc/go1.6 - lists the changes

protomyth 11y ago

Can someone give a decent explanation of the following: 1) Supposed I have a library that was written in C that receives a security update which is used in a Go program. Under what conditions do I need to get a recompiled version of the Go program. 2) Supposed I have a library that was written in Go that receives a security update which is used in a Go program. Under what conditions do I need to get a recompiled version of the Go program. 3) Is there a way to tell from the binary that the program was written in Go? Trying to figure this out for my Sys Admin dealing with Vendors role.

skybrian 11y ago
Best to assume that you will need to recompile a Go program yourself. If you don't have the source and know how to build it, you're in trouble.
- protomyth 11y ago
  I am a bit worried about accepting software from vendors written in Go given those circumstances. For example, the recent OpenSSL patches would be an example. Are the Go programs fine if I update OpenSSL or did they include OpenSSL's libraries statically? If someone writes a Go replacement for OpenSSL does that change the scenario. Given a lot of software makes it to my door written by government contractors for grant management / compliance, I don't have the source code.
  - skybrian 11y ago
    Go has its own crypto library that's maintained by a real crypto expert so that might not be the best example. Still, if they do find a bug, there will be a new release of Go and you (or your supplier) should be prepared to recompile. Running unmaintainable, unfixable binaries may be standard practice in other places but for Go it's not really viable. It's a different culture with different practices.
    - protomyth 11y ago
      > Running unmaintainable, unfixable binaries may be standard practice in other places but for Go it's not really viable. It's a different culture with different practices. Well, since I cannot just patch a library, I am a lot more worried about the implications of Go programs being the "unmaintainable, unfixable binaries".

dominotw 11y ago

I've been writing some gocode recently and huge chunk of code is if err != nil ... I know you can do if ; err!=nil but that not that much better and you end up in deeply nested if blocks. i have to mentally block out err !=nil to read any gocode linearly. How is this acceptable, I don't get it. https://blog.golang.org/errors-are-values https://blog.golang.org/errors-are-values We recently scanned all the open source projects we could find and discovered that this snippet occurs only once per page or two This seems false from my experience, def way more than 1 or 2 instances per page.

sergiotapia 11y ago
I agree, it's exactly why I stopped using the language. err != nil checks all over the place gave me a headache. I since moved on to Elixir and it's really great. I just wish that it would allow me to have just a single deployable binary. That's something I really miss about Go.
- ocean3 11y ago
  exrm provides a deployable tar file. Granted its not single binary.
jimjimjim 11y ago
No point in raising an error if you aren't going to do something about it. If you don't care about an error then don't check it. If you do care then handle it. and you don't need massive if blocks, you can use more early returns as part of the err checks.
- dominotw 11y ago
  I don't exactly understand what you are suggesting. Ofcourse, I care about error and want them to be handled. Problem often is that method I am in doesn't know how to handle the error and have to bubble it up to a place where there is knowledge about how to handle it. Here is Erik Meijer talking about golang exception handling https://www.youtube.com/watch?v=a2ihmMmSfwk&t=577 https://www.youtube.com/watch?v=a2ihmMmSfwk&t=577 The golang guy doesn't answer the question properly and repeats "exceptions are not for control flow". Really disappointing answer and cringeworthy interview.

alblue 11y ago

Release notes are here: https://golang.org/doc/go1.6 https://golang.org/doc/go1.6 Notably new this time is transparent http/2 support and tighter rules for integration with C.

zenlikethat 11y ago

Congratulations to the Go team! There are many excellent folks working on the Go language and it's been an absolute joy to work with in my experience.

fuddle 11y ago

Go is great, but I wish they would add terany operator support.

oofabz 11y ago
They won't. The Go authors value simplicity. Many people dislike ternary syntax and find it hard to read. Go errs on the side of verbosity and readability. It is sort of the opposite of Perl in that respect.
- fuddle 11y ago
  Which is more simple, an if/else block or a terany operator? if/else: if i == 0 { return "foo" } else { return "bar" } terany: return i == 0 ? "foo" : "bar"

jay_kyburz 11y ago

Can anybody tell me if you can run Go in Chrome using the NaCL stuff? I remember there was talking of it a few years ago but I don't know if anything ever came of it. A google seach show that you could build for NaCal in Go 1.3 but only run it in special builds not Chrome itself.

iso-8859-1 11y ago
As you can see on https://github.com/golang/go/wiki/NativeClient https://github.com/golang/go/wiki/NativeClient , there is no PNaCl support, which means it is only available in the Chrome Web Store.
- jay_kyburz 11y ago
  Thanks for the heads up.

kiril-me 11y ago

Do you know any framework using http2 on go lang?

pori 11y ago

Seen a lot of Erlang mentions in this thread. Is that the native alternative to Go? Personally, I prefer to write code in a functional manner. While I've always thought Go looked like an amazing platform for programming in general, I haven't been keen on moving to another imperative language. It seems the landscape for functional alternatives are mainly Scala and Clojure which are both based on the JVM and require a bit of time to learn the tooling. I am not a Java or JVM export, so I haven't been too inspired by this either.

cies 11y ago
> It seems the landscape for functional alternatives are mainly Scala and Clojure Cannot talk about functional alternatives without mentioning Haskell. OCaml (when abstaining from the "O", as many OCaml'ers do; similarly Scala'ers often abstain from the "O" in Scala) is also an interesting option. Finally there's Rust, which is besides being a bit more functional also more low-level than Go. While being fairly young, Frege[1] also deserves a mention. Very similar to Haskell, but on the JVM. 1: https://github.com/Frege/frege https://github.com/Frege/frege
- pori 11y ago
  Well, I was tempted to mention Haskell. Problem is, I haven't found a practical use for it. Of all the FP languages, this is actually the one I am most tempted by. I had forgotten about Rust. Are there major projects being used for this yet? I've heard it's picking up quite a bit.
  - codygman 11y ago
    > Well, I was tempted to mention Haskell. Problem is, I haven't found a practical use for it. That's the same as saying: Well, I was tempted to mention Go. Problem is, I haven't found a practical use for it. That is to say, just pick a problem and try to use Haskell to solve it. 90% chance it will fit your niche fine.
  - steveklabnik 11y ago
    Depends on how you define "major". Dropbox is currently running Rust in production, at the core of their product. Has been for about six weeks now. That's probably the largest, most serious use. There are also tiny bits in Firefox, that will be included starting with the next release. There's a lot of other usage too, it all depends on how you define "major".

jernfrost 11y ago

Read the debate with Go vs Java here with interest. I'd like to add a point I think is missed by the Java crowd in favor of Go. Complexity isn't free. Java might have and abundance of tools, IDE's, language features etc, but you can't claim that matching up every Go feature or tool with something superior found among the huge Java universe makes Java superior in every way. I find that there is an unfair assumption being used by the Java advocates, here which is that every software developer has a deep knowledge of Java. As one of those people who can certainly write Java code, but who is not familiar with the Java eco system and has not spend a lot of time with I must say that Go to me is a clear winner. My exposure to professional Java development has been quite frustrating compared to writing Go code. Every Java project I have gotten has used some different built tool: Ant, Maven or Gradle. They have also all seem to use different IDE's. The complexity of each of these tools is staggering. Considerable time has to be spend learning these tools. Go in comparison is laughably simple. You can get productive in less than a week without ever having used the dam thing. The tools and the libraries are very quick to get into. In fact I find Go code so easy to read that although I am an iOS developer by trade, I frequently read Go code to understand how various algorithms and network stuff works. An organization would easily be able to add people to a Go project without much previous exposure to the language. Adding people with limited Java knowledge to a Java project however would be far more expensive. Considerable time would be needed for training. There is a lot of money to be saved from having a well thought out standard library combined with a simple language with simple well thought out tools. As a Swift/Objective-C developer, my major gripes with my development process is actually the complexity of the tooling. Both Swift and Objective-C are fairly straightforward languages IMHO. In this regard I greatly envy Go developers although I do enjoy the strong typing and generics in Swift.

kampsy 11y ago

I fell in love with python because it was clean and easy to work with. Like most developers, I used to use c when I needed a performance boast. Then I got fade up and decided to learn a new language that could give me the feel of python and the performance of c. Two languages from a list of 10 passed the above criteria Go and Rust. Java did not even make the list because I Don't use languages that are owned by evil empire's(Oracle). I went with Go because it was easy to use and understand. I could read other people's code easily( Even with a large code base, I have never found myself scratching my head trying to figure out my own code does), could set up my workspace in less than a minute and all the text editors I used (sublime, Atom, Vim) supported it. I Don't really care about the fancy IDE's. Just syntax highlighting and code completion is good for me. I started learning go on September 2015. And I have managed to implement the porter stemmer algorithm and an inverted index in it. Miss generics but LOVE interfaces. The fact that any concrete type that implements method 1 satisfies interface 8 is awesome. You can easily reuse code from different package without changing anything.

sriram_malhar 11y ago

Have been using Go since its release, and like the deployment experience, the feeling of solidity of putting together a tight system. The toolchain is great. 1.6 is yet another Solid release in that direction. Thank you all. However, the _language_ doesn't give me much programming pleasure alas. Since there is plenty of time for Christmas, here's my syntax wish list :) '?': C's if-then-else operator. Block-syntax for closures ala Ruby. Unifying blocks and closures makes creating DSLs easy, but doesn't add to cognitive load (no more than using anon funcs) Pattern matching like Scala, ML, Rust. Sum types -- (Yeah, I lied. Not just syntax enhancements), or at least discriminated unions. I'd like to see an example (in the FAQ entry on the topic) on why support for it is troublesome. For 2017 Christmas, ------------------- Macros ala Nim. Systemic support for Goroutines, including detection of conditions where a goroutine would never get scheduled. Erlang-like tools for built-in goroutine insight. ------ My ideal language would be an intersection of Nim+Go

sacado2 11y ago
Sum types don't play well with zeroed values by default. What is the zero value of a sum type ? Pattern matching doesn't work well without sum types. So don't hold your breath.

rphlx 11y ago

> Source trees that contain a directory named “vendor” that is not used in accordance with the new feature will require changes to avoid broken builds That seems a little bit distasteful.