So, what does everyone think?

4293 views
Skip to first unread message

Robert Schonberger

unread,
Nov 10, 2009, 6:30:42 PM11/10/09
to golang-nuts
I love it! what do people think of Go? what are the 1st questions?

Dave

unread,
Nov 10, 2009, 6:35:50 PM11/10/09
to golang-nuts
I certainly like the idea, first question is probably - where is the
debugger? I can't imagine developing in any language these days
without a good debugger.

On Nov 10, 6:30 pm, Robert Schonberger <rschonber...@gmail.com>
wrote:

Gunnar Kriik

unread,
Nov 10, 2009, 7:00:24 PM11/10/09
to golang-nuts
Very interesting! Any chance we get to use existing C libraries from
Go?

On Nov 11, 12:30 am, Robert Schonberger <rschonber...@gmail.com>
wrote:

Dustin

unread,
Nov 10, 2009, 7:01:51 PM11/10/09
to golang-nuts

On Nov 10, 3:30 pm, Robert Schonberger <rschonber...@gmail.com>
wrote:
> I love it! what do people think of Go? what are the 1st questions?

It reminds me a lot of alef. That's something I've been looking
forward to doing something with since, well, alef.

cmtonkinson

unread,
Nov 10, 2009, 7:06:24 PM11/10/09
to golang-nuts
Agreed - wasn't part of the justification [for requiring the language
specification to be minimal] that other tools are then easy to create,
such as debuggers, analyzers, autodocs, etc?

That said - sounds like a very interesting project. I look forward to
seeing how Go gets used in the wild.

Das

unread,
Nov 10, 2009, 7:07:46 PM11/10/09
to golang-nuts


Seems a good candidate for a django or rails framework. In fact the
framework/s and related libs will dictate the use, Go doesn't competes
agains other languages but agains the combination of language and
frameworks (C++ and stl and boost and Qt vs C# and MS stuff for
example).

Let's see,

Das

PS. Can we now ignore D? :)

Adam Langley

unread,
Nov 10, 2009, 7:09:08 PM11/10/09
to Gunnar Kriik, golang-nuts
On Tue, Nov 10, 2009 at 4:00 PM, Gunnar Kriik <gunnar...@gmail.com> wrote:
> Very interesting! Any chance we get to use existing C libraries from
> Go?

We have a couple of examples:
http://code.google.com/p/go/source/browse/misc/cgo/gmp/gmp.go?r=release


AGL

Mac

unread,
Nov 10, 2009, 7:17:37 PM11/10/09
to golang-nuts
the choices of design are interesting. It's using Communicating
Sequential Processes
as the basis for much of the concurrency design. I knew that'd be the
case as soon
as I saw Rob Pike was on the list of the team.

My first reason is "how far along is the language?" I know they called
it experimental.
But at google everything is beta. :)

On Nov 10, 6:30 pm, Robert Schonberger <rschonber...@gmail.com>
wrote:

Benno

unread,
Nov 10, 2009, 9:26:12 PM11/10/09
to golang-nuts
I think it is a win. Will be a very cool language for writing L4
applications I think. Looking forward to porting.

On Nov 11, 10:30 am, Robert Schonberger <rschonber...@gmail.com>
wrote:

Abdulla

unread,
Nov 10, 2009, 9:28:33 PM11/10/09
to golang-nuts
Would you perhaps be a little biased? ;)

On Nov 11, 10:30 am, Robert Schonberger <rschonber...@gmail.com>
wrote:

Eric W.

unread,
Nov 10, 2009, 9:40:09 PM11/10/09
to golang-nuts
If there is one thing I always look at in a new language it's how is
the support for matrix operations. Should we expect native matrix
operations from Go? It's something that's I usually find absolutely
essential to the adoption of a language.

When a language defines a good standard numerical matrix, it allows to
build quickly the necessary mathematical libraries which are then
usually compatible with each other. When no standard is defined, each
library has it's own implementation of matrices, making it hard to
find "one to solve them all".

From the basic principles of Go, I could see my self using it to solve
operational research problems, since they usually benefit from
parallelized execution.

On Nov 11, 12:30 am, Robert Schonberger <rschonber...@gmail.com>
wrote:

