The lack of exceptions just seems like a total bear to me. I wrote C for 10 years and did tons of stuff like:<p><pre><code> Open file "foobar.dat". If that fails, abort with this error.
Read the first 4 bytes into x.
If that fails, abort with a different error.
Seek to byte x. If that fails, abort with yet another error.
</code></pre>
and so on, and so on, over and over again. Python's exceptions are a huge improvement over this pattern of timidly asking permission to do anything. The fact is there are so, so many occasions where you want to abort a computation if one of the many steps along the way goes wrong. Something like Haskell's Maybe monad is a good way of attacking the problem too.<p>But Go has neither. It seems to just offer the bad old clumsy C way and say, "Deal with it." To those who have written real Go programs, I'm honestly wondering: how is this not a pain in the ass?
A tip from someone that just recently started using Go: read the spec! I wasted some time early on trying to learn things that are very clearly and simply spelled out in the spec. The Tour + Spec is really all you need if you're a somewhat experienced programmer.<p>The spec is well written and tiny compared to most languages, and it's probably the only thoroughly accurate and complete Go reference at the moment.<p>Step 1. <a href="http://tour.golang.org/" rel="nofollow">http://tour.golang.org/</a>
Step 2. <a href="http://golang.org/ref/spec" rel="nofollow">http://golang.org/ref/spec</a>
I love how the dialogue on HN about Go has gone from pessimism and largely uninformed criticism, to regurgitation of the team's own talking points ["simple, orthogonal features"], to a more nuanced appreciation of what trade-offs Go makes.<p>Hopefully these are individual developers shifting through a continuum of enlightenment, rather than the conversation itself migrating to a more enlightened population.<p>This last question is testable, of course, though sadly HN does not offer an official API.
My biggest issues with Go are compatibilities with the C ABI and the lack of shared library support. I have not looked in a while, so I may be wrong, but here are my big questions: 1. Can C invoke a Go-compiled and exported callback/function? 2. Can I build a Go .so/.dll invokable via C or other non-Go FFI methods? 3. If I build a commercial Go lib for others to link with, how can I distribute it without distributing the Go source?
Everybody compares Go and Python. How is it so? Go compiles to a binary, implements static typing, got rid of classes, got rid of exceptions, and added lots of special purpose keywords on top of reinventing C's syntax. The only similarity I see is the "import" statement.
I (a go noob) somehow got the impression that you're supposed to version your API when writing go libraries. ie, your library should be github.com/501/foo/v1 rather than github.com/501/foo. Can any go users comment on whether that's expected practice?
Erlang does automatically parallelize over multiple cores. By default it will start one Erlang VM thread per core which work together to run the Erlang system. The Erlang VM also does automatic load balancing over the threads and even tries to shut down threads/cores if it detects they are not needed. It is possible to control how many Erlang VM threads you want at start-up and to lock them to cores as well, though the latter is not recommended. But as I said there is no need to do this.