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.
3. structs as the key type for built-in maps
That said, I find the Go developers courageous for leaving a lot of stuff out. I like the D language which attempts to provide a modern C++, but it seems to be falling in the same complexity trap as C++.
From a quick initial look, it seems to be a nice middle ground between the relative simplicity of C and means of abstraction in C++/Java.
Daniel de Kok
You might not believe how fast development of a large telecom system
in C/C++ can get bogged down by its build process, especially one
which generates code from a few models and little languages. Serious
development time, expensive tools, dedicated hardware, just to keep it
sane. Incremental builds definitely help, but create a tradeoff where
you take a big hit every time the view into the codebase becomes
corrupt, or you make a new one (daily, since you also want everyone
working in isolated views so they're not debugging each other's
Key improvements in Go that make it suited for large systems work
(IMO): easy threadish management and communication, an inherently
fast/scalable build system that explicitly manages its dependencies,
almost-C syntax, and imperative semantics (read: understood by today's
systems engineers, vs functional Haskell with different/cleaner syntax
and trickier/pure I/O).
To me, the cost of transitioning to the language pale next to the cost
and effort put into making big systems build fast. When Go is
available for the types of platforms on which big systems are done
(eg, Linux or a proprietary OS on a PowerPC), I'd be surprised if it's
not seriously considered.
We have not discussed an exponentiation operator. The language is not
set it stone, but I'm not sure an exponentiation operator would be
appropriate for a language like Go.
> I think I'd like to see integration with the Google App Engine (GAE)
> very early on.
We are also interested in App Engine integration and we hope it will
happen reasonably soon.
On Wed, Nov 11, 2009 at 17:55, Ian Lance Taylor <ia...@google.com> wrote:
> We are also interested in App Engine integration and we hope it will
> happen reasonably soon.
Wouldn't that terribly cripple Go, as AppEngine allows only
single-threaded apps? Or would you want to lift that limitation for
Well, the last time Ken Thompson (one of the three designers of Go)
came up with a language we got C. I'd put my money on him, and his
ability, rather than a popularity poll of random developers.
Languages designed by committes are never pretty - Fortran, COBOL,
Nec tecum possum vivere nec sine te
Yes, but their explanation is the problem. They say:
>they have profound effect on library and interface specification
So if you leave out exceptions and add them in later,
all code , base libraries and so on, using the "old go version without
exceptions" will become legacy code compared
to the "new code" with exceptions. That scenario will be very very
If they have a new concept that replaces exceptions, they should
figure it out before substantial code is written.
I think we would want to lift that limitation for Go. (I'm actually
not that familiar with AppEngine personally.)
On Wed, Nov 11, 2009 at 19:42, Ian Lance Taylor <ia...@google.com> wrote:
> I think we would want to lift that limitation for Go. (I'm actually
> not that familiar with AppEngine personally.)
I think the restriction is mainly to make it easier to do resource
tracking, but I don't know the details (ask appengine team @google I'd
guess :P). Also, how would go deal with DeadlineExceededException?
AppEngine limits apps to 30s of execution time, with no exception
support in go there'd be no way to deal with that?
My goal, which started this tangent: Data as objects, not in Python. :)
I missed this in the list of Go's goals.
Personally, I'm looking forward to a bunch of people deciding Go isn't
elaborate enough for them, and going away, so everyone else can spend
time getting work done with it instead of attacking and defending it.
(For example, if you can write Go programs in Unicode, why doesn't it
use APL operators? Surely they're more complete, and it would make Go
ever so much more succinct and useful.)
Hopefully the remaining community will be larger than Plan 9's and Inferno's.
1. Lightweight Processes Only on the Same Machine?
I'd read the Erlang book, but the language is too far removed from my
expertise for me
to pursue it seriously. I wished for somebody to bolt Erlang's
lightweight process idea
onto a C-like language (which is imho the only major good thing about
like "matching" and single-assignment just don't make sense to me).
Looks like the Go
team was thinking along similar lines!
A key limitation I see is that the communicating processes have to be
on the same machine.
Due to lack of operator overloading, this cannot be fixed by libraries
and still maintain
the same syntax as local channels.
I hope this gets added that at some point.
A second major advantage of Erlang is that it guarantees that a
cannot crash other processes. That allows a Erlang program consisting
of a single OS process
to monitor itself and restart components that crash.
I dont think Go can provide such strong guarantees. You'll need an
external program to monitor
the running process. This increases deployment pain.
I wonder if this can be addressed since Go is a compiled language. Are
there OS and CPU
facilities that can be used to wall off goroutines from each other?
3. Love the lack of type conversion (int -> long long etc).
I just debugged a nasty problem to do with implicit shifting in 32
bits instead of 64.