Adam Langley

unread,
Nov 10, 2009, 9:41:51 PM11/10/09
to Eric W., golang-nuts
On Tue, Nov 10, 2009 at 6:40 PM, Eric W. <eric.in...@gmail.com> wrote:
> If there is one thing I always look at in a new language it's how is
> the support for matrix operations. Should we expect native matrix
> operations from Go? It's something that's I usually find absolutely
> essential to the adoption of a language.

Are you suggesting a canonical matrix package, or special syntax
support for them also?

The former is certainly a good idea. Patches welcome :)


AGL

Venkatesh Srinivas

unread,
Nov 10, 2009, 9:48:48 PM11/10/09
to golang-nuts
> On Nov 11, 12:30 am, Robert Schonberger <rschonber...@gmail.com>
> wrote:
>> I love it! what do people think of Go? what are the 1st questions?

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
directly implemented?

Thanks,
-- vs

Adam Langley

unread,
Nov 10, 2009, 9:55:37 PM11/10/09
to Venkatesh Srinivas, golang-nuts
On Tue, Nov 10, 2009 at 6:48 PM, Venkatesh Srinivas <m...@acm.jhu.edu> wrote:
> 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
> directly implemented?

You want:

http://golang.org/doc/go_spec.html#Select_statements


AGL

Qwavel

unread,
Nov 11, 2009, 12:16:19 AM11/11/09
to golang-nuts
The thing that surprised me the most when I started reading about Go
was the emphasis on fast compilation (and related requirements, e.g.
simplicity of parsing).

Given the ever increasing processing power available to me when I
program, I'm not too concerned about this, and I'm surprised that it
would be such a fundamental design criteria for a language.

Kai Backman

unread,
Nov 11, 2009, 12:23:12 AM11/11/09
to Qwavel, golang-nuts
On Tue, Nov 10, 2009 at 9:16 PM, Qwavel <qwa...@gmail.com> wrote:
> Given the ever increasing processing power available to me when I
> program, I'm not too concerned about this, and I'm surprised that it
> would be such a fundamental design criteria for a language.

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.

Kai

Jens Alfke

unread,
Nov 11, 2009, 12:23:26 AM11/11/09
to Qwavel, golang-nuts

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.

—Jens

Wilson MacGyver

unread,
Nov 11, 2009, 12:26:55 AM11/11/09
to Qwavel, golang-nuts
The other possibility that comes to me is this.

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.

Ian Lance Taylor

unread,
Nov 11, 2009, 12:33:13 AM11/11/09
to Qwavel, golang-nuts
Qwavel <qwa...@gmail.com> writes:

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.

Ian

Wilson MacGyver

unread,
Nov 11, 2009, 12:37:39 AM11/11/09
to Ian Lance Taylor, Qwavel, golang-nuts
ie, gaining the quick turn around productivity of the dynamic languages :)

--

puzzler

unread,
Nov 11, 2009, 1:08:31 AM11/11/09
to golang-nuts
I just spent the evening reading through all the material on the
golang site.

Go aims to be a modern systems language, replacing C. I applaud the
effort -- a replacement for C is well overdue. However, in that
niche, Go's main competition is the D programming language, so really,
we need to compare Go to D. The D programming language is far more
mature (in 2007 when work on Go was beginning, D had already finalized
its stable 1.0 version, and was moving on to version 2.0) and
basically fulfills all of Go's aspirations such as fast compilation,
fast execution, dynamic-like ease of programming and better support
for concurrent programming. Perhaps due to its maturity, D has a
noticeably more complete set of features than Go. Specifically, the
language designers of D have done a great job of borrowing the best
bits from functional programming paradigms. I don't see any
inspirations from functional programming in Go, which is a shame,
since that seems to be where all the action is these days in terms of
making programming a less error-prone and more pleasurable experience.

Although D is relatively mature, the tools for developing in D are
not, which just goes to show how hard it is to create those sorts of
tools. I imagine that Go is looking at another two or three years,
minimum, before Go-friendly programming tools and IDEs emerge. Which
makes me kind of wish that instead of starting from scratch with Go,
the designers had invested their time building programming tools for
D. Then, we could have our cake and eat it now!

