[Proposal] Go: Google's answer to dotNet and Java

[Loughlin-McHugh]

In a fit of intense boredom I've decided that learning Google Go would be a great way to pass the time until Christmas and as everything I do seems to have a weird Ruby dimension the obvious project was a port of TinyRb, a Ruby subset in 2K lines of C. Say hello to RubyGoLightly, a project with absolutely no commercial value :)

As I'm really fired up about the possibilities of Ruby on Google's platform I'd like to talk a bit about this project, Go, TinyRb and anything else that seems to fit.

[David Salgado]

I'd definitely like to hear someone explain what makes Go interesting.

David

2009/11/24 Loughlin-McHugh <loughli...@gmail.com>:

> In a fit of intense boredom I've decided that learning Google Go would be a great way to pass the time until Christmas and as everything I do seems to have a weird Ruby dimension the obvious project was a port of TinyRb, a Ruby subset in 2K lines of C. Say hello to RubyGoLightly, a project with absolutely no commercial value :)
>
> As I'm really fired up about the possibilities of Ruby on Google's platform I'd like to talk a bit about this project, Go, TinyRb and anything else that seems to fit.
>

> --
> http://rubymanor.org
> Group home: http://groups.google.com/group/ruby-manor?hl=en
> Unsubscribe at ruby-manor+...@googlegroups.com
>

[Roland Swingler]

Yes, very much ++ please!

I'd be interested in the TinyRb side especially.

R

[Niko Felger]

+1

[Piers Cawley]

On Tue, Nov 24, 2009 at 9:34 AM, David Salgado <da...@digitalronin.com> wrote:

> I'd definitely like to hear someone explain what makes Go interesting.

That's easy. Rob Pike and Ken Thompson

[Murray Steele]

2009/11/25 Piers Cawley <pdca...@gmail.com>:

> On Tue, Nov 24, 2009 at 9:34 AM, David Salgado <da...@digitalronin.com> wrote:
>> I'd definitely like to hear someone explain what makes Go interesting.
>
> That's easy. Rob Pike and Ken Thompson

Care to enlighten me why the names of two crusty white dudes should
make me care about a new low-level systems language with clumsy syntax
that says nothing to my higher-level abstraction tainted heart? (I've
read through the intro to Go document and just don't see anything I
should care about - what is it that I'm missing?)

Muz

[Hampton]

Uh. I'll hop in here.

As a high-level tainted person myself, I have to say that there is a lot of joy to be had getting
closer to the metal of your machine. Its a nice breath of fresh air and can really help you
with your general abstractions and understandings of development.

Go has some really interesting ideas in it. It seems to have interfaces that actually work,
unlike Java. And, actually having that kind of clarity is actually nice when dealing with
internal and library APIs.

A garbage collected native language? Sounds good to me! I hate doing manual GC
in C.

Don't forget how many libraries that you use in Ruby that are written in native languages.
Obviously a friendlier native language (even if its ugly) is something we could find useful.

Finally, there is the multi-core stuff. Its actually really, really, really easy to write multi-core
programs. Something that Ruby is weak in.

So, my point is that because Go is good at things Ruby is bad at (speed, multi-core, interfaces),
its a nice tool to have in your back pocket, or at least wrap your brain around the paradigms.

-hampton.

[Murray Steele]

If Go's real purpose is a better approach to multi-core programming
what is it that meant it couldn't be done as a powerful abstraction
layer or framework for Java, C, C++ or some other language? Also what
set's Go aside from other languages already flexing their muscles in
the same area: Scala, Erlang et al?

I'm struggling to find a reason to get into Go because to me it seems
dull. What I keep coming back to is that lots of people keep saying
"Oh, yeah, Go is important", but as far as I can tell they're very coy
on why.

I'm willing to admit that it may simply be too early to tell, as I'm
sure there was nothing that exciting about Ruby 1.0 for the programmer
that spent 30mins poking at it before dismissing it as "a weird
looking perl" (which is basically what I've done with Go).

Muz

ps. Massive apologies for derailing this proposal thread with a
personal rant / quest for enlightenment. Maybe my questions could be
answered during a talk with a comparison between C tinyrb and Go
tinyrb? This could also give me some reason to choose Go over C the
next time I need to wire up some low-level library so I can play with
it in Ruby.

2009/11/25 Hampton <hca...@gmail.com>:

[Hampton]

Well, obviously Scala and Erland are functional languages. And no matter how
much people keep claiming that they will take over the world, they are very hard
to get your brain around. And as far as doing concurrent abstraction libraries,
these exist and are either hard to use or have a ton of overhead. The stuff in Ruby
that attempts to solve this background problem have tonnns of overhead.

With Go, these features are *compiled* down right into the processor code making
them far, far, far faster. Plus, you get the advantage of having a syntax that just makes
sense for communcation.

In go, here is how you go do something concurrently:

ch := make(chan int);
go sum(hugeArray, ch);

// ... do something else for a while
result := <-ch;  // wait for, and retrieve, result

And, to help with new syntaxes, this is the rubyfied version.

channel = Channel.new
channel.go(:sum, huge_array)
# Do stuff
result = channel.read

However, I think what's missing... is how efficient this is in Go. You can launch
10,000 concurrent processes (goroutines) in 2 seconds. Plus, you can do this
reading non-blocking if you want. Channels can be shared. Channels can
be passed around and can facilitate conversations between threads.

Its not that this stuff is unique. You can find this paradigm elsewhere.
Its that this time its compiled, native, garbage collected, cheap, imperative
(non-functional), and fast.

-hampton.

[Loughlin-McHugh]

Rob Pike, Ken Thompson and Plan9 :)


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

[Loughlin-McHugh]

On 25 Nov 2009, at 13:26, Hampton wrote:
> ps. Massive apologies for derailing this proposal thread with a
> personal rant / quest for enlightenment. Maybe my questions could be
> answered during a talk with a comparison between C tinyrb and Go
> tinyrb?

I don't know how far my port of TinyRb to Go will have progressed by then, but I'm hopeful that there'll be sufficient code to demonstrate how Go differs from C and why I think it's a good/interesting language for a ruby implementation. So far what has me most intrigued is the iterator idiom which abstracts all the details of multi-core away into libraries and promises enumerators that are multi-core aware in the same way as Apple's Grand Central Dispatch but without the cumbersome retrofitting of blocks onto standard C syntax.

This will of course all be very rough as it's my new toy and I'm far from an expert. My usual caveats about flaky broken code will need to be seriously beefed up :)

> This could also give me some reason to choose Go over C the
> next time I need to wire up some low-level library so I can play with
> it in Ruby.

Right now it's probably not a good choice as it doesn't play nicely with C/C++ and would be troublesome to wrap as a third-party library. However that's something that seems to be being worked on by the dev team.

In the future though this could be the best way to develop native libraries for Android and iPhone as Linux and Darwin are both supported, and on both x86 and arm architectures. Put this together with Google's Native Client (which is hard-wired into my visual cortex as sodium chloride) and we may also be seeing some hint of where both Wave and ChromeOS are heading, although that's pure speculation on my part.