

From r60 to Go 1 - BarkMore
http://gophersays.com/from-r60-to-go1/

======
hungrycoder
I am excited by golang and plan to start hacking with it. Here's why:

1\. language designed with good intentions
([http://golang.org/doc/go_faq.html#What_is_the_purpose_of_the...](http://golang.org/doc/go_faq.html#What_is_the_purpose_of_the_project))

2\. designed and built by a group of veteran system researchers and engineers
(ie. not javascript)

3\. implementation open sourced from the start:
<http://code.google.com/p/go/source/browse>

4\. not overdesigned (<http://golang.org/doc/go_faq.html#Design>)

5\. a real and practical abstraction for multicore computing
(<http://www.usingcsp.com/cspbook.pdf>)

Its success, like most languages, will depend on library support. Here's
hoping it catches on.

~~~
jbarham
> Its success, like most languages, will depend on library support.

By that measure Go's standard library is very extensive:
<http://weekly.golang.org/pkg/>

There are also a lot of 3rd party packages (e.g.,
<http://godashboard.appspot.com/package>) most of which can be installed in a
single command.

For my purposes, Go's standard library has proved as complete as Python's
(<http://docs.python.org/library/index.html>) and includes some things that
the Python standard library doesn't (e.g., crypto, graphics), all the more
impressive IMO considering how relatively young Go is.

------
peregrine
Wow these are significant changes! The entire development process has been
cleaned up significantly, and not having to use Makefiles is a significant
improvement, as well as default error type. Go team is dedicated to developers
and developer process and it will pay off.

~~~
sho_hn
Agreed, this sort of attention to tooling and the more menial parts of the
development experience is sorely amiss among many other contenders, and
definitely makes Go appear more interesting to me.

------
bwarp
Fantastic. I was hoping Makefiles would go away. I hate writing them!

More detailed info here: <http://weekly.golang.org/doc/go1.html>

------
duaneb
Looks like Go is cleaning up. Love the language, but I won't commit to writing
heavy-duty code in it until it either has sensible union support or sensible
generic support. The type system is just too weak right now.

~~~
bwarp
I actually thought that to start with but when you get used to the frankly
wierd type system, it actually works extremely well without generics (bear in
mind I use C# which is heavily generic programming). When you approach the
problems with a Go mindset, I don't think I've found a single case that needed
generic types.

I'm not sure of the value of unions now or ever as it brings what is
effectively a compiler decision into user space and allows very unsafe,
architecture dependent code to be accidentally written.

~~~
ootachi
Discriminated unions are neither architecture-dependent nor unsafe.

~~~
bwarp
A "tagged union" which is what I assume you mean is usually abstracted as a
native type (struct) in other langauges (Go included). C gives you
architecture level access to it. Go leaves it to the VM to decide.

------
kristianp
Note that Go 1 hasn't been released yet, but can be previewed from the weekly
tag.

------
cpeterso
Are any Google projects currently using or evaluating Go for production?

~~~
enneff
Yep, there are some Go services at Google that handle a staggering amount of
traffic. I hope to be able to discuss one of the services publicly later this
year. (Yeah, confidentiality is a drag.)

------
fennecfoxen
So to be perfectly clear, this is a project named Go but it's not Google Go?
It used to be named r60? It has something to do with building things?

~~~
mbrubeck
Go 1 is a release of the Go programming language developed at Google. The
summary of <http://weekly.golang.org/doc/go1.html> has details.

~~~
fennecfoxen
Thank you for your informative and clarifying information!

------
listic
What's wrong with makefiles and why is new Go convention better?

~~~
enneff
All the information required to build a go package is in the source. why write
and maintain Make files when they are unnecessary? The Go project is all about
making programming simpler.

------
zyfo
Anyone using or planning on using Go in the near future? For what?

It looks intriguing but I can't think of any obvious immediate applications
(I'm sure there are plenty, I just don't see them).

~~~
unoti
I'm using it to build a world server for a multiplayer game. A lot of people
suggest Scala/Java, Erlang, or Node.js for this, but I'm using Go. Go has a
good, efficient memory model that lets me simulate a heck of a lot more of my
world per megabyte of RAM. In today's world of hosting, that translates into a
huge impact on how many dollars per user/hour we need to pay to run our game.
That can have a direct translation into what kinds of business models can, and
cannot, work for a game design. I've actually written rudimentary versions of
my world server in all of the languages I mentioned above, and Go is by far
the best in terms of what I can do with memory.

Go makes it very easy to communicate between nodes, almost as easy as what you
can do in Erlang. Doozer is a library in Go for coordination of the activities
of many machines, a lot like Zookeeper. Between Doozer and Netchan, Go is a
really solid choice for making a system like a world simulator that needs to
be distributed among many computers.

Go is also better than Node.js for things that require manipulating binary
data. For example, I have some communications back and forth where the server
is in Go, the client is in Python, and they talk using Protocol Buffers.
Javascript doesn't do binary (at all? not very well?) like Go or Java can.
There is an experimental protocol buffer library in Javascript, but in general
Javascript needs to kind of bend over backwards to work with binary data. It's
possible to do it, but it's not natural or efficient.

In general, if you care about memory usage, working with binary data, tons of
simultaneous threads/actors, building distributed systems, then Go is a great
choice, especially if you want to do more than one of the above.

~~~
hungrycoder
Would love to hear more in the form of a blog post; perhaps when the world
server has shipped.

+1 on memory usage. OOM is a killer for long running apps (pun intended)