Jens Alfke

unread,
Nov 11, 2009, 1:21:38 AM11/11/09
to puzzler, golang-nuts

On Nov 10, 2009, at 10:08 PM, puzzler wrote:

> 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.

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 implement JavaScript-style objects in about 100 lines of Lua 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.)

—Jens

Aaron

unread,
Nov 11, 2009, 1:22:21 AM11/11/09
to golang-nuts
> > equivalent for Limbo's "alt". Am I missing something, or is this not
> > directly implemented?
>
> You want:
>
> http://golang.org/doc/go_spec.html#Select_statements

Out of curiosity, were Reppy's first-class communication ideas
considered (e.g., Concurrent ML, O'Caml's Event module) at any point
during the design phase?

Suppose, for example, that we have two channels, ch1 and ch2. ch1 is
a channel of ints, while ch2 is a channel of floats. 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)])

It seems that in go, we'd have to select on receiving from each
channel and then check the type of what was received to do the proper
conversion.

While this example is simple, In general, first-class communication
allows hiding channel-based communication under higher-level
constructions that can still be manipulated as communication events.
This style leads to cleaner APIs.

Ian Lance Taylor

unread,
Nov 11, 2009, 1:25:51 AM11/11/09
to puzzler, golang-nuts
puzzler <mark.en...@gmail.com> writes:

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.

Ian

Russ Cox

unread,
Nov 11, 2009, 1:29:26 AM11/11/09
to Aaron, golang-nuts
> Suppose, for example, that we have two channels, ch1 and ch2.  ch1 is
> a channel of ints, while ch2 is a channel of floats.

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;
select {
case j := <-ch1:
i = j;
case f := <-ch2:
i = int(f);
}

Russ

Ian Lance Taylor

unread,
Nov 11, 2009, 1:36:51 AM11/11/09
to Jens Alfke, puzzler, golang-nuts
Jens Alfke <je...@mooseyard.com> writes:

> 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
> implement JavaScript-style objects in about 100 lines of Lua
> 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.

Ian

Peter Froehlich

unread,
Nov 11, 2009, 1:38:57 AM11/11/09
to golang-nuts
Hi all,

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.
:-D

Cheers,
Peter
--
Peter H. Froehlich <http://www.cs.jhu.edu/~phf/>
Senior Lecturer | Director, Johns Hopkins Gaming Lab

Peter Froehlich

unread,
Nov 11, 2009, 1:41:27 AM11/11/09
to golang-nuts
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.

Aaron

unread,
Nov 11, 2009, 1:56:08 AM11/11/09
to golang-nuts
>     var i int;
>     select {
>     case j := <-ch1:
>         i = j;
>     case f := <-ch2:
>         i = int(f);
>     }

Ok, so this case can be handled cleanly. Let's try something more
complex.

(* Attempts to apply big_computation to the data n. *)
let apply big_computation n =
let ch = new_channel () in
(* compute asynchronously; return result on ch *)
let tid = Thread.create big_computation (n, ch) in
(* return an event that either returns the result of computation
* if selected, or kills the created thread if not selected *)
wrap_abort (read ch) (fun () -> Thread.kill tid)

(* Bundles all my methods of computing the result into
* a single event that runs them all concurrently,
* takes the result of the fastest, and kills off the rest. *)
let try_all methods = choose (List.map (fun m -> apply m) methods)

let f = try_all given_methods

Now suppose I'm given a datum n; I just call

sync (f n)

For that matter, suppose I'm given a list of data; I just call

List.map (fun n -> sync (f n)) data

The main features illustrated here are

1. the ability to select on variable numbers of communication events
2. the ability to wrap_abort, i.e., clean up when not selected
3. the ability to abstract away the underlying communication (messy)
to present a clean interface (just try_all in this case)

Ian Lance Taylor

unread,
Nov 11, 2009, 1:59:04 AM11/11/09
to Peter Froehlich, golang-nuts
Peter Froehlich <peter.hans...@gmail.com> writes:

> 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.

http://golang.org/doc/effective_go.html#embedding

Ian

Russ Cox

