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.
Wilson MacGyver
Andrew Sledge
:)
On Nov 10, 6:30 pm, Robert Schonberger <rschonber...@gmail.com>
Evan Behar
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
> 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
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
>
>
>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
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
> 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
(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
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
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
>
> 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
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
I think we would want to lift that limitation for Go. (I'm actually
not that familiar with AppEngine personally.)
Ian
Edmon Begoli
Sverre Rabbelier
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
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
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
> 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
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
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
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
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
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
> 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
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
> 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
I think that we have is the C calling interface as a defacto standard.
For more complex issues we have programs like swig.
I agree that more work could be done in this area.
Ian
Wilson MacGyver
go. What sort of "gotcha" should I pay attention to?
On Wed, Nov 11, 2009 at 4:23 PM, Ian Lance Taylor <ia...@google.com> wrote:
>
> I think that we have is the C calling interface as a defacto standard.
>
> For more complex issues we have programs like swig.
>
> I agree that more work could be done in this area.
>
> Ian
>
--
Omnem crede diem tibi diluxisse supremum.
Antoine Chavasse
interesting. Lacking exceptions is bad but the multiple return values
+ the standardized error interfaces seems like it can cover a lot of
what's missing there.
I'm not sure that template/generics are really that needed given how
the type system works, provided that compilers can seize opportunities
to resolve types at compilation time when possible (for instance if a
function takes a parameter that needs to be a certain interface, if
you call it with values of completely different types that all
implement that interface, does the compiler generate one version of
the function for each type?)
My pet project currently is a game engine written in C++ with
javascript bindings for game scripting etc. and actually I believe
that goroutines/channels would be awesome for the purpose of scripting
game objects. Since the compiler is very fast, I was wondering if
there's any plan to include it as a package, allowing to compile go
code at runtime? Maybe the exp.eval is planned to become such a thing?
That would be pretty awesome.
John Cowan
> I'm not sure that template/generics are really that needed given how
> the type system works, provided that compilers can seize opportunities
> to resolve types at compilation time when possible (for instance if a
> function takes a parameter that needs to be a certain interface, if
> you call it with values of completely different types that all
> implement that interface, does the compiler generate one version of
> the function for each type?)
No. An interface is a run-time object: a pointer to the underlying
primitive or struct plus a pointer to the vtable for this interface.
It's essentially pure runtime polymorphism separate from any
considerations of data storage or layout. Consequently, there's
nothing you can do with an interface but invoke one of its methods.
--
GMail doesn't have rotating .sigs, but you can see mine at
http://www.ccil.org/~cowan/signatures
Nigel Tao
pass it. Try:
package main
import "fmt"
import "http"
import "os"
func main() {
s := "http://www.golang.org/";
r, _, err := http.Get(s);
if err != nil {
fmt.Printf("Error: %v\n", err);
return;
}
var buf [4096]byte;
for {
n, err := r.Body.Read(buf[0:len(buf)]);
if err != nil && err != os.EOF {
fmt.Printf("Error: %v\n", err);
return;
}
fmt.Printf("%d bytes were read\n", n);
if err == os.EOF {
break;
}
}
r.Body.Close();
}
Michael Bernstein
bytes and there are only say, 200bytes - it doesn't return the 200
bytes in the buffer (I think at least?). I'll take a look at it, it
could just be that Printf won't output the slice if it's not properly
terminated or something.
package main
import "fmt"
import "http"
import "os"
func main() {
s := "http://www.golang.org/";
r, _, err := http.Get(s);
if err != nil {
fmt.Printf("Error: %v\n", err);
return;
}
var buf [1]byte;
for err != os.EOF {
_, err = r.Body.Read(buf[0:len(buf)]);
fmt.Printf("%s", buf[0:len(buf)]);
if err != nil && err != os.EOF {
fmt.Printf("Error: %v\n", err);
return;
}
}
r.Body.Close();
}
vs.
package main
import "fmt"
import "http"
import "os"
func main() {
s := "http://www.golang.org/";
r, _, err := http.Get(s);
if err != nil {
fmt.Printf("Error: %v\n", err);
return;
}
var buf [4096]byte;
for err != os.EOF {
_, err = r.Body.Read(buf[0:len(buf)]);
fmt.Printf("%s", buf[0:len(buf)]);
if err != nil && err != os.EOF {
fmt.Printf("Error: %v\n", err);
return;
}
}
r.Body.Close();
}
Michael Bernstein
mnber...@gmail.com
Nigel Tao
> _, err = r.Body.Read(buf[0:len(buf)]);
> fmt.Printf("%s", buf[0:len(buf)]);
I don't think you should print buf[0:len(buf)], you should instead
print buf[0:n], where n replaces the _ in the previous line (i.e. n is
the number of bytes read).
I'm not sure if that will fix all your problems, but that's at least
one problem.
Another thing (off the top of my head) is that you might, after the
for loop, try printing a "\n" to see if that flushes anything. That
might just be total crack, though.
Michael Bernstein
clarify my previous email in which I totally failed, you'd pretty much
want
n, err := r.Body.Read(&buf);
fmt.Printf("%s", buf[0:n]);
Michael Bernstein
mnber...@gmail.com
Ian Lance Taylor
> This leads me to an interop question. When calling c routine from
> go. What sort of "gotcha" should I pay attention to?
If you pass a pointer to C, make sure you keep a copy in Go, since
otherwise Go's garbage collector might pick it up.
C routines run in their own thread.
Ian
Michael Bernstein
ignoring the number of bytes being returned...That was pretty much
every problem other then go not wanting to grab a page with the
default os x firewall active. But that's another issue entirely
unrelated to the buffering.
Thanks for the help.
Michael Bernstein
mnber...@gmail.com
Ian Lance Taylor
> My pet project currently is a game engine written in C++ with
> javascript bindings for game scripting etc. and actually I believe
> that goroutines/channels would be awesome for the purpose of scripting
> game objects. Since the compiler is very fast, I was wondering if
> there's any plan to include it as a package, allowing to compile go
> code at runtime? Maybe the exp.eval is planned to become such a thing?
> That would be pretty awesome.
We have thought about that sort of thing, but nothing concrete yet.
Ian
Wilson MacGyver
--
Ian Lance Taylor
> On Wed, Nov 11, 2009 at 4:43 PM, Antoine Chavasse <a.cha...@gmail.com> wrote:
>
>> I'm not sure that template/generics are really that needed given how
>> the type system works, provided that compilers can seize opportunities
>> to resolve types at compilation time when possible (for instance if a
>> function takes a parameter that needs to be a certain interface, if
>> you call it with values of completely different types that all
>> implement that interface, does the compiler generate one version of
>> the function for each type?)
>
> No. An interface is a run-time object: a pointer to the underlying
> primitive or struct plus a pointer to the vtable for this interface.
> It's essentially pure runtime polymorphism separate from any
> considerations of data storage or layout. Consequently, there's
> nothing you can do with an interface but invoke one of its methods.
To be precise, you can also convert it another interface or back to
its dynamic type.
Ian
Jason
failed because of that, and I didn't see any proxy support in the http
package.
-Jason
Jason
process?
-Jason
On Nov 11, 1:21 pm, Ian Lance Taylor <i...@google.com> wrote:
Harshal Baviskar
Especially liked ideas to make code more concise, channels and go
routines, absence of pointer headache. It is enough for me to look
into this language seriously for serve side programming.
However one thing that I would like to see before I start coding in
database connectivity. Would like to know if, how and when it is
planned.
- Harshal
On Nov 11, 4:30 am, Robert Schonberger <rschonber...@gmail.com>
Jason
pretty nice (although maybe not as novel as the authors think; a lot
of us have used Objective-C, you know!). I don't mind the
implementation of inheritance, because, hey, that's how it looks at a
low-level anyway, and the syntactic sugar of "raising" internal
anonymous type methods to the top is a perfectly fine substitute, as
far as I'm concerned. Could be a pain if two anonymous type members
implement the same method, but that's a problem that any multiple-
inheritance system has, too, and at least it's pretty clear how to
resolve it in Go.
Re: exceptions, I think they are a total pain no matter what. I mean,
it's error checking. It's not sexy. I just wrote my first method that
returns os.Error, and at least you can't easily ignore it (since now
the method returns the (value, os.Error) tuple). You _could_
explicitly ignore it (e.g. v, _ = o.myErrorMethod()), but you would be
doing so at your own risk. But how many times have you written "try{ }
catch (Exception e) { ; }"? Same deal, only it's only one
character. :)
It's not that hard to emulate the "stop executing and pop the stack"
behavior (e.g. in Java). Instead of "try/catch/[finally]" it's
"[defer]/os.Error,goto/return". It just a lot more explicit, including
popping exceptions up the stack. Here's an example (at the risk of
showing an anti-pattern; but I'm sure I'll be corrected if that
happens!):
func f() os.Error {
defer func() { /* do cleanup */ }();
d,err := g(x);
if err != nil { goto error; }
// Do something with d, possibly repeating the pattern
return nil;
error:
// Or, panicln(err)?
fmt.Println(err);
return err;
}
OTOH, I'm not convinced about the whole type safety thing. Any time
you have unbridled direct access to the members of a struct, you can't
have complete type safety. Types include parameters, such as valid
values, and it appears this sort of thing is extremely difficult to
validate in Go.
Speaking of this, working on my toy system, I found that the ", ok"
technique was really valuable. I was playing with rendering days of
the week and was pleasantly surprised when this construct worked:
func (d dayOfWeek) String() string {
s, ok := dayNames[d];
if ( ok ) {
return s;
}
return "Unknown";
}
Of course, I'd _like_ to have _any_ way to restrict my "day of the
week" value to be within the valid range of 0-6. There just doesn't
seem to be a way to do this, or even to reliably make the user of the
class do something ugly to set off alarm bells. For example, one thing
I tried to do was this:
func NewDay(dow DayOfWeek) *Day {
return &Day{ dayOfWeek(dow) };
}
Where I have a set of "DayOfWeek" (note initial caps) const defined.
But I can happily just pass in "8" without even having to typecast it!
Without constructors, I think this is going to create some major pain
(or at least not solve this pain where other languages do).
Also, don't take this as a criticism of not having enum types, which
would solve this case, but it appears to be a global problem. Let's
say I have a struct with a URL string in it. The caller can set that
to whatever crazy value they want with zero validation (until possibly
_much_ later; this is a Heisenbug waiting to happen). This seems to be
a problem with the object-orientation of Go.
I've had some success with a factory function and a public interface/
private implementation. Is this the way we do encapsulation in Go?
-Jason
On Nov 10, 3:30 pm, Robert Schonberger <rschonber...@gmail.com>
Ian Lance Taylor
> Does this mean a system trap in a goroutine won't kill the whole
> process?
Fair point, currently a division by zero or something like that will
kill the entire process.
Ian
Sverre Rabbelier
On Thu, Nov 12, 2009 at 01:32, Jason <jki...@gmail.com> wrote:
> I've had some success with a factory function and a public interface/
> private implementation. Is this the way we do encapsulation in Go?
Mhhh, Misko Hevery often rants about the abuse of 'new' in say Java,
where people should only be using it to construct basic data types,
and should be using a factory pattern (or such) otherwise. Looks like
this is pretty much what Go encourages, sweet.
--
Cheers,
Sverre Rabbelier
Ian Lance Taylor
> However one thing that I would like to see before I start coding in
> database connectivity. Would like to know if, how and when it is
> planned.
We have no specific plans but several people have expressed an
interest in it. I would encourage somebody to propose a plan for how
it should be done.
Ian
Robert Griesemer
At a high level, I like the language. Dynamic interface matching is
pretty nice (although maybe not as novel as the authors think; a lot
of us have used Objective-C, you know!). I don't mind the
Speaking of this, working on my toy system, I found that the ", ok"
technique was really valuable. I was playing with rendering days of
the week and was pleasantly surprised when this construct worked:
func (d dayOfWeek) String() string {
s, ok := dayNames[d];
if ( ok ) {
return s;
}
return "Unknown";
}
Of course, I'd _like_ to have _any_ way to restrict my "day of the
week" value to be within the valid range of 0-6. There just doesn't
seem to be a way to do this, or even to reliably make the user of the
class do something ugly to set off alarm bells. For example, one thing
I tried to do was this:
func NewDay(dow DayOfWeek) *Day {
return &Day{ dayOfWeek(dow) };
}
Where I have a set of "DayOfWeek" (note initial caps) const defined.
But I can happily just pass in "8" without even having to typecast it!
Without constructors, I think this is going to create some major pain
(or at least not solve this pain where other languages do).
Also, don't take this as a criticism of not having enum types, which
would solve this case, but it appears to be a global problem. Let's
say I have a struct with a URL string in it. The caller can set that
to whatever crazy value they want with zero validation (until possibly
_much_ later; this is a Heisenbug waiting to happen). This seems to be
a problem with the object-orientation of Go.
I've had some success with a factory function and a public interface/
private implementation. Is this the way we do encapsulation in Go?
Jeek Elemental
Going by author list it should be very good.
I wish the name could be different tho, very noisy to search for.
On Nov 11, 12:30 am, Robert Schonberger <rschonber...@gmail.com>
Jason
On Nov 11, 4:59 pm, Robert Griesemer <g...@golang.org> wrote:
right? So there is only encapsulation if you access the field by name.
> On a related note (if this is a concern), note that even though one does not
> have to specify that a type T "implements" a type T0 as in other languages,
> you can get the same effect in Go by simply declaring a dummy method "IsT0"
> (which is empty and has no result) in the interface of T0 and then all types
> T that are compatible with T0 must implement "IsT0". Thus, the IsT0 plays
> exactly the same role as "implements T0", say in Java; but there is actually
> no need for a separate language construct. You can make that name (IsT0)
> arbitrarily obscure and thus pretty much ensure that nobody implements an
> interface "accidentally".
>
concern, at least for the kind of code I normally write. If someone
else implements the interface methods, it's up to them and the caller
to get it right. I could imagine wanting "authenticated" code, for
example (a known implementation of the interface), but I think that's
another orthogonal problem. ;)
>
>
> > Speaking of this, working on my toy system, I found that the ", ok"
> > technique was really valuable. I was playing with rendering days of
> > the week and was pleasantly surprised when this construct worked:
>
> > func (d dayOfWeek) String() string {
> > s, ok := dayNames[d];
> > if ( ok ) {
> > return s;
> > }
>
> > return "Unknown";
> > }
>
> > Of course, I'd _like_ to have _any_ way to restrict my "day of the
> > week" value to be within the valid range of 0-6. There just doesn't
> > seem to be a way to do this, or even to reliably make the user of the
> > class do something ugly to set off alarm bells. For example, one thing
> > I tried to do was this:
>
> > func NewDay(dow DayOfWeek) *Day {
> > return &Day{ dayOfWeek(dow) };
> > }
>
> > Where I have a set of "DayOfWeek" (note initial caps) const defined.
> > But I can happily just pass in "8" without even having to typecast it!
> > Without constructors, I think this is going to create some major pain
> > (or at least not solve this pain where other languages do).
>
> Yes, this is a difficult area. enums solve some of these problems but in
> turn cause many others. We hope that being able to have your own "MyInt"
> type and use it with methods defined on it (that may have to check the valid
> range) gets you enough safety w/o being too restrictive or unusable in
> practice.
>
type. E.g.:
type DayOfWeek int
const {
Sunday DayOfWeek = iota;
// blah, blah...
}
func f(dow DayOfWeek) {
// Blah
}
f(42); // Compiler should fail, no? C'mon, I'm trying here by giving
you all those const...
f(DayOfWeek(42)); // Okay, buddy, you're on your own, then, if you
_insist_
>
>
> > Also, don't take this as a criticism of not having enum types, which
> > would solve this case, but it appears to be a global problem. Let's
> > say I have a struct with a URL string in it. The caller can set that
> > to whatever crazy value they want with zero validation (until possibly
> > _much_ later; this is a Heisenbug waiting to happen). This seems to be
> > a problem with the object-orientation of Go.
>
> > I've had some success with a factory function and a public interface/
> > private implementation. Is this the way we do encapsulation in Go?
>
> That is one way of handling access control. If you don't care about
> separating the actual implementation from the interface, you can just export
> (capitalize) the type, fields, and methods that you want to have accessible
> outside your package. So, for instance:
>
> package MyPackage
>
> type ExportedType struct {
> ExportedField int;
> privateField float;
>
> }
>
> func (x *ExportedType) ExportedMethod() {...}
> etc.
>
> So you got very fine-grained export control - on the identifier level. The
> rule's easy: If the first letter is not capitalized, you can't access it
> from another package. You can even have factory functions that return a
> non-exported type that contains exported fields; i.e. you cannot declare a
> variable of that name because the name is not accessible, but you can access
> the fields of a value of that type if returned to you.
door that allows you to violate the rules (curly-brace
initialization). Seems like a problem.
Ian Lance Taylor
> 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.
Yes, we thought about that. In the end we felt that the convenience
of being able to see immediately whether a type or variable is
exported outweighed that issue.
Ian
Ian Lance Taylor
> Where can I get one of those Go T-Shirts (ref: http://www.youtube.com/watch?v=wwoWei-GAPo)?
Well, if we do make them available, we'll certainly announce it here.
Ian
Ian Lance Taylor
> 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.
Yes, that can be very effective. There is an experimental
interpreter, but the approach can be an awkward fit with a statically
compiled language like Go.
Ian
Robert Griesemer
So, why not require an explicit cast if I use a value not of that
type. E.g.:
type DayOfWeek int
const {
Sunday DayOfWeek = iota;
// blah, blah...
}
func f(dow DayOfWeek) {
// Blah
}
f(42); // Compiler should fail, no? C'mon, I'm trying here by giving
you all those const...
f(DayOfWeek(42)); // Okay, buddy, you're on your own, then, if you
_insist_
Andrew Coleman
I'm disappointed at the lack of unified commenting like in Java.
Having javadoc creation really helps documentation, which in my
experience is the main cause of programming woes. When a large
project is being worked on, making documentation as easy as possible
is a big plus for anyone else who has to read your code.
Also, why not discussion of GUI debugger/compiler? IMO, that's the #1
lacking thing from C and C++. Creating a good, flexible debugger/IDE
will help foster other people to start using the code - and the
ignorance of this for the command line will keep Go from being
adopted.
On Nov 10, 5:35 pm, Dave <wrig...@gmail.com> wrote:
> 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>
Ian Lance Taylor
> While I haven't had time to look through the language extensively,
> I'm disappointed at the lack of unified commenting like in Java.
>
> Having javadoc creation really helps documentation, which in my
> experience is the main cause of programming woes. When a large
> project is being worked on, making documentation as easy as possible
> is a big plus for anyone else who has to read your code.
were generated automatically using the godoc program which can be
found in src/cmd/godoc.
> Also, why not discussion of GUI debugger/compiler? IMO, that's the #1
> lacking thing from C and C++. Creating a good, flexible debugger/IDE
> will help foster other people to start using the code - and the
> ignorance of this for the command line will keep Go from being
> adopted.
the resources to work on at present.
Ian
Jason
to construct a test case, I get a link error (not a compile error).
Changing my original case back to test this, I do get the compiler
error. If I can reproduce my case, I'll post it, but my guess is my .6
file was out of date.
FWIW, here's the case that compiles but doesn't link (using the 6g/6l
chain on MacOS 10.5.8):
package TestCase
type MyStruct struct {
a int
}
package main
import (
"./TestCase";
"fmt";
)
func main() {
t := &TestCase.MyStruct{12};
fmt.Println(t);
}
Results in:
(5) DATA type·TestCase.MyStruct+0(SB)/
8,$type·*runtime.StructType+0(SB)
MHeapMap_Preallocate: multiple initialization
(5) DATA type·TestCase.MyStruct+8(SB)/8,$type·TestCase.MyStruct
+16(SB)
MHeapMap_Preallocate: multiple initialization
(5) DATA type·TestCase.MyStruct+16(SB)/8,$8
MHeapMap_Preallocate: multiple initialization
(5) DATA type·TestCase.MyStruct+24(SB)/4,$1867948883
MHeapMap_Preallocate: multiple initialization
(5) DATA type·TestCase.MyStruct+28(SB)/1,$1
MHeapMap_Preallocate: multiple initialization
(5) DATA type·TestCase.MyStruct+29(SB)/1,$8
MHeapMap_Preallocate: multiple initialization
(5) DATA type·TestCase.MyStruct+30(SB)/1,$8
MHeapMap_Preallocate: multiple initialization
(5) DATA type·TestCase.MyStruct+32(SB)/
8,$go.string·"TestCase.MyStruct"+0(SB)
MHeapMap_Preallocate: multiple initialization
(5) DATA type·TestCase.MyStruct+40(SB)/
8,$extratype·TestCase.MyStruct+0(SB)
MHeapMap_Preallocate: multiple initialization
(5) DATA type·TestCase.MyStruct+48(SB)/8,$type·TestCase.MyStruct
+64(SB)
MHeapMap_Preallocate: multiple initialization
(5) DATA type·TestCase.MyStruct+56(SB)/4,$1
MHeapMap_Preallocate: multiple initialization
(5) DATA type·TestCase.MyStruct+60(SB)/4,$1
MHeapMap_Preallocate: multiple initialization
(5) DATA type·TestCase.MyStruct+64(SB)/8,$go.string·"a"+0(SB)
MHeapMap_Preallocate: multiple initialization
(5) DATA type·TestCase.MyStruct+72(SB)/8,$go.string·"TestCase"+0
(SB)
MHeapMap_Preallocate: multiple initialization
(5) DATA type·TestCase.MyStruct+80(SB)/8,$type·int+0(SB)
MHeapMap_Preallocate: multiple initialization
(5) DATA type·*TestCase.MyStruct+0(SB)/8,$type·*runtime.PtrType
+0(SB)
MHeapMap_Preallocate: multiple initialization
(5) DATA type·*TestCase.MyStruct+8(SB)/
8,$type·*TestCase.MyStruct+16(SB)
MHeapMap_Preallocate: multiple initialization
(5) DATA type·*TestCase.MyStruct+16(SB)/8,$8
MHeapMap_Preallocate: multiple initialization
(5) DATA type·*TestCase.MyStruct+24(SB)/4,$827827212
MHeapMap_Preallocate: multiple initialization
(5) DATA type·*TestCase.MyStruct+29(SB)/1,$8
MHeapMap_Preallocate: multiple initialization
(5) DATA type·*TestCase.MyStruct+30(SB)/1,$8
MHeapMap_Preallocate: multiple initialization
too many errors
-Jason
On Nov 10, 10:29 pm, Russ Cox <r...@golang.org> wrote:
> > 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
Eon
tremendously promising.
I have a few questions of course.
I noticed a lack of Unions and Variants in the language. Are they
candidates for implementation or have they been explicitly
left out?
Are there any considerations for compatibility in situations like
this: var a [3]int; var b struct{ sa int, sb int, sc int }; ?
My cases for each are below:
Unions and Variants are powerful tools for embedded system
development, of which this may want to be able to reach.
I make the distinction because a Union provides alternate access to
the guts of a type (i.e. floating point numbers
consist of a sign, exponent, and mantissa field, and either is a valid
interpretation of the data) while Variants provide a
means of identifying a type based on the local data alone (uses
include pseudo-inheritance from C, used for event handling
in SDL, and data transmission where the objects being sent must be
recognized in the stream itself).
As far as the struct/array compatibility, there are certaintly
ordering concerns, but the benefits arise in array math where
referencing each axis by index is potentially more sensible than doing
the same accessing fields. This reduces the difficulty
associated with building 2D systems and then increasing their
dimensionality to 3, 4, or higher. A perfect example is in
ray tracing when dealing with pixel color. I may want a highly
optimized piece of code that handles red, green, and blue
channels of light, but if I decide to improve on my fidelity and
sample the visible, IR, and UV spectrum in addition, I may
manually have to code in the additional dimensionality.
There is always the possibility for a workaround when a language is
Turing complete, but the question is, do either of these
situations play well on the implicit design of the language?
I look forward to digging into this spec a little deeper. Looks like
a lot of what I've been wanting from a new language.
Kudos,
-Eon
On Nov 10, 4:30 pm, Robert Schonberger <rschonber...@gmail.com>
Jason
1) This link error occurs if I define a private type and don't use a
value of it in the package where it is defined. E.g., this works
(thanks solely to the bugFix variable):
package DayOfWeek
type dayOfWeek int
type DayOfWeek int
type DayStruct struct {
dow dayOfWeek
}
type DayStructPublic struct {
dow DayOfWeek
}
var bugFix dayOfWeek = 1;
2) The following code seems to violate the compiler rules. In both
cases, I am assigning a value to x.dow, which should be private,
right?
package main
import (
"fmt";
"./DayOfWeek";
)
func main() {
dw := &DayOfWeek.DayStruct{8};
dw2 := &DayOfWeek.DayStructPublic{8};
fmt.Println(dw);
fmt.Println(dw2);
}
(Result is: &{8}, &{8})
-Jason
garbeam
> Very interesting! Any chance we get to use existing C libraries from
> Go?
Yes, I work on porting my window manager to go, a very minimalist
example (only two Xlib function bindings yet) is this
http://hg.suckless.org/godwm
However I more elaborate example is in go hg itself
go/misc/cgo/gmp/gmp.go
HTH,
Anselm