Re: [FRIAM] [sfx: Discuss] The Go Programming Language
Go is open source and I'm wondering how many of the successful languages are open source. Go seems to be designed well for multiple core situations, so it may take off as cloud computing does. Go might lower the development costs for huge projects if the right Go team can exploit the language's simplicity to save time. At this point, I think the best languages are the ones that have large communities and libraries - assets that Go does not have. Tyler On 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? -- Owen -- You received this message because you are subscribed to the Santa Fe Complex discuss group. To post to this group, send email to disc...@sfcomplex.org To unsubscribe from this group, send email to discuss+unsubscr...@sfcomplex.org For more options, visit this group at http://groups.google.com/a/sfcomplex.org/group/discuss 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
Re: [FRIAM] [sfx: Discuss] The Go Programming Language
Owen Densmore wrote: I've been on the Go Nuts group and found that they apparently are fairly slim group Unlike, http://www.haskell.org/pipermail/haskell-cafe/ http://hackage.haskell.org/packages/archive/pkg-list.html http://software.intel.com/en-us/blogs/2010/05/27/announcing-intel-concurrent-collections-for-haskell-01/ http://research.microsoft.com/en-us/um/people/simonpj/papers/haskell-retrospective/Haskell-Erlang-Jun09.pdf 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
Re: [FRIAM] [sfx: Discuss] The Go Programming Language
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=alllang=all http://shootout.alioth.debian.org/u32/benchmark.php?test=alllang=allinstead of the 64bit benchmarks: http://shootout.alioth.debian.org/u64/benchmark.php?test=alllang=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
Re: [FRIAM] [sfx: Discuss] The Go Programming Language
Thanks, good .. er .. pointers. :) -- Owen On Jul 23, 2010, at 9:16 PM, Roger Critchlow wrote: Oh, I see Pike gave two other talks at OSCON, no video but pdfs of the slides: Go http://www.oscon.com/oscon2010/public/schedule/detail/15464 Another Go at Language Design http://www.oscon.com/oscon2010/public/schedule/detail/14760 On Fri, Jul 23, 2010 at 9:08 PM, Roger Critchlow r...@elf.org wrote: Rob Pike made a presentation at the O'Reilly Open Source Conference yesterday slamming Java and C++ as part of explaining how the Go Language came about. http://infoworld.com/d/developer-world/google-executive-frustrated-java-c-complexity-375 Ah, here's a link to a pdf for the talk and a 12:30 you tube video. http://www.oscon.com/oscon2010/public/schedule/detail/13423 -- 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
Re: [FRIAM] [sfx: Discuss] The Go Programming Language
I thought they were good references. ;-] ;-] --Doug On Sat, Jul 24, 2010 at 10:59 AM, Owen Densmore o...@backspaces.net wrote: Thanks, good .. er .. pointers. :) -- Owen On Jul 23, 2010, at 9:16 PM, Roger Critchlow wrote: Oh, I see Pike gave two other talks at OSCON, no video but pdfs of the slides: Go http://www.oscon.com/oscon2010/public/schedule/detail/15464 http://www.oscon.com/oscon2010/public/schedule/detail/15464 Another Go at Language Design http://www.oscon.com/oscon2010/public/schedule/detail/14760 On Fri, Jul 23, 2010 at 9:08 PM, Roger Critchlow r...@elf.org wrote: Rob Pike made a presentation at the O'Reilly Open Source Conference yesterday slamming Java and C++ as part of explaining how the Go Language came about. http://infoworld.com/d/developer-world/google-executive-frustrated-java-c-complexity-375 http://infoworld.com/d/developer-world/google-executive-frustrated-java-c-complexity-375Ah, here's a link to a pdf for the talk and a 12:30 you tube video. http://www.oscon.com/oscon2010/public/schedule/detail/13423 http://www.oscon.com/oscon2010/public/schedule/detail/13423-- 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
Re: [FRIAM] [sfx: Discuss] The Go Programming Language
It's interesting to see that go already is in the language shootout: http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php#table That means its pretty serious .. lota work to get the benchmark programs written. But they have a long way to go: above them are c/c++, java, scala, lua, pascal, ada, haskell, Fortran, F#/C#, ocaml, lisp/scheme. BUT all these (plus javascript v8) all come in with a median of less than 10. Python = 31, ruby = 38, php = 81!!. Listening to the talk, Pike clearly distinguished between dynamic/interpreted and ease of use. Sad to loose the python dynamics and sophistication, but at its level of development to have javascript crush it at over 4x in speed, I gotta say v8 js looks pretty good! Interesting that both go and js use a different solution for classes/objects. Alan Kay must be happy! So I gotta wonder: is go going to replace c/c++ over time @ google? And possibly more interesting, will it somehow affect the JS v8 effort? -- Owen 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
Re: [FRIAM] [sfx: Discuss] The Go Programming Language
Pike actually says in a few places that there could be pointers when his examples use arrays. Declaring an array argument doesn't automatically get you a pointer to the contents of the array, but you can get one if it's needed. So pointers and references. I found it even more apparent on this pass through that the language is very well built for the kind of parallel programming that I've become comfortable with in erlang. That is, go makes it very easy to spin off a new thread/process/goroutine and establish communications using channels. This is a matter of being able to easily instantiate the appropriate graph of communicating sequential processes to a computational task, receive the result of the computation when it finishes or fails, and know that all the cruft got cleaned up. So if your computation can be pipelined or fanned out onto multiple cores, That it's all statically typed and compiled and compiles fast is an appreciable advantage. I've been beating my head against the erlang dialyzer lately, which does static type analysis as an appendix to the main language involving type specifications with a syntax and predefined vocabulary that extends base erlang. That would be tolerable, but the dialyzer takes a coffee break to grovel through its computations, and I can't drink enough coffee to keep myself amused while it grovels. -- rec -- On Sat, Jul 24, 2010 at 11:17 AM, Douglas Roberts d...@parrot-farm.netwrote: I thought they were good references. ;-] ;-] --Doug On Sat, Jul 24, 2010 at 10:59 AM, Owen Densmore o...@backspaces.netwrote: Thanks, good .. er .. pointers. :) -- Owen On Jul 23, 2010, at 9:16 PM, Roger Critchlow wrote: Oh, I see Pike gave two other talks at OSCON, no video but pdfs of the slides: Go http://www.oscon.com/oscon2010/public/schedule/detail/15464 http://www.oscon.com/oscon2010/public/schedule/detail/15464 Another Go at Language Design http://www.oscon.com/oscon2010/public/schedule/detail/14760 On Fri, Jul 23, 2010 at 9:08 PM, Roger Critchlow r...@elf.org wrote: Rob Pike made a presentation at the O'Reilly Open Source Conference yesterday slamming Java and C++ as part of explaining how the Go Language came about. http://infoworld.com/d/developer-world/google-executive-frustrated-java-c-complexity-375 http://infoworld.com/d/developer-world/google-executive-frustrated-java-c-complexity-375Ah, here's a link to a pdf for the talk and a 12:30 you tube video. http://www.oscon.com/oscon2010/public/schedule/detail/13423 http://www.oscon.com/oscon2010/public/schedule/detail/13423-- 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 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
Re: [FRIAM] [sfx: Discuss] The Go Programming Language
Roger Critchlow wrote: I found it even more apparent on this pass through that the language is very well built for the kind of parallel programming that I've become comfortable with in erlang. That is, go makes it very easy to spin off a new thread/process/goroutine and establish communications using channels. This is a matter of being able to easily instantiate the appropriate graph of communicating sequential processes to a computational task, receive the result of the computation when it finishes or fails, and know that all the cruft got cleaned up. So if your computation can be pipelined or fanned out onto multiple cores, I can see that goroutines and channels are appealing programming abstractions, but have a hard time believing they could scale. Seems like the more goroutines you have the more CPU cycles that will be absorbed in switching amongst them.I could see how distributed Erlang would scale with lots of high latency _network_ messages in flight -- the amount of time for switching would be small compared to the latency of the message. That wouldn't seem to be the case with Google Go, which would all be in core. Marcus 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
Re: [FRIAM] [sfx: Discuss] The Go Programming Language
On Sat, Jul 24, 2010 at 12:46 PM, Marcus Daniels mar...@snoutfarm.comwrote: Roger Critchlow wrote: I found it even more apparent on this pass through that the language is very well built for the kind of parallel programming that I've become comfortable with in erlang. That is, go makes it very easy to spin off a new thread/process/goroutine and establish communications using channels. This is a matter of being able to easily instantiate the appropriate graph of communicating sequential processes to a computational task, receive the result of the computation when it finishes or fails, and know that all the cruft got cleaned up. So if your computation can be pipelined or fanned out onto multiple cores, I can see that goroutines and channels are appealing programming abstractions, but have a hard time believing they could scale. Seems like the more goroutines you have the more CPU cycles that will be absorbed in switching amongst them.I could see how distributed Erlang would scale with lots of high latency _network_ messages in flight -- the amount of time for switching would be small compared to the latency of the message. That wouldn't seem to be the case with Google Go, which would all be in core. Right, but is that a Google Go problem or is it our failure to build useful multi-core processors? All my Erlang programs are running on one machine, but that doesn't make the factoring into communicating processes any less pleasing to my sense of algorithmic correctness. If I am comfortable correctly expressing the parallel granularity of a computation, then a compiler can transform to any equivalent sequential form up to simply simulating the parallelism I wrote on a single core. But if I can't express the parallel granularity, then who will ever know what I was trying to do? Erlang can scale with distribution, but it can also discover that processes which cooperated when locally hosted fail when distributed, or vice versa. Every receive in an Erlang program has a timeout which typically reports what failed to happen in the expected time and dies. Which is why Erlang comes bundled with the uselessly misnamed OTP (Open Telecom Platform) libraries so you can monitor process deaths and specify how much of the system needs to be torn down and restarted when part of it chokes, and give up when it chokes repeatedly, and write logs of stultifying detail about what happened. At which point you open up the logs, see who repeatedly timed out, and tweak the timeout until it gets happy again. You can, in general, tune things to work at different scales, but not all things and not at all scales. Locally hosted Erlang programs can scale linearly in performance with the number of cores, but they will probably run into the same problem that you anticipate for Google Go at some point. -- 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
Re: [FRIAM] [sfx: Discuss] The Go Programming Language
Roger Critchlow wrote: I can see that goroutines and channels are appealing programming abstractions, but have a hard time believing they could scale. Seems like the more goroutines you have the more CPU cycles that will be absorbed in switching amongst them.I could see how distributed Erlang would scale with lots of high latency _network_ messages in flight -- the amount of time for switching would be small compared to the latency of the message. That wouldn't seem to be the case with Google Go, which would all be in core. Right, but is that a Google Go problem or is it our failure to build useful multi-core processors? It don't think it's a processor design issue so much as a network and memory subsystem design issue. Given: 1) Concurrency = Bandwidth * Latency 2) Latency can only be minimized so far 3) Bandwidth can always be increased by adding wires. By being limited to SMP type systems, Go is assuming latency is already minimized. But the way you really get a lot of concurrency is by allowing for higher latency communication (e.g. long wires between many processors). Go does not provide a programming model where memory can be accessed across cores. Even if the operating system did that for you, the Go scheduler would only know about spinning threads for pending channels, not for pending memory. To my mind, what would be preferable is to have all memory to be channels (i.e. as Cray XMT implements in hardware). Alternatively, keep a small number of channels (compared to the number memory addresses) but constrain the use of memory to named (typically local) address spaces, i.e. Sequoia or OpenCL. Marcus 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
Re: [FRIAM] [sfx: Discuss] The Go Programming Language
Rob Pike made a presentation at the O'Reilly Open Source Conference yesterday slamming Java and C++ as part of explaining how the Go Language came about. http://infoworld.com/d/developer-world/google-executive-frustrated-java-c-complexity-375 http://infoworld.com/d/developer-world/google-executive-frustrated-java-c-complexity-375Ah, here's a link to a pdf for the talk and a 12:30 you tube video. http://www.oscon.com/oscon2010/public/schedule/detail/13423 http://www.oscon.com/oscon2010/public/schedule/detail/13423-- rec -- On Fri, Jul 23, 2010 at 6:29 PM, Owen Densmore o...@backspaces.net wrote: Has anyone tried Google's go language? http://golang.org/ Google makes the same case for it as chrome: its been 10 years since a system language has been created! Mainly the concern is multi-core gc and an architecture for large distributed systems. I just installed on my macbook: http://golang.org/doc/install.html http://www.kelvinwong.ca/2009/11/12/installing-google-go-on-mac-os-x-leopard Kinda interesting looking at the faq's .. they are adamant that simplicity is important. -- Owen -- You received this message because you are subscribed to the Santa Fe Complex discuss group. To post to this group, send email to disc...@sfcomplex.org To unsubscribe from this group, send email to discuss+unsubscr...@sfcomplex.org discuss%2bunsubscr...@sfcomplex.org For more options, visit this group at http://groups.google.com/a/sfcomplex.org/group/discuss 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
Re: [FRIAM] [sfx: Discuss] The Go Programming Language
Oh, I see Pike gave two other talks at OSCON, no video but pdfs of the slides: Go http://www.oscon.com/oscon2010/public/schedule/detail/15464 http://www.oscon.com/oscon2010/public/schedule/detail/15464 Another Go at Language Design http://www.oscon.com/oscon2010/public/schedule/detail/14760 On Fri, Jul 23, 2010 at 9:08 PM, Roger Critchlow r...@elf.org wrote: Rob Pike made a presentation at the O'Reilly Open Source Conference yesterday slamming Java and C++ as part of explaining how the Go Language came about. http://infoworld.com/d/developer-world/google-executive-frustrated-java-c-complexity-375 http://infoworld.com/d/developer-world/google-executive-frustrated-java-c-complexity-375Ah, here's a link to a pdf for the talk and a 12:30 you tube video. http://www.oscon.com/oscon2010/public/schedule/detail/13423 http://www.oscon.com/oscon2010/public/schedule/detail/13423-- rec -- On Fri, Jul 23, 2010 at 6:29 PM, Owen Densmore o...@backspaces.netwrote: Has anyone tried Google's go language? http://golang.org/ Google makes the same case for it as chrome: its been 10 years since a system language has been created! Mainly the concern is multi-core gc and an architecture for large distributed systems. I just installed on my macbook: http://golang.org/doc/install.html http://www.kelvinwong.ca/2009/11/12/installing-google-go-on-mac-os-x-leopard Kinda interesting looking at the faq's .. they are adamant that simplicity is important. -- Owen -- You received this message because you are subscribed to the Santa Fe Complex discuss group. To post to this group, send email to disc...@sfcomplex.org To unsubscribe from this group, send email to discuss+unsubscr...@sfcomplex.org discuss%2bunsubscr...@sfcomplex.org For more options, visit this group at http://groups.google.com/a/sfcomplex.org/group/discuss 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
