13 ms·

Go 1.1 beta 1 Released

161 points by geetarista 14y ago

dvt 14y ago
I think this is an amazing milestone; I contributed to Go in the early phases and was very excited about the project. I even had Rob Pike OK some of my patches (which was a huge nerd ego boost, obviously). However, the direction the language took ended up being quite predictable and somewhat of a bore. The problem with Go is that it doesn't seem to fit any particular niche. Some other design decisions were questionable (no exception handling, for one). I kind of like Go, but I haven't used it for years. There's no real reason to NOT write something in C (or, rarely, C++) or Java, or if I need some serious scaling, Erlang (or just use either something like libevent for C or Kilim for Java). Go is very D-like. D, like Go, can't really find its niche. If Go or D were more idiomatic, perhaps they would be adopted in early programming classes (high schools and colleges -- like Python, for example), but even though goroutines, channels, and fast compilation are interesting concepts, they aren't really enough to detract from writing in the many other languages that do just about the same thing (and are a lot more popular).
- deleted 14y ago
  [deleted]
- afhof 14y ago
  I suspect that the kind of scaling Go was intended for was programming scale. A lot of the design of the language seems specific for large scale projects (statically compiling everything, not having unused variables, explicitly naming all imports, fast compiler, test and benchmarking as builtins, code changing via go fix). These are problems I have seen with larger java projects with unused imports, unused variables, library dependencies, long compile times, etc. I think that Go's niche is for extremely large projects, but it remains to be seen if it will work.
  - enneff 14y ago
    > I suspect that the kind of scaling Go was intended for was programming scale. Your suspicions are well-founded! http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article
  - taligent 14y ago
    IDEs have flagged and/or auto-corrected unused imports/variables for well over a decade now. And the issues with library dependencies/compile times generally only exist for large projects. And many frameworks e.g. Play don't have compile cycles. Personally I see Go being perfect for smaller web apps that would be super fast on an EC2 Micro. For the higher end apps the JVM is proven and far more flexible.
- enneff 14y ago
  Have you used it since 3 days after it was launched, more than three years ago? (That's when you contributed.) The language, libraries, and ecosystem are miles ahead of where they were back in 2009. Why not use C? Because C has no sensible packaging system, is unsafe, requires manual memory management, and offers a degree of control that is unnecessary for most tasks. Why not use Java? Because it is verbose and picky and basically forces you to use an IDE to get anything done, etc etc. If there were nothing wrong with these languages (they're the main ones we use at Google) we wouldn't have developed Go. Use Go more! You'll see why people love it, and why we created it.
  - dvt 14y ago
    To be fair, I haven't used it since 2011 and I'm sure a lot has changed. I've read plenty of valid criticisms however which (after having used it for several projects) deterred me from using it again. For a project a couple of years ago, I needed to use OpenCV and the Go bindings were quite immature. I just switched to C++ (for that project) and never really returned. But now that I think about it, whenever people that are interested in being introduced to coding (it happens a lot on campus) ask me "what language should I learn?" I've never answered Go. I'm not sure if most people would.
    - NateDad 14y ago
      While I don't think it's really a harsh criticism to say that Go shouldn't be your first language... I'd be interested to know what you think a good first language would be. Certainly not C or C++, if you're discounting Go. I'd also discount Java and C#, since they're syntactically quite similar to Go. Certainly not erlang. So... python? ruby? While I like those languages, I feel that the lack of a compiler is a pretty big hindrance to new programmers. Statically typed languages can catch many errors that produce some truly strange error messages in dynamic languages.
  - derefr 14y ago
    You addressed two of those questions, but what I really, really want to know is the answer to the third one. Why not use Erlang? It seems like the kind of thing Google would like, and yet I'm not familiar with any Google projects done in it.
- obilgic 14y ago
  Of course it has it's niche. It is fun, organized and simple to write like ruby, but It is a statically typed, compiled language. There you go.
- vladev 14y ago
  Honestly, I mostly share(d) your opinion, but am starting to see Go in a different light. The problem is that the community pitches it against C/C++, where Go, with its GC, just doesn't fit well, and Java, whose runtime and libraries is still miles ahead (fast GC, for one). However, Go seems to be very good at what Python/Ruby/Node.js/Perl are good at. It provides a simple, clean language with more guarantees and better runtime (mainly the cheap goroutines). I see Go taking some of their role for web development, simple tools (Go programs produce a single binary - very easy to distribute).
  - dvt 14y ago
    I think you may be right, and I completely understand the problematic benchmarks that always crop up. I don't pretend I'm smarter than the people at Google (because I'm not), but some questionable decisions were made (there's plenty of literature out there written by reputable people) -- and I think that's why Go hasn't seen more of the lime light. Apart from Google (who uses it for Youtube), Go hasn't really been used in large projects. Maybe 1.1 will change that. I might give it another shot, too!
    - mseepgood 14y ago
      > Apart from Google (who uses it for Youtube), Go hasn't really been used in large projects. I don't know how large each of these projects is, but a growing number of companies are using it for serious projects: Iron.io: How We Went from 30 Servers to 2 with Go http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2-go.html http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2... Behind the Scenes: Big Data at Torbit http://torbit.com/blog/2013/02/19/big-data-at-torbit/ http://torbit.com/blog/2013/02/19/big-data-at-torbit/ pool.ntp.org DNS server in Go http://news.ntppool.org/2012/10/new-dns-server.html http://news.ntppool.org/2012/10/new-dns-server.html Juju at Canonical http://www.reddit.com/r/programming/comments/18atce/juju_canonical_109k_lines_of_go_code/ http://www.reddit.com/r/programming/comments/18atce/juju_can... Go at bitly http://word.bitly.com/post/29550171827/go-go-gadget http://word.bitly.com/post/29550171827/go-go-gadget CloudFlare blows hole in laws of Web physics with Go and Railgun http://arstechnica.com/information-technology/2013/02/cloudflare-blows-hole-in-laws-of-web-physics-with-go-and-railgun/ http://arstechnica.com/information-technology/2013/02/cloudf... dl.google.com now served by Go https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/BNUNbKSypE0 https://groups.google.com/forum/?fromgroups=#!topic/golang-n... Go At Conformal https://www.cyphertite.com/blog.php?/archives/7-Go-at-Conformal..html https://www.cyphertite.com/blog.php?/archives/7-Go-at-Confor... Go at Novartis https://plus.google.com/114945221884326152379/posts/d1SVaqkRyTL https://plus.google.com/114945221884326152379/posts/d1SVaqkR... Go at the BBC http://www.quora.com/Go-programming-language/Is-Google-Go-ready-for-production-use/answer/Kunal-Anand http://www.quora.com/Go-programming-language/Is-Google-Go-re... Go at SoundCloud http://backstage.soundcloud.com/2012/07/go-at-soundcloud/ http://backstage.soundcloud.com/2012/07/go-at-soundcloud/ Go at CloudFlare http://blog.cloudflare.com/go-at-cloudflare http://blog.cloudflare.com/go-at-cloudflare Go at Heroku http://blog.golang.org/2011/04/go-at-heroku.html http://blog.golang.org/2011/04/go-at-heroku.html Building StatHat with Go http://blog.golang.org/2011/12/building-stathat-with-go.html http://blog.golang.org/2011/12/building-stathat-with-go.html