unread,
Nov 11, 2009, 2:08:30 AM11/11/09
to Aaron, golang-nuts
> (* Attempts to apply big_computation to the data n. *)
> let apply big_computation n =
>  let ch = new_channel () in
>  (* compute asynchronously; return result on ch *)
>  let tid = Thread.create big_computation (n, ch) in
>    (* return an event that either returns the result of computation
>     * if selected, or kills the created thread if not selected *)
>    wrap_abort (read ch) (fun () -> Thread.kill tid)
>
> (* Bundles all my methods of computing the result into
>  * a single event that runs them all concurrently,
>  * takes the result of the fastest, and kills off the rest. *)
> let try_all methods = choose (List.map (fun m -> apply m) methods)

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.

http://golang.org/doc/go_faq.html#Why_doesnt_Go_have_feature_X

Russ

Aaron

unread,
Nov 11, 2009, 2:15:17 AM11/11/09
to golang-nuts
> More generally, you're already an expert on all the things
> you can think of that Go doesn't have.  

On the contrary, I'm simply a user of these programming language
features, not at all an expert. I didn't mean any disrespect; I was
simply curious about the thought process that went into the design,
and it seemed this forum was the place to ask such things. I was
excited to read that Go is embracing message passing (I like the
slogan) and thought I'd see if the designers were in a mood to talk
about their decision-making with respect to this feature.

Happy coding.

Aaron

unread,
Nov 11, 2009, 2:17:56 AM11/11/09
to golang-nuts
> let try_all methods = choose (List.map (fun m -> apply m) methods)

Whoops, I meant
let try_all methods datum = choose (List.map (fun m -> apply m
datum) methods)
if it matters.

Tim_M

unread,
Nov 11, 2009, 2:53:19 AM11/11/09
to golang-nuts
So what about exponentiation. Was that ever considered the right to
it's own operator like how Haskell uses the caret '^'? It's a topic
that has come up a few times within the D community and it seems very
likely that they will be using double caret '^^' for it.

JE

unread,
Nov 11, 2009, 7:21:45 AM11/11/09
to golang-nuts
On Nov 11, 12:30 am, Robert Schonberger <rschonber...@gmail.com>
wrote:
> I love it! what do people think of Go? what are the 1st questions?

IMHO go does not provide two features a modern programming language
needs to provide :

1. Exceptions
2. Templates/Generics

Since these two features have a huge impact on the design of the base
library I really wonder why google would release GO to the public in
this state.
Except if they don't think these features are just nice-to-have
features instead of core-features of the language.

If exceptions and genrics are not core features of a language, I
won't touch the language unless some business case forces me too.

Cheers,
JE

JE

unread,
Nov 11, 2009, 7:25:14 AM11/11/09
to golang-nuts
small typo:

> Except if they don't think these features are just  nice-to-have
> features instead of core-features of the language.
should have been:

Except if they think these features are just nice-to-have features

Daniël de Kok

unread,
Nov 11, 2009, 7:35:34 AM11/11/09
to golang-nuts
On Nov 11, 2009, at 1:21 PM, JE wrote:
> On Nov 11, 12:30 am, Robert Schonberger <rschonber...@gmail.com>
> wrote:
>> I love it! what do people think of Go? what are the 1st questions?
>
> IMHO go does not provide two features a modern programming language
> needs to provide :
>
> 1. Exceptions
> 2. Templates/Generics

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.

Take care,
Daniel de Kok

Sean

unread,
Nov 11, 2009, 8:24:36 AM11/11/09
to golang-nuts
Disclosures: (1) I've watched the video and skimmed the documentation.
(2) Python was obviously invented by people with a pathological hatred
of curly braces, and is just plain loopy.

I think I'd like to see integration with the Google App Engine (GAE)
very early on. The obvious convergence here would be in hitching the
Go concept of decorating any object with methods to the GAE object-
oriented approach to data. This seems like a very powerful if not a
transformative combination. Given the amount of legwork involved in
creating data-driven applications, the up-front savings could be
enough to overcome the downside of adopting an unrefined language.

It would then seem to me you could produce a lot of useful web apps
very quickly with something like...
GAE => Go + GQL => XML serialization => JQuery

So you punt on server-side presentation scripting and the spaghetti
code trap a la ASP/JSP/PHP, but you can still get a lot done.