We have a couple of examples:
Are you suggesting a canonical matrix package, or special syntax
support for them also?
The former is certainly a good idea. Patches welcome :)
It looks a lot like Limbo (and its source tree looks a lot like Inferno :D).
I quickly looked at the channel primitives, but I did not see an
equivalent for Limbo's "alt". Am I missing something, or is this not
As a rough approximation C++ compilation speed grows exponentially
with the size of the codebase. When you have a few million lines of
code to recompile it starts to matter a lot more. An example is
OpenOffice. It takes hours and hours to compile OpenOffice from
sources and it's only 8 million lines of code. Some proprietary
codebases are probably larger.
It's an issue if you build large programs (like a lot of Google's software, not coincidentally.) Try a clean build of Chrome sometime — it takes over an hour on my MacBook Pro.
Say you have small apps/plugins, imagine widgets on
desktop you want to run on native code.
Let's say you have a bunch of devices, some of them are x86
based machines, some are ARM chip machines.
What if, you can "install" the these tiny apps by pushing the
go src, and on the fly compile it? If compile speed is always
very fast. this becomes possible.
and you can "distribute" this single src across the board.
Like say Chrome OS on desktop/netbooks that has
both x86 and ARM cpus.
Omnem crede diem tibi diluxisse supremum.
Besides other answers: when you can build a whole program in less than
a second it permits you to change your workflow in interesting ways.
> Go's main competition is the D programming language, so really, we need to compare Go to D.
I agree; this was my first reaction too when I heard of Go. I have not coded in D, but I've read through the documentation and it looked very good — not as radical a change as Go, but a "C++ done right" with no awkward backward-compatibility issues.
(I'm sure some people will argue that Go's interfaces are object-oriented; but without inheritance, they're not. They're basically equivalent to COM, an architecture I've tried really hard to stay away from.)
I have not done much programming in D, but from reading the docs I
think Go and D really have different goals. D seems to me to be
aiming for a better C++, bringing in all the interesting and useful
features from C++ and even from some other languages. Go is a
language designed from scratch to have relatively few powerful
concepts. It intentionally does not have a lot of features.
This is all just my opinion, of course, and may be wrong-headed.
var ch1 chan int;
var ch2 chan float;
I'm with you so far.
> We'd like to
> receive from whichever one is ready and return the value as an int.
> First-class communication would allow us to do something like
> let the_int = sync (choose [wrap (receive ch1) (fun i -> i); wrap
> (receive ch2) (fun f -> int_of_float f)])
In Go, this isn't all packed onto one line but is largely the same:
var i int;
case j := <-ch1:
i = j;
case f := <-ch2:
i = int(f);
> The deal-breaker for me with Go is the lack of object-oriented
> programming. The only other contemporary language I can think of
> that doesn't support objects is Lua; it's understandable there
> because Lua is meant to be tiny and stripped-down (and you can
> anyway.) For a larger-scale language, leaving out OOP seems kind of,
> well, nuts to me.
> (I'm sure some people will argue that Go's interfaces are
> object-oriented; but without inheritance, they're not. They're
> basically equivalent to COM, an architecture I've tried really hard
> to stay away from.)
Embedding anonymous fields provides a form of inheritance. It's quite
powerful in practice.
On Wed, Nov 11, 2009 at 1:21 AM, Jens Alfke <je...@mooseyard.com> wrote:
> (I'm sure some people will argue that Go's interfaces are object-oriented; but without inheritance, they're not. They're basically equivalent to COM, an architecture I've tried really hard to stay away from.)
Just $0.02: I'd argue that subtype polymorphism (exactly what
interfaces give you) is more central to OOP than inheritance (in the
usual sense of implementation inheritance).
Can you sensibly use inheritance without polymorphism? Kinda hard
since you need to statically decide what method to run at every call
site. Can you sensibly use polymorphism without inheritance? You
betcha, but you may have to write a little more code (for example to
do forwarding instead).
Think of it this way: Using an interface, you "reuse" all the code
that "understands" that interface. Using inheritance, you reuse (some
of) the code from your class up to your base class(es). I doubt that
the path up your class hierarchy contains more code than all the
potential client applications accepting your interface.
Yes, you can make some nice things happen with inheritance, heck I
found a nice way to use a multiply-inherited mixin in Python today,
even made sense remotely in the design. But I can certainly see why
some people would prefer not having to deal with such constructions.
Peter H. Froehlich <http://www.cs.jhu.edu/~phf/>
Senior Lecturer | Director, Johns Hopkins Gaming Lab
Example? Link suffices.
> On Wed, Nov 11, 2009 at 1:36 AM, Ian Lance Taylor <ia...@google.com> wrote:
>> Embedding anonymous fields provides a form of inheritance. It's quite
>> powerful in practice.
> Example? Link suffices.
I don't think Go's model is much different than
what you're writing, it just has a different syntax.
John Reppy and Rob Pike are certainly aware of each
other's work in this area.
More generally, you're already an expert on all the things
you can think of that Go doesn't have. It's much more
interesting to look at the new things Go has.