So, what does everyone think?

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

Faried Nawaz

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

I know it compiles very quickly and all, but I really wish it had a
repl. When I'm trying to interface with a website's API, or dealing
with XML or JSON data, being able to incrementally write code to
extract what I need makes me very productive.

Qwavel

unread,
Nov 11, 2009, 10:23:55 AM11/11/09
to golang-nuts
Thanks for all the responses to my posting. They have focused on the
need for speed on the biggest systems projects.

I'm not sure about this, but I would have thought that 90% of systems
development work (the sort of stuff that C/C++ is currently used for)
is systems applications which are either small or medium in size and
are becoming reasonably quick to compile, particularly with the
techniques of distributed compilation.

Even for the very largest systems' projects, I'd like to think that
the entire project doesn't have to be recompiled too often.

Perhaps what I was missing is that the Go language is specifically
designed for those 'largest' projects - projects that Google probably
has quite a few of.

Wilson MacGyver

unread,
Nov 11, 2009, 10:27:24 AM11/11/09
to JE, golang-nuts
They address why Go doesn't have exception in

http://golang.org/doc/go_lang_faq.html#exceptions

--

Andrew Sledge

unread,
Nov 11, 2009, 10:33:04 AM11/11/09
to golang-nuts
Where can I get one of those Go T-Shirts (ref: http://www.youtube.com/watch?v=wwoWei-GAPo)?

:)

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

Evan Behar

unread,
Nov 11, 2009, 10:34:28 AM11/11/09
to golang-nuts
Why the decision to make the export condition an upper-case first
symbol?

It seems to me that this implies that if I decide to make a non-
exported symbol exported later, or vice-versa, I then have to change
all references to it within the package to match the new name, instead
of making a single-location change. This seems like a pretty big
hassle.

Jason Catena

unread,
Nov 11, 2009, 10:54:23 AM11/11/09
to Qwavel, golang-nuts
On Wed, Nov 11, 2009 at 09:23, Qwavel <qwa...@gmail.com> wrote:
> I'm not sure about this, but I would have thought that 90% of systems
> development work (the sort of stuff that C/C++ is currently used for)
> is systems applications which are either small or medium in size and
> are becoming reasonably quick to compile, particularly with the
> techniques of distributed compilation.
>
> Even for the very largest systems' projects, I'd like to think that
> the entire project doesn't have to be recompiled too often.

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
half-done work).

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.

Jason Catena

JE

unread,
Nov 11, 2009, 11:35:20 AM11/11/09
to golang-nuts


On Nov 11, 4:27 pm, Wilson MacGyver <wmacgy...@gmail.com> wrote:
> They address why Go doesn't have exception in
>
> http://golang.org/doc/go_lang_faq.html#exceptions
>
>

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
messy.
If they have a new concept that replaces exceptions, they should
figure it out before substantial code is written.

Ian Lance Taylor

unread,
Nov 11, 2009, 11:54:46 AM11/11/09
to Tim_M, golang-nuts
Tim_M <tim.ma...@gmail.com> writes:

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.

Ian

Ian Lance Taylor

unread,
Nov 11, 2009, 11:55:56 AM11/11/09
to Sean, golang-nuts
Sean <seanvo...@gmail.com> writes:

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

Ian

Michael C Smith

unread,
Nov 11, 2009, 12:10:44 PM11/11/09
to golang-nuts
On Nov 10, 6:41 pm, Adam Langley <a...@golang.org> wrote:

(regarding a matrix package)

>
> Are you suggesting a canonical matrix package, or special syntax
> support for them also?
>
> The former is certainly a good idea. Patches welcome :)

I would happily assist in such a project. (I'm also working on a
complex number library now, btw)

Please keep me in the loop. :)

>
> AGL

Mike Smith

Sverre Rabbelier

unread,
Nov 11, 2009, 12:16:39 PM11/11/09
to Ian Lance Taylor, Sean, golang-nuts
Heya,

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
Go?

--
Cheers,

Sverre Rabbelier

BigPilot

unread,
Nov 11, 2009, 1:26:39 PM11/11/09
to golang-nuts

On Nov 11, 12:30 am, Robert Schonberger <rschonber...@gmail.com>
wrote:
> I love it! what do peoplethinkof Go? what are the 1st questions?

My first question would be: why didn't Google ask developers what they
wanted in a new computer language instead of allowing a couple of
geeks to come up with yet-another-C-like-language?

