5 ms·

I have'nt managed enough time yet to familiarize myself with Go, but the little that I have glanced at, it seems a nice enough language for scientific computati

by srean 15y ago

I have'nt managed enough time yet to familiarize myself with Go, but the little that I have glanced at, it seems a nice enough language for scientific computation. The syntax and semantics of arrays are nice and binding to C is purportedly simple. Ease of binding with Fortran would have been nice too. So I find it a bit strange that I never hear of Go in the context of array based computation, that is the stuff people use Numpy, MATLAB, J, K for. Is there any particular reason for that or is it just that not many have got around to doing it. A type-inferred language with first class functions, with strong support for parallelism, and good support for arrays and slicing seems a really sweet deal. Throw in SIMD and it is already very compelling. Is anything wrong with the picture that I am missing. Performance issues ?

georgemcbay 15y ago
Thus far you barely hear of anyone using Go in any context, though that is changing. I think the primary reason for the lack of users has been language stability. The Go team are currently working on the first actual "release" of the language ("Go 1") to address this. But prior to the move towards Go 1, the language was very much in flux, more so than you'd want for a language (that you'll actively be maintaining code in) to be. (And gofix, while nice, isn't really a substitute for language and standard library stability).
- krasin 15y ago
  According to the recent weekly release, they are 1-2 weeks before Go 1 release: http://weekly.golang.org/doc/devel/weekly.html#2012-03-13 http://weekly.golang.org/doc/devel/weekly.html#2012-03-13
- eternalban 15y ago
  > And gofix, while nice, isn't really a substitute for language and standard library stability I agree with you in principle but practically, gofix (+ gofmt) it is pretty darn close. I revisited a Go project that I wrote back when it first came out (in other words, an ancient one :). Biggest pita was dealing with the 'error' changes that gofix couldn't fix (and some minor pain due to time and Duration), but everything else was taken care of by the tool. In any event, my understanding is that the Go authors will strategically depend on gofix to deal with language evolution (beyond "Go 1"). I've been coding since '82 and have had my share of PLs. Go is a serious contender and I highly recommend it to anyone looking for a "modern" C.
ootachi 15y ago
The concurrent stop-the-world garbage collector is a performance issue. Additionally, the Plan 9-based compiler is not an optimizing compiler.
- dsymonds 15y ago
  Have you found the GC to be an actual problem? Or are you assuming it is? It's a very different situation to other GC-based languages.
  - ootachi 15y ago
    Why is it so different? I'd be curious to know. In my experience, a stop-the-world collector that must be threadsafe ends up being a disaster. You hit a brick wall in terms of real-time performance quickly (look at iOS versus Android for an easy example, and Dalvik's GC is much more sophisticated than that of Go these days). I predict that Go is going to have to put a lot of effort into making the GC fast in order to compete with C++ and Java. They're going to need a concurrent, generational garbage collector much like Java's, probably with a server mode and a client mode. It'll have to be heavily tuned and will require man-years of work.
    - enneff 15y ago
      Java requires a powerful, sophisticated garbage collector because it is extremely difficult (and in many cases impossible) to write Java programs that don't generate a lot of garbage. Even many of the core APIs are allocation heavy. It's a pain. Go data structures tend to be much smaller than the Java equivalents, and it is much easier to track down and eliminate unnecessary allocations in Go code. When you have better control over allocations you don't need to lean so hard on the garbage collector. (Some of this is touched on here http://loadcode.blogspot.com.au/2009/12/go-vs-java.html http://loadcode.blogspot.com.au/2009/12/go-vs-java.html) You seem to have a lot of strong opinions (and predictions!) about Go, when you clearly don't have much experience with it.
      - ootachi 15y ago
canop_fr 15y ago
I concur about arrays. Each time I make computations in java and I have to either pass offsets and lengths or make arraycopy I regret not to code in Go.

by srean 15y ago

georgemcbay 15y ago

Thus far you barely hear of anyone using Go in any context, though that is changing. I think the primary reason for the lack of users has been language stability. The Go team are currently working on the first actual "release" of the language ("Go 1") to address this. But prior to the move towards Go 1, the language was very much in flux, more so than you'd want for a language (that you'll actively be maintaining code in) to be. (And gofix, while nice, isn't really a substitute for language and standard library stability).

krasin 15y ago
According to the recent weekly release, they are 1-2 weeks before Go 1 release: http://weekly.golang.org/doc/devel/weekly.html#2012-03-13 http://weekly.golang.org/doc/devel/weekly.html#2012-03-13
eternalban 15y ago
> And gofix, while nice, isn't really a substitute for language and standard library stability I agree with you in principle but practically, gofix (+ gofmt) it is pretty darn close. I revisited a Go project that I wrote back when it first came out (in other words, an ancient one :). Biggest pita was dealing with the 'error' changes that gofix couldn't fix (and some minor pain due to time and Duration), but everything else was taken care of by the tool. In any event, my understanding is that the Go authors will strategically depend on gofix to deal with language evolution (beyond "Go 1"). I've been coding since '82 and have had my share of PLs. Go is a serious contender and I highly recommend it to anyone looking for a "modern" C.

ootachi 15y ago

The concurrent stop-the-world garbage collector is a performance issue. Additionally, the Plan 9-based compiler is not an optimizing compiler.

dsymonds 15y ago
Have you found the GC to be an actual problem? Or are you assuming it is? It's a very different situation to other GC-based languages.
- ootachi 15y ago
  Why is it so different? I'd be curious to know. In my experience, a stop-the-world collector that must be threadsafe ends up being a disaster. You hit a brick wall in terms of real-time performance quickly (look at iOS versus Android for an easy example, and Dalvik's GC is much more sophisticated than that of Go these days). I predict that Go is going to have to put a lot of effort into making the GC fast in order to compete with C++ and Java. They're going to need a concurrent, generational garbage collector much like Java's, probably with a server mode and a client mode. It'll have to be heavily tuned and will require man-years of work.
  - enneff 15y ago
    Java requires a powerful, sophisticated garbage collector because it is extremely difficult (and in many cases impossible) to write Java programs that don't generate a lot of garbage. Even many of the core APIs are allocation heavy. It's a pain. Go data structures tend to be much smaller than the Java equivalents, and it is much easier to track down and eliminate unnecessary allocations in Go code. When you have better control over allocations you don't need to lean so hard on the garbage collector. (Some of this is touched on here http://loadcode.blogspot.com.au/2009/12/go-vs-java.html http://loadcode.blogspot.com.au/2009/12/go-vs-java.html) You seem to have a lot of strong opinions (and predictions!) about Go, when you clearly don't have much experience with it.
    - ootachi 15y ago

canop_fr 15y ago

I concur about arrays. Each time I make computations in java and I have to either pass offsets and lengths or make arraycopy I regret not to code in Go.