The Go Programming Language
Locked
 
Administrator
|
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 ============================================================ 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 |
|
|
This came up a while ago. At that time I compared it to Haskell.
-- Russ Abbott ______________________________________ Professor, Computer Science California State University, Los Angeles cell: 310-621-3805 Google voice: 424-242-USA0 (last character is zero) blog: http://russabbott.blogspot.com/ vita: http://sites.google.com/site/russabbott/ ______________________________________ On Fri, Jul 23, 2010 at 5:29 PM, Owen Densmore <[hidden email]> wrote: Has anyone tried Google's go language? ============================================================ 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: [sfx: Discuss] The Go Programming Language
|
|
In reply to this post by Owen Densmore
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.
On Fri, Jul 23, 2010 at 6:29 PM, Owen Densmore <[hidden email]> wrote: Has anyone tried Google's go language? ============================================================ 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: [sfx: Discuss] The Go Programming Language
|
|
Oh, I see Pike gave two other talks at OSCON, no video but pdfs of the slides:
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 <[hidden email]> 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. ============================================================ 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: [sfx: Discuss] The Go Programming Language
|
Administrator
|
In reply to this post by Roger Critchlow-2
Thanks, good .. er .. pointers. :)
-- 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: [sfx: Discuss] The Go Programming Language
|
|
I thought they were good references.
;-] ;-] --Doug
On Sat, Jul 24, 2010 at 10:59 AM, Owen Densmore <[hidden email]> wrote:
============================================================ 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: [sfx: Discuss] The Go Programming Language
|
Administrator
|
In reply to this post by Owen Densmore
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#tableThat 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: [sfx: Discuss] The Go Programming Language
|
|
In reply to this post by Douglas Roberts-2
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 <[hidden email]> wrote: I thought they were good references. ============================================================ 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: [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: [sfx: Discuss] The Go Programming Language
|
|
On Sat, Jul 24, 2010 at 12:46 PM, Marcus Daniels <[hidden email]> wrote:
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: [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? 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: [sfx: Discuss] The Go Programming Language
|
Administrator
|
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 ============================================================ 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: [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 <[hidden email]> 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 [hidden email] > To unsubscribe from this group, send email to > [hidden email] > 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: [sfx: Discuss] The Go Programming Language
|
|
In reply to this post by Owen Densmore
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: [sfx: Discuss] The Go Programming Language
|
|
In reply to this post by Owen Densmore
On Sun, Jul 25, 2010 at 9:29 AM, Owen Densmore <[hidden email]> wrote: So .. here's the question, given our current understanding: can Go succeed?I wonder why you chose to show us the 32bit benchmarks: 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 |
«
Return to Friam
|
1 view|%1 views
| Free forum by Nabble | Edit this page |