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).
From r60 to Go 1
11–20 of 30 posts
Re: From r60 to Go 1
#12Anyone 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).
I chose it because the native code interface is so nice, so it's trivial to use libraries like ZeroMQ without the overhead you'd see out of something like JNI.
Re: From r60 to Go 1
#13Re: From r60 to Go 1
#14So 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?
Re: From r60 to Go 1
#15So 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?
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.
Re: From r60 to Go 1
#16Fantastic. I was hoping Makefiles would go away. I hate writing them! More detailed info here: http://weekly.golang.org/doc/go1.html
Re: From r60 to Go 1
#17Looks 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.
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 decisi…
Re: From r60 to Go 1
#18Anyone 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).
Re: From r60 to Go 1
#19Anyone 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).
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.
Re: From r60 to Go 1
#201. language designed with good intentions (http://golang.org/doc/go_faq.html#What_is_the_purpose_of_the...)
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.