Of all the C-like languages, I like C# by far the best. It has all the
good things of C++ without the complexity, the header files and a
simple and intuitive syntax (for experienced C / C++ developers, at
least). The only thing I miss in C# is C++'s execution speed. If
Google had asked me what kind of language that I'd wanted them to
create I'd have said: a C# clone with a native compilation and a cross-
platform GUI similar to wxWidgets (i.e. native widgets, not self
drawn) and a framework library like .NET and C/C++ interop
capability.For me that would be programming heaven.

I don't like Go's syntax which looks different just to be different
for no good reason. I don't see any groundbreaking innovations in it
that would warrant me to learn yet another language.

Just my $0.02.

Iain A F Fleming

unread,
Nov 11, 2009, 1:34:01 PM11/11/09
to BigPilot, golang-nuts
BigPilot writes:
>
> My first question would be: why didn't Google ask developers what
> they wanted in a new computer language instead of allowing a couple
> of geeks to come up with yet-another-C-like-language?

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

--
Nec tecum possum vivere nec sine te

atomly

unread,
Nov 11, 2009, 1:35:50 PM11/11/09
to JE, golang-nuts
On Wed, Nov 11, 2009 at 11:35 AM, JE <jed...@gmail.com> wrote:
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
messy.
If they have a new concept that replaces exceptions, they should
figure it out before substantial code is written.

More than Exceptions, I'd like to see support for Erlang-style fault-tolerance.

--
:: atomly ::

[ ato...@atomly.com : www.atomly.com  : http://blog.atomly.com/ ...
[ atomiq records : new york city : +1.917.442.9450 ...
[ e-mail atomly-new...@atomly.com for atomly info and updates ...

Ian Lance Taylor

unread,
Nov 11, 2009, 1:42:33 PM11/11/09
to Sverre Rabbelier, Sean, golang-nuts
Sverre Rabbelier <srabb...@gmail.com> writes:

I think we would want to lift that limitation for Go. (I'm actually
not that familiar with AppEngine personally.)

Ian

Edmon Begoli

unread,
Nov 11, 2009, 1:52:26 PM11/11/09
to golang-nuts
I think that language is beautiful. I posted a moment ago that I want to do my dissertation work in it.
I think that the adoption or the lack of will make all the difference.

I was a big supporter of GWT, and I thought that it was great for Java programmers. I have observed however that poor general 
adoption was a major impediment to further innovation of this framework. 

Is there an issue with internal competition with Guido Van Rossum and his work with Python?

-Edmon

Sverre Rabbelier

unread,
Nov 11, 2009, 1:52:27 PM11/11/09
to Ian Lance Taylor, Sean, golang-nuts
Heya,

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?

--
Cheers,

Sverre Rabbelier

mat42

unread,
Nov 11, 2009, 2:09:41 PM11/11/09
to golang-nuts
I love the attempt to create a language to rule them all ;-)
But in my Opinion Go is a bit too focused on easy code writing and too
little focused on large scale projects. And many small programs turn
into large projects without anyone noticing. Here is my judgment:
++ great ideas for concurrency
+ garbage collection is useful for a wide range of applications
+ programmer's choice between heap and stack allocated memory
+ dropping pointer arithmetic is compiler friendly
+ support for closures
-- compile time type checking is problematic with implicit inheritance
and without compile-time template mechanism
- interfaces allow virtual functions, anonymous members mimic
inheritance => this sounds like nightmare refactoring to me
- inconsistencies between built-in and custom types (ex: make() seems
like a constructor for built-in types only)

I guess the unified programming language is still to come but Go is a
great approach! I am looking forward to a language with Go's great
concurrency features and memory model combined with more conservative
class hierarchy features and strong compile-time checks. I am unsure
whether both compile-time templates and fast compilation are
realizable...

Sean Vostinar

unread,
Nov 11, 2009, 2:10:24 PM11/11/09
to Sverre Rabbelier, Ian Lance Taylor, Sean, golang-nuts
Being that the App Engine is a dessert topping and a floor wax and a floor
on which to eat desserts topped with wax, specific goals of "integration"
probably need definition before anyone can even think about these kinds of
nuances.

My goal, which started this tangent: Data as objects, not in Python. :)

Jason Catena

unread,
Nov 11, 2009, 2:18:56 PM11/11/09
to mat42, golang-nuts
> I love the attempt to create a language to rule them all ;-)
> I guess the unified programming language is still to come but Go is a
> great approach!

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.

Jason Catena

Don Dailey

unread,
Nov 11, 2009, 3:13:42 PM11/11/09
to golang-nuts
It's really cool.

The obvious comparison is probably to digital mars D which is clearly
more mature but in my view too heavy. This is a rethink and
definitely not just C repackaged. I like and prefer than it's
less.