- mseepgood 14y ago
  > Go is very D-like. I think it's very D-unlike. It's very small and simple.
- drivebyacct2 14y ago
  I can't really agree with a single word of this and I've been writing Go weekly for 8 months.
- VeejayRampay 14y ago
  Has a claim as coarse-grained as "There's no real reason to not write something in C" ever made any sense past the immediate attention-bait value? I mean, different languages have different use cases and you can't pretend to make a case for a language on your own perception of it, let's be serious a second.
- smegel 14y ago
  Of all the languages you compared to Go, only 1 has native green threads: erlang. So why didnt google just use erlang? Well Go solves lots of problems that erlang doesnt, and maybe they also didn't want an interpreted functional language with no variables.
- pkolaczk 14y ago
  I agree Go and D really can't find its niche. They both are very interesting languages, but is there any really impressive application where those languages would rock? Something that when asked for, the only obvious answer would be "use Go"? Being a better C or a better C++ is IMHO not enough. Want high performance and full control? Use C (or C++). Want your code to be easy to maintain by an average Joe? Use Java or C#. Want your code to be concise? Use Clojure. Want extreme typesafety? Use Haskell. Need to use both OOP and FP? Use Scala. What question to ask so the obvious answer would be "Use Go?"
  - kyrias 14y ago
    "easy to maintain by an average Joe" and "Java" don't belong together
    - coldtea 14y ago
      Seen any other language used and maintained by more average Joes? Because that's exactly one of the niches of Java -- enterprise programming by average Joes. It was even a stated design goal of the language back in the day.
  - pjmlp 14y ago
    Go is C programming for the average Joe.
    - polshaw 14y ago
      I kind of agree with you (being an 'average Joe'?), but surely Go offers some advantages over C even for a C programmer; faster to write and compile, more readable code, concurrency, memory safety.
      - pjmlp 14y ago
        Except those advantages were already possible back in 1978 with Modula-2, nothing new.
