So, what does everyone think?
Robert Schonberger
Dave
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
Go?
On Nov 11, 12:30 am, Robert Schonberger <rschonber...@gmail.com>
wrote:
Dustin
On Nov 10, 3:30 pm, Robert Schonberger <rschonber...@gmail.com>
wrote:
forward to doing something with since, well, alef.
cmtonkinson
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
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
> 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
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. :)
Benno
applications I think. Looking forward to porting.
On Nov 11, 10:30 am, Robert Schonberger <rschonber...@gmail.com>
wrote:
Abdulla
Eric W.
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
> 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
> 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
> 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
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
> 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
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
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
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
--
puzzler
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
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
> > directly implemented?
>
> You want:
>
> http://golang.org/doc/go_spec.html#Select_statements
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
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
> 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
> 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
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
> Embedding anonymous fields provides a form of inheritance. It's quite
> powerful in practice.
Example? Link suffices.
Aaron
> select {
> case j := <-ch1:
> i = j;
> case f := <-ch2:
> i = int(f);
> }
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
> 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
> 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
> you can think of that Go doesn't have.
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
let try_all methods datum = choose (List.map (fun m -> apply m
datum) methods)
if it matters.
Tim_M
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
wrote:
> I love it! what do people think of Go? what are the 1st questions?
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
> Except if they don't think these features are just nice-to-have
> features instead of core-features of the language.
Except if they think these features are just nice-to-have features
Daniël de Kok
> 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
(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
> I love it! what do people think of Go? what are the 1st questions?
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
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.