I'm troubled by the windows thing. I am not a fan of windows, I'm a
Linux person all the way. But I do believe in cross platform
compatibility and I like to be able to develop on Linux and distribute
to windows people. That's not a deal breaker for me, but it
might be for Go. At some point I think this will have to be
supportive of windows to get legs.

The other issue is that I am a perfromance freak so I would love to
see the quality of the compiler match and exceed C. In my view this
would guarantee it's acceptance as the "new C" or the new systems
programming language. Even if C remains 5% faster it will be seen
as the real thing and this will be seen as a wanna-be or alternative
to the real thing. I don't think it SHOULD be that way, but I
believe it WILL be that way.

As far as I'm concerned I'm behind this all the way. I wonder if
any GUI libraries are in the works?

- Don



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

Qwavel

unread,
Nov 11, 2009, 3:35:04 PM11/11/09
to golang-nuts

It's great to have yet another language option! I'm just sorry that
we haven't been able to establish some standards to allow for greater
Interoperability!

I'm not talking about going as far as Microsoft's dotNet in this
regard, but it would be nice to have some basic standard interfaces,
types, and formats that would allow C++, D, and Go applications to
interact with each other - on Linux at least - in the same way that
these languages can currently call into C.

Ranganathan Sankaralingam

unread,
Nov 11, 2009, 3:37:49 PM11/11/09
to golang-nuts
Go has a lot of things which I would put into my own language if were
not so lazy. :) Bravo.

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
Erlang; things
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.

2. Crashproofing?

A second major advantage of Erlang is that it guarantees that a
badly-written process
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.

Ranga

ReaanB

unread,
Nov 11, 2009, 3:43:49 PM11/11/09
to golang-nuts
Oh wow! There are so many great things in Go. I hardly know what to
play with first! Above all, I love the excellent type system. The
world needed something as good as this. Thank you.

One question / complaint: map is nice, but I want Date and Darwin
style first-class relations. ;)

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

John

unread,
Nov 11, 2009, 3:49:52 PM11/11/09
to golang-nuts
The need for a new widely adopted language that can simplify multicore/
multiprocessor development is long overdue. And I think that good
questions are being addressed in the thought and development.
Breaking things down, taking steps back and looking at making things
simple is very important. Look at the CELL chip. That was a wide
departure from x86 and brilliant. But the tools suck. Opening a pipe
to on of 6 SSEs to execute code is ridiculous.

Not sure what I am going to develop with it yet. But porting some
machine learning libs would probably be my first go...:) K-means
cluster?

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

Ian Lance Taylor

unread,
Nov 11, 2009, 4:17:41 PM11/11/09
to Edmon Begoli, golang-nuts
Edmon Begoli <ebe...@gmail.com> writes:

> I think that language is beautiful. I posted a moment ago that I want to do
> my dissertation work in it.

Thanks!

> I think that the adoption or the lack of will make all the difference.

Yes.

> Is there an issue with internal competition with Guido Van Rossum and his
> work with Python?

No, Google works on lots of different things.

Ian

Michael Bernstein

unread,
Nov 11, 2009, 4:20:13 PM11/11/09
to golang-nuts
This is pretty straightforward and simple - but it seems to be a good
starting point in trying to understand the inner-workings of Go. I
might be too entrenched in my ways of thinking (I figured you'd use a
for loop to replace a while loop and you'd get the body returned in
chunks of bytes) and I might not realize what's going on - but in
regards to Go, how does one consume io Readers? I don't like throwing
something out and saying hey - what did I do wrong? However, with the
sparse documentation, I figured it might help others as well.

package main

import "fmt"
import "http"

func main() {
s := "http://www.michaelbernstein.info/";
r,_,_ := http.Get(s);
if r != nil {
var z []byte;
n := -1;
for n != 0 {
n, _ = r.Body.Read(z);
fmt.Printf("len(z) is %d\n", len(z));
}
r.Body.Close();

}
else
{
fmt.Printf("Error Occured somewhere\n");
}
}


Michael Bernstein
mnber...@gmail.com

Ian Lance Taylor

unread,
Nov 11, 2009, 4:21:39 PM11/11/09
to Ranganathan Sankaralingam, golang-nuts
Ranganathan Sankaralingam <ranga...@gmail.com> writes:

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

Not at present. However, the lack of pointer arithmetic, and array
bounds checking, make it hard for one goroutine to crash another
accidentally.

Ian

Ian Lance Taylor

unread,
Nov 11, 2009, 4:23:27 PM11/11/09