- trailfox 14y ago
  Lack of exception handling is the biggest reason I haven't used Go for much. The other reasons are that it's just so plain/boring (yes, I know that's subjective), nothing about the syntax is interesting. Learning go is like eating cardboard. The other issues are that IDE support is very primitive and that Java and Scala are both faster and better supported in terms of tooling. Go seems rather nice, just very boring and not very compelling vs. many other tools.
  - EdiX 14y ago
    > Lack of exception handling is the biggest reason I haven't used Go for much. Go does exception handling with panic, recover and its reflection syntax.
    - trailfox 14y ago
      So if I'm reading from a file I should use panic recover and not return code checking?? That's not what I've seen in the docs.
      - jlgreco 14y ago
        You seem to be missing the difference between "can you do it" and "should you do it". The reason that you should not is because doing so is not idiomatic Go. You are completely able to do so though.
    - NateDad 14y ago
      Using panic and recover is strongly discouraged, and in the rare cases where it makes the code significantly simpler, panics should never cross package boundaries (which is to say, you should never have a public API that can panic, unless you fully expect the panic to take down the process).
      - EdiX 14y ago
        Using panics for control flow or having panics cross library boundaries is strongly discouraged, otherwise they are fine. Go's own standard library uses them internally in several places. Even then discouraging panics is very different from not having them.
phasevar 14y ago
Exciting stuff! Can't wait to see Go 1.1 in the benchmark games.
- trailfox 14y ago
  I'm interested to see if it is still going to be clobbered by Java and Scala the way Go 1 was.
  - trailfox 14y ago
    Curious downvote for a factually accurate post... source: http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?test=all&lang=go&lang2=java http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t...
    - Intermernet 14y ago
      Probably downvoted for not providing a link to the benchmarks that show Java and Scala out-performing Go 1.0? I know of Collin VanDyck's web service showdown (http://boundary.com/blog/2012/09/17/comparing-go-and-java-part-2-performance/ http://boundary.com/blog/2012/09/17/comparing-go-and-java-pa...) which showed that Java had lower latency and higher throughput for highly concurrent tasks based on a very simple code base, but net/http performance in Go 1.0 wasn't a high priority. It seems that it has since been bumped up the priority list and a lot of work has been going on (https://groups.google.com/d/topic/golang-nuts/zeLMYnjO_JA/discussion https://groups.google.com/d/topic/golang-nuts/zeLMYnjO_JA/di...). The thing is, Go isn't just for writing web apps. If you have a look at some of the real world use cases for Go (there's a list in another comment here somewhere) you'll notice that these aren't just web apps. Every bit of Go code I've written (web app, mp3 database generator, encryption library) has been blisteringly fast, and it seems Go 1.1 will bring substantial performance improvements again. Oh, and I didn't down-vote you, I don't yet have that privilege.
      - trailfox 14y ago
        Thanks, I've added the link now.
VeejayRampay 14y ago
Great stuff, looking forward to the final release, thanks to the Golang developers for all the hard work.
deleted 14y ago
[deleted]
- guywithabike 14y ago
  Nope. This is the announcement that Go 1.1 has reached beta status.
- enneff 14y ago
  That's the go1 changelog. There's nothing about Go 1.1 in there.
  - mitchi 14y ago
    Oops, wrong copy paste!
frou_dh 14y ago
The changes concerning function returning[0] are really welcome. The merits of implicit vs. explicit else blocks were debated, but I think everyone should be glad to get rid of forced panic("unreachable"). [0] http://tip.golang.org/doc/go1.1#return http://tip.golang.org/doc/go1.1#return
creativityland 14y ago
https://news.ycombinator.com/item?id=5489054 https://news.ycombinator.com/item?id=5489054
- dualogy 14y ago
  Unrelated (Google's Webkit fork -- zilch to do with Go 1.1 beta)
eridius 14y ago
Very cool. I don't see a tip in the hg repo for go1.1beta1. Anyone know what the right revision is? I'd rather install the known beta source than whatever's at the tip.
- enneff 14y ago
  The beta isn't tagged. As mentioned in the article, beta1 is cut from revision 267bb9854177. But as only fixes will be submitted between now and the 1.1 release, it's definitely better to use tip.
  - eridius 14y ago
    Ah you're right, I missed seeing the 267bb9854177 in the mail. But I guess I'll use tip if that's better. Thanks.
glitch273 14y ago
Is there a decent web framework using Go can that be competitive to Rails or Django someday?
- dualogy 14y ago
  http://robfig.github.com/revel http://robfig.github.com/revel is at least aiming for that. Can't vouch for or against it (yet) though. Gorilla toolkit is also very neat, but it's a handy tool-box for web work, rather than a kitchen-sink framework.
- buro9 14y ago
  There's enough built into Go that frameworks feel very unnecessary. The only thing I'd strongly recommend is Gorilla Mux: http://www.gorillatoolkit.org/pkg/mux http://www.gorillatoolkit.org/pkg/mux And you can get an idea of how people build websites using Mux and Go by looking on github: https://github.com/jimmykuu/gopher https://github.com/jimmykuu/gopher If you're very new to Go, then reading that last link repo you probably want to read these files in this order: https://github.com/jimmykuu/gopher/blob/master/src/server/main.go https://github.com/jimmykuu/gopher/blob/master/src/server/ma... https://github.com/jimmykuu/gopher/blob/master/src/gopher/server.go https://github.com/jimmykuu/gopher/blob/master/src/gopher/se... https://github.com/jimmykuu/gopher/blob/master/src/gopher/urls.go https://github.com/jimmykuu/gopher/blob/master/src/gopher/ur... and then to take a look at the files in this folder for the handlers and html/template calling: https://github.com/jimmykuu/gopher/tree/master/src/gopher https://github.com/jimmykuu/gopher/tree/master/src/gopher
  - stock_toaster 14y ago
    Second the Gorilla recommendation. Great toolkit.
  - swah 14y ago
    In older versions there seemed to be a websocket package, but I can't find it anymore - do you know what hapenned to it?
    - 14y ago
LAMike 14y ago
What makes Go so cool?
- frou_dh 14y ago
  It: is small, is natively compiled, has great tools, has a great stdlib, is concurrent, is parallel, is gc'd ... and has well implemented features including closures, channels and structural static typing.
- pjmlp 14y ago
  It is made by Google.
  - coldtea 14y ago
    Kind of like Google Wave was cool then?
    - pjmlp 14y ago
      Yes, still waiting to see if it will follow Reader and Wave's fate.
      - enneff 14y ago
        A nonsense comment. Go is an 100% open source project.
        pjmlp 14y ago
        Lets see how far it goes if Google stops giving money to the core team.
        NateDad 14y ago
        1. Google isn't going to stop giving them money, as Go solves a ton of Google's problems with C++. 2. There are over 300 non-google contributors already http://golang.org/CONTRIBUTORS http://golang.org/CONTRIBUTORS
eridius 14y ago
The new data race detector looks great. I have a script I run daily that panics maybe once a month. I've never been able to figure out where the problem is. One run after building with -race and I now have a juicy data race report. Awesome!
- eridius 14y ago
  Turns out exec runs two goroutines, one for Stdout and one for Stderr, and if I run both into the same bytes.Buffer, that's a data race. No wonder I couldn't find it, I was looking in my own code for the goroutines. Thanks go1.1beta1!
pjmlp 14y ago
Still no generics :(
- dsymonds 14y ago
  You aren't going to see any radical changes to the language in the 1.x series.
  - vanderZwan 14y ago
    To explain that a bit further: the core Go team is not against generics by definition, they just believe that no generics is better than bad generics (where "bad" admittedly is subjective, but see Russ Cox' article on the topic[1]). If/when they find a solution that fits their strict criteria, it in all likelihood will require breaking changes to the Go language, and the point of having the 1.x series was a promise that this would not happen. [1] http://research.swtch.com/generic http://research.swtch.com/generic
    - happy_dino 14y ago
      I'm wondering how long it will take until people will either stop linking to blatantly false articles or start reading more than the first 5 paragraphs of it.
      - vanderZwan 14y ago
        Apologies, I quickly Googled and pasted the link like you implied I did. I remember a longer, more deeply reasoned article than this one, and by quickly skimming I mistook this for that - it probably was somewhere on the go-nuts mailing list. The problem is that the topic of generics has come up so many times on that mailing list it will require quite a bit of digging to find that again. That said, the discussion below the article does get across the standpoint of the Go developers on the topic, doesn't it?
        happy_dino 14y ago
knotty66 14y ago
FWIW, I benchmarked a basic Revel web app. Go 1.0.3 = 2850 req/sec ... 1.1 = 10928 req/sec.
- conroy 14y ago
  Any chance you can post the code you used to benchmark? That's an insane difference.
  - knotty66 14y ago
    It was a basic newly generated Revel app running in production mode. Not hitting a DB. Benchmarked with 'ab -n 10000 -c 30 http://localhost:9000/some_action http://localhost:9000/some_action. See also: https://github.com/davecheney/autobench https://github.com/davecheney/autobench BenchmarkHTTPClientServer 373216, 52646 -85.89%
    - errnoh 14y ago
      bench old_ns/op new_ns/op delta "BenchmarkHTTPClientServer 373216, 52646 -85.89%" That bench is 7 times faster in Go 1.1 than 1.0.3.
      - knotty66 14y ago
        Uh? They are two separate benchmarks, that's why I said 'See also'.
        deleted 14y ago
        [deleted]
        knotty66 14y ago
        The sources don't contradict each other? 1.1 is several times faster then 1.03 in both benchmarks.
        kyrias 14y ago
groundCode 14y ago
Kudos to the team. Go is going from strength to strength. I'm about to start a small project with it.
AcessoNegado 14y ago
I think this is really the one language/tech that's going to take off. It's just too early, but it's going to make it's splash.
chmike 14y ago
I'm a C++ and python programmer with some basic experience in JavaScript. I started learning Go, as I looked into D some years ago, an was a bit puzzled by some design choices. I don't understand the need to enforce the use of { } and that the if of for line must end with a {. I don't like this writing. My preferred syntax is the one of Pythons, which is the most concise and clear. It seem Go could have used : and indentation as in python instead of { }. Another puzzling choice of Go is slicing which differ from Python's and D's. In Go slicing is limited by the capacity and not by the number of items it contains. Returning 0 as default value looks to me like an open door to silent bugs. The way Go handles errors looks original and interesting, but I'm lacking experience to determine how it compares to exceptions from the usage perspective. From what I saw, I would say that Go is a better C and D is a better C++ where better means also closer. As a consequence Go seams simpler than D to learn and use. Thus I expect we will see much more Go programmers than D programmers in the future. Simplicity has been proven many times to be trump.
- mseepgood 14y ago
  > I don't understand the need to enforce the use of { } and that the if of for line must end with a {. I don't like this writing. My preferred syntax is the one of Pythons, which is the most concise and clear. This article explains the reasoning behind lots of Go's design choices: http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article "Some observers objected to Go's C-like block structure with braces, preferring the use of spaces for indentation, in the style of Python or Haskell. However, we have had extensive experience tracking down build and test failures caused by cross-language builds where a Python snippet embedded in another language, for instance through a SWIG invocation, is subtly and invisibly broken by a change in the indentation of the surrounding code. Our position is therefore that, although spaces for indentation is nice for small programs, it doesn't scale well, and the bigger and more heterogeneous the code base, the more trouble it can cause. It is better to forgo convenience for safety and dependability, so Go has brace-bounded blocks."
  - ma2rten 14y ago
    My personal opinion on the subject is that you should not obsess about those things. It is good that Go that enforces one consistent style. In practice it does not really matter for your productivity what that style is. That said, I don't consider this a convincing argument. They basically say "We had some problems in the past with embedding Python code in Java files". This is a very specific problem and I could think of at least 4 different specific solutions for this specific problem. I don't think this arguement can support very broad conclusions like "Spaces for indentation does not scale to big and heterogeneous code bases and compromises safety and dependability for convenience".
g3orge 14y ago
I get a 404 at the changelog link they provide...
- mahmoudhossam 14y ago
  The correct link is in the first reply on Google groups.
yason 14y ago
What's the standard graphics library for Go That Just Works(tm) ? I'm looking for something for Go like PyGame is for Python. I like to get surfaces rendered on my screen in pretty much no time as I like to learn a language by doing simple graphical demos and experiment from there. There are few SDL bindings for Go but none of them worked. One of them did work to some extent after a lot of tweaking without the help of many examples. I quit learning after I realized I'd have to learn more how the graphics bindings were written than how to program in Go.
- easytiger 14y ago
  building a "standard graphics library" into a language that is not part of a write once run anywhere managed environment is a terrible idea and has never worked. On the other hand a more solid native 2d drawing library like java2d would be more welcome. Weekend project #34532
  - deleted 14y ago
    [deleted]
    - easytiger 14y ago
      > "write once run anywhere managed environment" that is not even remotely what that is. A sufficiently advanced graphics library will do considerable amounts of non trivial interaction with system dependent and even hardware dependent libraries. The parent cited SDL. Which sits atop other libraries. Which imposes certain runtime constraints.
      - laumars 14y ago
        You're now talking specifically about SDL, where as I was commenting about your generalisation about Go as a language (which was the context of your previous comment). I'd already said Go lacks any kind of standard graphics library and never tried to argue otherwise. But the standard packages that are included with Go's SDK are cross platform. I can (and frequently do) write Go applications using just the standard libraries that I then run on different platforms (both in terms of OS and CPU architecture) without any code changes what-so-ever. Anyhow, even that being my point, I don't agree with it myself. Thinking properly about it, Go's base packages are little more equivalent to ANSI C than JRE; Go isn't managed and thus base packages are really just a set of standard libraries rather than a runtime environment.
truebosko 14y ago
For someone who wants to spend a week hacking on a project in Go, what kind of project do you recommend?
- burntsushi 14y ago
  The only real way to get hobby projects is to find a problem you've been having and solve it. So what are your problems? :-) Here are some of mine, that I turned into Go code: (restricted to "week long hacking" or less) A simple blog application. A command that when run, sends the output of other commands to your email. An image viewer. A simpler interface to `xrandr`. A parser for the new TOML configuration format. Or, you could pick a small program that you wrote in another language and port it.
derengel 14y ago
Is Go a good choice to create a CRUD web app? between the stdlib, gorilla toolking and the pg driver seems it wouldn't be so much of a pain, but the pg driver doesn't look ready for production use. https://github.com/bmizerany/pq https://github.com/bmizerany/pq
- jbooth 14y ago
  For just plain CRUD, you'll probably get where you want to go faster with Django or Ruby -- they get you up and running faster, and their template engines are more mature than anything in Go. Once you're beyond just plain CRUD to the point where the language you're using matters more than how fast you can get going with defaults, then you might like Go more (or less) than Ruby/Python.
- chimeracoder 14y ago
  I wrote the outline of one[0] a while back with gorilla and it wasn't too difficult. Be warned that some of the code is less-than-idiomatic, since I began it while I was still learning Go. There's definitely some refactoring that can be done, etc. However, as you can see, it's not too difficult to write a basic CRUD app with authentication, even if you're starting completely from scratch (which you don't have to; I did it more as a learning exercise). I disagree with jbooth; I find Go's templating language to be incredibly mature, and I also find it much easier to develop with gorilla than something like Flask, if for no other reason than the static compilation and incredibly thorough code analysis/other checking done at compile-time (unused lvalues, etc.) [0] https://github.com/chimeracoder/go-server-bootstrap https://github.com/chimeracoder/go-server-bootstrap
waterside81 14y ago
I've been using Python almost exclusively since 2004. Go is the first language that has made me want to switch. I can't put my finger on it, but it's fun to work with. Actually, I'll try to put my finger on it: 1) Fast build times 2) Goroutines. If you've tried using any async library in Python or are waiting for Tulip to come into mainline Python around v3.4 - stop wasting your time. Goroutines along with channels just works (TM) and is unbelievably easy to use. No callbacks, no threadpools, no having to CTRL-C your way out of a bug. It's a pleasure to work with.

161 points by geetarista 14y ago

dvt 14y ago

I think this is an amazing milestone; I contributed to Go in the early phases and was very excited about the project. I even had Rob Pike OK some of my patches (which was a huge nerd ego boost, obviously). However, the direction the language took ended up being quite predictable and somewhat of a bore. The problem with Go is that it doesn't seem to fit any particular niche. Some other design decisions were questionable (no exception handling, for one). I kind of like Go, but I haven't used it for years. There's no real reason to NOT write something in C (or, rarely, C++) or Java, or if I need some serious scaling, Erlang (or just use either something like libevent for C or Kilim for Java). Go is very D-like. D, like Go, can't really find its niche. If Go or D were more idiomatic, perhaps they would be adopted in early programming classes (high schools and colleges -- like Python, for example), but even though goroutines, channels, and fast compilation are interesting concepts, they aren't really enough to detract from writing in the many other languages that do just about the same thing (and are a lot more popular).

deleted 14y ago
[deleted]
afhof 14y ago
I suspect that the kind of scaling Go was intended for was programming scale. A lot of the design of the language seems specific for large scale projects (statically compiling everything, not having unused variables, explicitly naming all imports, fast compiler, test and benchmarking as builtins, code changing via go fix). These are problems I have seen with larger java projects with unused imports, unused variables, library dependencies, long compile times, etc. I think that Go's niche is for extremely large projects, but it remains to be seen if it will work.
- enneff 14y ago
  > I suspect that the kind of scaling Go was intended for was programming scale. Your suspicions are well-founded! http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article
- taligent 14y ago
  IDEs have flagged and/or auto-corrected unused imports/variables for well over a decade now. And the issues with library dependencies/compile times generally only exist for large projects. And many frameworks e.g. Play don't have compile cycles. Personally I see Go being perfect for smaller web apps that would be super fast on an EC2 Micro. For the higher end apps the JVM is proven and far more flexible.
enneff 14y ago
Have you used it since 3 days after it was launched, more than three years ago? (That's when you contributed.) The language, libraries, and ecosystem are miles ahead of where they were back in 2009. Why not use C? Because C has no sensible packaging system, is unsafe, requires manual memory management, and offers a degree of control that is unnecessary for most tasks. Why not use Java? Because it is verbose and picky and basically forces you to use an IDE to get anything done, etc etc. If there were nothing wrong with these languages (they're the main ones we use at Google) we wouldn't have developed Go. Use Go more! You'll see why people love it, and why we created it.
- dvt 14y ago
  To be fair, I haven't used it since 2011 and I'm sure a lot has changed. I've read plenty of valid criticisms however which (after having used it for several projects) deterred me from using it again. For a project a couple of years ago, I needed to use OpenCV and the Go bindings were quite immature. I just switched to C++ (for that project) and never really returned. But now that I think about it, whenever people that are interested in being introduced to coding (it happens a lot on campus) ask me "what language should I learn?" I've never answered Go. I'm not sure if most people would.
  - NateDad 14y ago
    While I don't think it's really a harsh criticism to say that Go shouldn't be your first language... I'd be interested to know what you think a good first language would be. Certainly not C or C++, if you're discounting Go. I'd also discount Java and C#, since they're syntactically quite similar to Go. Certainly not erlang. So... python? ruby? While I like those languages, I feel that the lack of a compiler is a pretty big hindrance to new programmers. Statically typed languages can catch many errors that produce some truly strange error messages in dynamic languages.
- derefr 14y ago
  You addressed two of those questions, but what I really, really want to know is the answer to the third one. Why not use Erlang? It seems like the kind of thing Google would like, and yet I'm not familiar with any Google projects done in it.
obilgic 14y ago
Of course it has it's niche. It is fun, organized and simple to write like ruby, but It is a statically typed, compiled language. There you go.
vladev 14y ago
Honestly, I mostly share(d) your opinion, but am starting to see Go in a different light. The problem is that the community pitches it against C/C++, where Go, with its GC, just doesn't fit well, and Java, whose runtime and libraries is still miles ahead (fast GC, for one). However, Go seems to be very good at what Python/Ruby/Node.js/Perl are good at. It provides a simple, clean language with more guarantees and better runtime (mainly the cheap goroutines). I see Go taking some of their role for web development, simple tools (Go programs produce a single binary - very easy to distribute).
- dvt 14y ago
  I think you may be right, and I completely understand the problematic benchmarks that always crop up. I don't pretend I'm smarter than the people at Google (because I'm not), but some questionable decisions were made (there's plenty of literature out there written by reputable people) -- and I think that's why Go hasn't seen more of the lime light. Apart from Google (who uses it for Youtube), Go hasn't really been used in large projects. Maybe 1.1 will change that. I might give it another shot, too!
  - mseepgood 14y ago
    > Apart from Google (who uses it for Youtube), Go hasn't really been used in large projects. I don't know how large each of these projects is, but a growing number of companies are using it for serious projects: Iron.io: How We Went from 30 Servers to 2 with Go http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2-go.html http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2... Behind the Scenes: Big Data at Torbit http://torbit.com/blog/2013/02/19/big-data-at-torbit/ http://torbit.com/blog/2013/02/19/big-data-at-torbit/ pool.ntp.org DNS server in Go http://news.ntppool.org/2012/10/new-dns-server.html http://news.ntppool.org/2012/10/new-dns-server.html Juju at Canonical http://www.reddit.com/r/programming/comments/18atce/juju_canonical_109k_lines_of_go_code/ http://www.reddit.com/r/programming/comments/18atce/juju_can... Go at bitly http://word.bitly.com/post/29550171827/go-go-gadget http://word.bitly.com/post/29550171827/go-go-gadget CloudFlare blows hole in laws of Web physics with Go and Railgun http://arstechnica.com/information-technology/2013/02/cloudflare-blows-hole-in-laws-of-web-physics-with-go-and-railgun/ http://arstechnica.com/information-technology/2013/02/cloudf... dl.google.com now served by Go https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/BNUNbKSypE0 https://groups.google.com/forum/?fromgroups=#!topic/golang-n... Go At Conformal https://www.cyphertite.com/blog.php?/archives/7-Go-at-Conformal..html https://www.cyphertite.com/blog.php?/archives/7-Go-at-Confor... Go at Novartis https://plus.google.com/114945221884326152379/posts/d1SVaqkRyTL https://plus.google.com/114945221884326152379/posts/d1SVaqkR... Go at the BBC http://www.quora.com/Go-programming-language/Is-Google-Go-ready-for-production-use/answer/Kunal-Anand http://www.quora.com/Go-programming-language/Is-Google-Go-re... Go at SoundCloud http://backstage.soundcloud.com/2012/07/go-at-soundcloud/ http://backstage.soundcloud.com/2012/07/go-at-soundcloud/ Go at CloudFlare http://blog.cloudflare.com/go-at-cloudflare http://blog.cloudflare.com/go-at-cloudflare Go at Heroku http://blog.golang.org/2011/04/go-at-heroku.html http://blog.golang.org/2011/04/go-at-heroku.html Building StatHat with Go http://blog.golang.org/2011/12/building-stathat-with-go.html http://blog.golang.org/2011/12/building-stathat-with-go.html
mseepgood 14y ago
> Go is very D-like. I think it's very D-unlike. It's very small and simple.
drivebyacct2 14y ago
I can't really agree with a single word of this and I've been writing Go weekly for 8 months.
VeejayRampay 14y ago
Has a claim as coarse-grained as "There's no real reason to not write something in C" ever made any sense past the immediate attention-bait value? I mean, different languages have different use cases and you can't pretend to make a case for a language on your own perception of it, let's be serious a second.
smegel 14y ago
Of all the languages you compared to Go, only 1 has native green threads: erlang. So why didnt google just use erlang? Well Go solves lots of problems that erlang doesnt, and maybe they also didn't want an interpreted functional language with no variables.
pkolaczk 14y ago
I agree Go and D really can't find its niche. They both are very interesting languages, but is there any really impressive application where those languages would rock? Something that when asked for, the only obvious answer would be "use Go"? Being a better C or a better C++ is IMHO not enough. Want high performance and full control? Use C (or C++). Want your code to be easy to maintain by an average Joe? Use Java or C#. Want your code to be concise? Use Clojure. Want extreme typesafety? Use Haskell. Need to use both OOP and FP? Use Scala. What question to ask so the obvious answer would be "Use Go?"
- kyrias 14y ago
  "easy to maintain by an average Joe" and "Java" don't belong together
  - coldtea 14y ago
    Seen any other language used and maintained by more average Joes? Because that's exactly one of the niches of Java -- enterprise programming by average Joes. It was even a stated design goal of the language back in the day.
- pjmlp 14y ago
  Go is C programming for the average Joe.
  - polshaw 14y ago
    I kind of agree with you (being an 'average Joe'?), but surely Go offers some advantages over C even for a C programmer; faster to write and compile, more readable code, concurrency, memory safety.
    - pjmlp 14y ago
      Except those advantages were already possible back in 1978 with Modula-2, nothing new.
trailfox 14y ago
Lack of exception handling is the biggest reason I haven't used Go for much. The other reasons are that it's just so plain/boring (yes, I know that's subjective), nothing about the syntax is interesting. Learning go is like eating cardboard. The other issues are that IDE support is very primitive and that Java and Scala are both faster and better supported in terms of tooling. Go seems rather nice, just very boring and not very compelling vs. many other tools.
- EdiX 14y ago
  > Lack of exception handling is the biggest reason I haven't used Go for much. Go does exception handling with panic, recover and its reflection syntax.
  - trailfox 14y ago
    So if I'm reading from a file I should use panic recover and not return code checking?? That's not what I've seen in the docs.
    - jlgreco 14y ago
      You seem to be missing the difference between "can you do it" and "should you do it". The reason that you should not is because doing so is not idiomatic Go. You are completely able to do so though.
  - NateDad 14y ago
    Using panic and recover is strongly discouraged, and in the rare cases where it makes the code significantly simpler, panics should never cross package boundaries (which is to say, you should never have a public API that can panic, unless you fully expect the panic to take down the process).
    - EdiX 14y ago
      Using panics for control flow or having panics cross library boundaries is strongly discouraged, otherwise they are fine. Go's own standard library uses them internally in several places. Even then discouraging panics is very different from not having them.

phasevar 14y ago

Exciting stuff! Can't wait to see Go 1.1 in the benchmark games.

trailfox 14y ago
I'm interested to see if it is still going to be clobbered by Java and Scala the way Go 1 was.
- trailfox 14y ago
  Curious downvote for a factually accurate post... source: http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?test=all&lang=go&lang2=java http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t...
  - Intermernet 14y ago
    Probably downvoted for not providing a link to the benchmarks that show Java and Scala out-performing Go 1.0? I know of Collin VanDyck's web service showdown (http://boundary.com/blog/2012/09/17/comparing-go-and-java-part-2-performance/ http://boundary.com/blog/2012/09/17/comparing-go-and-java-pa...) which showed that Java had lower latency and higher throughput for highly concurrent tasks based on a very simple code base, but net/http performance in Go 1.0 wasn't a high priority. It seems that it has since been bumped up the priority list and a lot of work has been going on (https://groups.google.com/d/topic/golang-nuts/zeLMYnjO_JA/discussion https://groups.google.com/d/topic/golang-nuts/zeLMYnjO_JA/di...). The thing is, Go isn't just for writing web apps. If you have a look at some of the real world use cases for Go (there's a list in another comment here somewhere) you'll notice that these aren't just web apps. Every bit of Go code I've written (web app, mp3 database generator, encryption library) has been blisteringly fast, and it seems Go 1.1 will bring substantial performance improvements again. Oh, and I didn't down-vote you, I don't yet have that privilege.
    - trailfox 14y ago
      Thanks, I've added the link now.

VeejayRampay 14y ago

Great stuff, looking forward to the final release, thanks to the Golang developers for all the hard work.

deleted 14y ago

[deleted]

guywithabike 14y ago
Nope. This is the announcement that Go 1.1 has reached beta status.
enneff 14y ago
That's the go1 changelog. There's nothing about Go 1.1 in there.
- mitchi 14y ago
  Oops, wrong copy paste!

frou_dh 14y ago

The changes concerning function returning[0] are really welcome. The merits of implicit vs. explicit else blocks were debated, but I think everyone should be glad to get rid of forced panic("unreachable"). [0] http://tip.golang.org/doc/go1.1#return http://tip.golang.org/doc/go1.1#return

creativityland 14y ago

https://news.ycombinator.com/item?id=5489054 https://news.ycombinator.com/item?id=5489054

dualogy 14y ago
Unrelated (Google's Webkit fork -- zilch to do with Go 1.1 beta)

eridius 14y ago

Very cool. I don't see a tip in the hg repo for go1.1beta1. Anyone know what the right revision is? I'd rather install the known beta source than whatever's at the tip.

enneff 14y ago
The beta isn't tagged. As mentioned in the article, beta1 is cut from revision 267bb9854177. But as only fixes will be submitted between now and the 1.1 release, it's definitely better to use tip.
- eridius 14y ago
  Ah you're right, I missed seeing the 267bb9854177 in the mail. But I guess I'll use tip if that's better. Thanks.

glitch273 14y ago

Is there a decent web framework using Go can that be competitive to Rails or Django someday?

dualogy 14y ago
http://robfig.github.com/revel http://robfig.github.com/revel is at least aiming for that. Can't vouch for or against it (yet) though. Gorilla toolkit is also very neat, but it's a handy tool-box for web work, rather than a kitchen-sink framework.
buro9 14y ago
There's enough built into Go that frameworks feel very unnecessary. The only thing I'd strongly recommend is Gorilla Mux: http://www.gorillatoolkit.org/pkg/mux http://www.gorillatoolkit.org/pkg/mux And you can get an idea of how people build websites using Mux and Go by looking on github: https://github.com/jimmykuu/gopher https://github.com/jimmykuu/gopher If you're very new to Go, then reading that last link repo you probably want to read these files in this order: https://github.com/jimmykuu/gopher/blob/master/src/server/main.go https://github.com/jimmykuu/gopher/blob/master/src/server/ma... https://github.com/jimmykuu/gopher/blob/master/src/gopher/server.go https://github.com/jimmykuu/gopher/blob/master/src/gopher/se... https://github.com/jimmykuu/gopher/blob/master/src/gopher/urls.go https://github.com/jimmykuu/gopher/blob/master/src/gopher/ur... and then to take a look at the files in this folder for the handlers and html/template calling: https://github.com/jimmykuu/gopher/tree/master/src/gopher https://github.com/jimmykuu/gopher/tree/master/src/gopher
- stock_toaster 14y ago
  Second the Gorilla recommendation. Great toolkit.
- swah 14y ago
  In older versions there seemed to be a websocket package, but I can't find it anymore - do you know what hapenned to it?
  - 14y ago

LAMike 14y ago

What makes Go so cool?

frou_dh 14y ago
It: is small, is natively compiled, has great tools, has a great stdlib, is concurrent, is parallel, is gc'd ... and has well implemented features including closures, channels and structural static typing.
pjmlp 14y ago
It is made by Google.
- coldtea 14y ago
  Kind of like Google Wave was cool then?
  - pjmlp 14y ago
    Yes, still waiting to see if it will follow Reader and Wave's fate.
    - enneff 14y ago
      A nonsense comment. Go is an 100% open source project.
      - pjmlp 14y ago
        Lets see how far it goes if Google stops giving money to the core team.
        NateDad 14y ago
        1. Google isn't going to stop giving them money, as Go solves a ton of Google's problems with C++. 2. There are over 300 non-google contributors already http://golang.org/CONTRIBUTORS http://golang.org/CONTRIBUTORS

eridius 14y ago

The new data race detector looks great. I have a script I run daily that panics maybe once a month. I've never been able to figure out where the problem is. One run after building with -race and I now have a juicy data race report. Awesome!

eridius 14y ago
Turns out exec runs two goroutines, one for Stdout and one for Stderr, and if I run both into the same bytes.Buffer, that's a data race. No wonder I couldn't find it, I was looking in my own code for the goroutines. Thanks go1.1beta1!

pjmlp 14y ago

Still no generics :(

dsymonds 14y ago
You aren't going to see any radical changes to the language in the 1.x series.
- vanderZwan 14y ago
  To explain that a bit further: the core Go team is not against generics by definition, they just believe that no generics is better than bad generics (where "bad" admittedly is subjective, but see Russ Cox' article on the topic[1]). If/when they find a solution that fits their strict criteria, it in all likelihood will require breaking changes to the Go language, and the point of having the 1.x series was a promise that this would not happen. [1] http://research.swtch.com/generic http://research.swtch.com/generic
  - happy_dino 14y ago
    I'm wondering how long it will take until people will either stop linking to blatantly false articles or start reading more than the first 5 paragraphs of it.
    - vanderZwan 14y ago
      Apologies, I quickly Googled and pasted the link like you implied I did. I remember a longer, more deeply reasoned article than this one, and by quickly skimming I mistook this for that - it probably was somewhere on the go-nuts mailing list. The problem is that the topic of generics has come up so many times on that mailing list it will require quite a bit of digging to find that again. That said, the discussion below the article does get across the standpoint of the Go developers on the topic, doesn't it?
      - happy_dino 14y ago

knotty66 14y ago

FWIW, I benchmarked a basic Revel web app. Go 1.0.3 = 2850 req/sec ... 1.1 = 10928 req/sec.

conroy 14y ago
Any chance you can post the code you used to benchmark? That's an insane difference.
- knotty66 14y ago
  It was a basic newly generated Revel app running in production mode. Not hitting a DB. Benchmarked with 'ab -n 10000 -c 30 http://localhost:9000/some_action http://localhost:9000/some_action. See also: https://github.com/davecheney/autobench https://github.com/davecheney/autobench BenchmarkHTTPClientServer 373216, 52646 -85.89%
  - errnoh 14y ago
    bench old_ns/op new_ns/op delta "BenchmarkHTTPClientServer 373216, 52646 -85.89%" That bench is 7 times faster in Go 1.1 than 1.0.3.
    - knotty66 14y ago
      Uh? They are two separate benchmarks, that's why I said 'See also'.
      - deleted 14y ago
        [deleted]
        knotty66 14y ago
        The sources don't contradict each other? 1.1 is several times faster then 1.03 in both benchmarks.
        kyrias 14y ago

groundCode 14y ago

Kudos to the team. Go is going from strength to strength. I'm about to start a small project with it.

AcessoNegado 14y ago

I think this is really the one language/tech that's going to take off. It's just too early, but it's going to make it's splash.

chmike 14y ago

I'm a C++ and python programmer with some basic experience in JavaScript. I started learning Go, as I looked into D some years ago, an was a bit puzzled by some design choices. I don't understand the need to enforce the use of { } and that the if of for line must end with a {. I don't like this writing. My preferred syntax is the one of Pythons, which is the most concise and clear. It seem Go could have used : and indentation as in python instead of { }. Another puzzling choice of Go is slicing which differ from Python's and D's. In Go slicing is limited by the capacity and not by the number of items it contains. Returning 0 as default value looks to me like an open door to silent bugs. The way Go handles errors looks original and interesting, but I'm lacking experience to determine how it compares to exceptions from the usage perspective. From what I saw, I would say that Go is a better C and D is a better C++ where better means also closer. As a consequence Go seams simpler than D to learn and use. Thus I expect we will see much more Go programmers than D programmers in the future. Simplicity has been proven many times to be trump.

mseepgood 14y ago
> I don't understand the need to enforce the use of { } and that the if of for line must end with a {. I don't like this writing. My preferred syntax is the one of Pythons, which is the most concise and clear. This article explains the reasoning behind lots of Go's design choices: http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article "Some observers objected to Go's C-like block structure with braces, preferring the use of spaces for indentation, in the style of Python or Haskell. However, we have had extensive experience tracking down build and test failures caused by cross-language builds where a Python snippet embedded in another language, for instance through a SWIG invocation, is subtly and invisibly broken by a change in the indentation of the surrounding code. Our position is therefore that, although spaces for indentation is nice for small programs, it doesn't scale well, and the bigger and more heterogeneous the code base, the more trouble it can cause. It is better to forgo convenience for safety and dependability, so Go has brace-bounded blocks."
- ma2rten 14y ago
  My personal opinion on the subject is that you should not obsess about those things. It is good that Go that enforces one consistent style. In practice it does not really matter for your productivity what that style is. That said, I don't consider this a convincing argument. They basically say "We had some problems in the past with embedding Python code in Java files". This is a very specific problem and I could think of at least 4 different specific solutions for this specific problem. I don't think this arguement can support very broad conclusions like "Spaces for indentation does not scale to big and heterogeneous code bases and compromises safety and dependability for convenience".

g3orge 14y ago

I get a 404 at the changelog link they provide...

mahmoudhossam 14y ago
The correct link is in the first reply on Google groups.

yason 14y ago

What's the standard graphics library for Go That Just Works(tm) ? I'm looking for something for Go like PyGame is for Python. I like to get surfaces rendered on my screen in pretty much no time as I like to learn a language by doing simple graphical demos and experiment from there. There are few SDL bindings for Go but none of them worked. One of them did work to some extent after a lot of tweaking without the help of many examples. I quit learning after I realized I'd have to learn more how the graphics bindings were written than how to program in Go.

easytiger 14y ago
building a "standard graphics library" into a language that is not part of a write once run anywhere managed environment is a terrible idea and has never worked. On the other hand a more solid native 2d drawing library like java2d would be more welcome. Weekend project #34532
- deleted 14y ago
  [deleted]
  - easytiger 14y ago
    > "write once run anywhere managed environment" that is not even remotely what that is. A sufficiently advanced graphics library will do considerable amounts of non trivial interaction with system dependent and even hardware dependent libraries. The parent cited SDL. Which sits atop other libraries. Which imposes certain runtime constraints.
    - laumars 14y ago
      You're now talking specifically about SDL, where as I was commenting about your generalisation about Go as a language (which was the context of your previous comment). I'd already said Go lacks any kind of standard graphics library and never tried to argue otherwise. But the standard packages that are included with Go's SDK are cross platform. I can (and frequently do) write Go applications using just the standard libraries that I then run on different platforms (both in terms of OS and CPU architecture) without any code changes what-so-ever. Anyhow, even that being my point, I don't agree with it myself. Thinking properly about it, Go's base packages are little more equivalent to ANSI C than JRE; Go isn't managed and thus base packages are really just a set of standard libraries rather than a runtime environment.

truebosko 14y ago

For someone who wants to spend a week hacking on a project in Go, what kind of project do you recommend?

burntsushi 14y ago
The only real way to get hobby projects is to find a problem you've been having and solve it. So what are your problems? :-) Here are some of mine, that I turned into Go code: (restricted to "week long hacking" or less) A simple blog application. A command that when run, sends the output of other commands to your email. An image viewer. A simpler interface to `xrandr`. A parser for the new TOML configuration format. Or, you could pick a small program that you wrote in another language and port it.

derengel 14y ago

Is Go a good choice to create a CRUD web app? between the stdlib, gorilla toolking and the pg driver seems it wouldn't be so much of a pain, but the pg driver doesn't look ready for production use. https://github.com/bmizerany/pq https://github.com/bmizerany/pq

jbooth 14y ago
For just plain CRUD, you'll probably get where you want to go faster with Django or Ruby -- they get you up and running faster, and their template engines are more mature than anything in Go. Once you're beyond just plain CRUD to the point where the language you're using matters more than how fast you can get going with defaults, then you might like Go more (or less) than Ruby/Python.
chimeracoder 14y ago
I wrote the outline of one[0] a while back with gorilla and it wasn't too difficult. Be warned that some of the code is less-than-idiomatic, since I began it while I was still learning Go. There's definitely some refactoring that can be done, etc. However, as you can see, it's not too difficult to write a basic CRUD app with authentication, even if you're starting completely from scratch (which you don't have to; I did it more as a learning exercise). I disagree with jbooth; I find Go's templating language to be incredibly mature, and I also find it much easier to develop with gorilla than something like Flask, if for no other reason than the static compilation and incredibly thorough code analysis/other checking done at compile-time (unused lvalues, etc.) [0] https://github.com/chimeracoder/go-server-bootstrap https://github.com/chimeracoder/go-server-bootstrap

waterside81 14y ago

I've been using Python almost exclusively since 2004. Go is the first language that has made me want to switch. I can't put my finger on it, but it's fun to work with. Actually, I'll try to put my finger on it: 1) Fast build times 2) Goroutines. If you've tried using any async library in Python or are waiting for Tulip to come into mainline Python around v3.4 - stop wasting your time. Goroutines along with channels just works (TM) and is unbelievably easy to use. No callbacks, no threadpools, no having to CTRL-C your way out of a bug. It's a pleasure to work with.