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).
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.
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).
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.
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.
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?"
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.
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.
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.
> 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.
"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."
The formatting has been well thought out. The main problems with Python formatting are copy and paste problems, source control merges, and relying on the count of invisible characters to determine indenting. Any time you're merging two bits of code, it's very easy for the indenting to get messed up. In go, that's not a problem, since the braces are the only thing that matter. This is also what allows gofmt to format your code for you.
I think you misunderstand slicing. It's very similar to python's slices, except that python makes a copy of the list and Go does not. This is a really nice feature for reducing data copies.
The default values are very useful in many situations, and code is often designed around the fact that uninitialized variables have specific values.
As for error handling, Go's error handling is one of its biggest strengths, in my opinion. You never have to worry that your function will exit out in the middle unexpectedly. This is really great when dealing with third party libraries, since you don't have to know if something 6 levels deep is going to throw an exception... if something returns an error, you can deal with it right there. I find I write much more reliable code in Go, because error handling is so much simpler.
So use Nimrod instead: systems programming with indentation based syntax. It also has unmatched meta programming facilities, a realtime GC and checked exceptions done right (however, not in the 0.9.0 release).
> 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.
Having done a lot of straight C programming in my life, the error handling in Go is very familiar. Most C code returns errors and doesn't use exceptions (though I have used setjmp()/longjmp() fairly successfully at times).
In practice, the code is more verbose with Go's style of returned errors, but requires you to think more explicitly about errors and recovery, resulting in potentially better code overall.
However, since Go doesn't have an RIAA like C++ and doesn't have "goto" like C, it makes cleaning up from errors more ugly and repetitious (and potentially error prone). File handling, in particular, is causing me headaches right now (getting files closed on errors). I am admittedly a Go newbie, so I may be missing some style that makes it cleaner.
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.
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.
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!
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!
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").
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.
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.
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.
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.)
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.
[+] [-] dvt|13 years ago|reply
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).
[+] [-] enneff|13 years ago|reply
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.
[+] [-] vladev|13 years ago|reply
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).
[+] [-] VeejayRampay|13 years ago|reply
[+] [-] afhof|13 years ago|reply
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.
[+] [-] mseepgood|13 years ago|reply
I think it's very D-unlike. It's very small and simple.
[+] [-] pkolaczk|13 years ago|reply
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?"
[+] [-] trailfox|13 years ago|reply
[+] [-] obilgic|13 years ago|reply
[+] [-] smegel|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] chmike|13 years ago|reply
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|13 years ago|reply
This article explains the reasoning behind lots of Go's design choices: 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."
[+] [-] NateDad|13 years ago|reply
I think you misunderstand slicing. It's very similar to python's slices, except that python makes a copy of the list and Go does not. This is a really nice feature for reducing data copies.
The default values are very useful in many situations, and code is often designed around the fact that uninitialized variables have specific values.
As for error handling, Go's error handling is one of its biggest strengths, in my opinion. You never have to worry that your function will exit out in the middle unexpectedly. This is really great when dealing with third party libraries, since you don't have to know if something 6 levels deep is going to throw an exception... if something returns an error, you can deal with it right there. I find I write much more reliable code in Go, because error handling is so much simpler.
[+] [-] hp50g|13 years ago|reply
I'm not really a fan of python indentation as I've had to clean up a couple of messes before.
[+] [-] dom96|13 years ago|reply
[+] [-] __david__|13 years ago|reply
Having done a lot of straight C programming in my life, the error handling in Go is very familiar. Most C code returns errors and doesn't use exceptions (though I have used setjmp()/longjmp() fairly successfully at times).
In practice, the code is more verbose with Go's style of returned errors, but requires you to think more explicitly about errors and recovery, resulting in potentially better code overall.
However, since Go doesn't have an RIAA like C++ and doesn't have "goto" like C, it makes cleaning up from errors more ugly and repetitious (and potentially error prone). File handling, in particular, is causing me headaches right now (getting files closed on errors). I am admittedly a Go newbie, so I may be missing some style that makes it cleaner.
[+] [-] TylerE|13 years ago|reply
[+] [-] waterside81|13 years ago|reply
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.
[+] [-] yason|13 years ago|reply
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.
[+] [-] knotty66|13 years ago|reply
[+] [-] eridius|13 years ago|reply
[+] [-] eridius|13 years ago|reply
[+] [-] frou_dh|13 years ago|reply
[0] http://tip.golang.org/doc/go1.1#return
[+] [-] eridius|13 years ago|reply
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|13 years ago|reply
But as only fixes will be submitted between now and the 1.1 release, it's definitely better to use tip.
[+] [-] glitch273|13 years ago|reply
[+] [-] buro9|13 years ago|reply
The only thing I'd strongly recommend is Gorilla 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
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/ma... https://github.com/jimmykuu/gopher/blob/master/src/gopher/se... 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
[+] [-] dualogy|13 years ago|reply
Gorilla toolkit is also very neat, but it's a handy tool-box for web work, rather than a kitchen-sink framework.
[+] [-] VeejayRampay|13 years ago|reply
[+] [-] phasevar|13 years ago|reply
[+] [-] trailfox|13 years ago|reply
[+] [-] groundCode|13 years ago|reply
[+] [-] LAMike|13 years ago|reply
[+] [-] derengel|13 years ago|reply
https://github.com/bmizerany/pq
[+] [-] jbooth|13 years ago|reply
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|13 years ago|reply
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
[+] [-] truebosko|13 years ago|reply
[+] [-] burntsushi|13 years ago|reply
Here are some of mine, that I turned into Go code: (restricted to "week long hacking" or less)
Or, you could pick a small program that you wrote in another language and port it.[+] [-] pjmlp|13 years ago|reply
[+] [-] dsymonds|13 years ago|reply
[+] [-] kyrias|13 years ago|reply
[+] [-] g3orge|13 years ago|reply
[+] [-] mahmoudhossam|13 years ago|reply
[+] [-] AcessoNegado|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] creativityland|13 years ago|reply
[+] [-] dualogy|13 years ago|reply