On Sun, Jul 25, 2010 at 9:29 AM, Owen Densmore <o...@backspaces.net> wrote:
> So .. here's the question, given our current understanding: can Go succeed? > > Generally a new technology has to have a 10x improvement over the current > tech to make it. Its just too hard to change for it to merely be good and > sexy. > > I've been on the Go Nuts group and found that they apparently are fairly > slim group -- I asked if Joyent/Solaris could use Go in the near future. > No, they aren't working on a port, and near-term Windows is naturally their > next platform. This indicates to me that the group is lean-and-mean. > > That's fine, but suggests that Go is not getting a lot of support. So it > is not, for example, going to succeed the way Java did .. by being "better" > and having a lot of libraries being built for it. A LOT of them. > > Do you see a way for Go to really succeed? > > I wonder why you chose to show us the 32bit benchmarks: http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all <http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all>instead of the 64bit benchmarks: http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=all The median performance of Go on 64bits (2.44) is better than the best performing Go program on 32bits (2.69). I'd be very wary of handicapping this at this point. Go has been in public existence for less than a year, announced last November, and in development less than 3 years, since September 2007. It's been in development a year less than Java had been at its initial release in 1995. In that time it's overtaken 15 languages in performance on the 64bit list, including the second oldest (Lisp at 62), the third and fourth oldest (Pascal and Smalltalk at 40), the sixth oldest (Racket/Scheme at 30), and it's on the verge of overtaking the oldest (Fortran at 63). There is nothing in the design of Go which will prevent it from eventually reaching parity with gcc and g++ in scalar performance. I've already found one of the Go benchmarks, mandelbrot, with multi-processing support already in it. It spins off a goroutine for each available core to compute scan lines in parallel. The issues of source code complexity and costs of compilation in large projects are true problems. The dynamic languages simply ignore the issues, by going for dynamic types, interpretation, and jits. The compiled languages are stuck with their syntax and their include file dependencies. -- rec --
============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
