release.2010-11-02
Andrew Gerrand
can update by running:
hg pull
hg update release
This release includes a language change: the new built-in function, append.
Append makes growing slices much simpler. See the spec for details:
http://golang.org/doc/go_spec.html#Appending_and_copying_slices
Other changes:
* 8l: pe generation fixes (thanks Alex Brainman).
* doc: Effective Go: append and a few words about "..." args.
* build: fiddle with make variables.
* codereview: fix sync and download in Python 2.7 (thanks Fazlul Shahriar).
* debug/pe, cgo: add windows support (thanks Wei Guangjing <vcc...@gmail.com>).
* go/ast: add Inspect function for easy AST inspection w/o a visitor.
* go/printer: do not remove parens around composite literals starting with
a type name in control clauses.
* go/scanner: bug fixes, revisions, and more tests.
* gob: several fixes and documentation updates.
* godoc: bug fix (bug introduced with revision 3ee58453e961).
* gotest: print empty benchmark list in a way that gofmt will leave alone.
* http server: correctly respond with 304 NotModified (thanks Michael Hoisie).
* kate: update list of builtins (thanks Evan Shaw).
* libutf: update to Unicode 5.2.0 to match pkg/unicode (thanks Anthony Martin).
* misc/bbedit: update list of builtins (thanks Anthony Starks).
* misc/vim: update list of builtins.
* mkrunetype: install a Makefile and tweak it slightly so it can be built.
* netchan: fix locking bug.
* pidigits: minor improvements (thanks Evan Shaw).
* rpc: fix client deadlock bug.
* src: use append where appropriate (often instead of vector).
* strings: add Contains helper function (thanks Brad Fitzpatrick).
* syscall: SIO constants for Linux (thanks Albert Strasheim),
Stat(path) on windows (thanks Alex Brainman).
* test/ken/convert.go: add conversion torture test.
* testing: add Benchmark (thanks Roger Peppe).
Apologies if we missed anyone in the above list. We appreciate all your help.
To see a full list of changes between this and the previous release,
after updating, run:
hg log -r release.2010-10-27:release.2010-11-02
Enjoy.
Andrew
Dave Cheney
behold, here it is in release form!
Keep up the great work, I am enjoying the Go experience immensely.
Cheers
Dave
kar
good bye ol friend: >
func AppendBytes(d []byte, s []byte) []byte {
lens := len(d)
lenx := len(d) + len(s)
if lenx <= cap(d) {
d = d[0 : lenx]
} else {
n := make([]byte, lenx, resize(lenx))
copy(n, d)
d = n
}
copy(d[lens : lenx], s)
return d
}
func resize(n int) int {
if n < 16 { n = 16 }
return n + n/2
}
func Append(d []byte, val interface{}) []byte {
var b []byte
switch v := val.(type) {
case string: b = []byte(v)
case []byte: b = v
default: b = IntB(val)
}
if b != nil { d = AppendBytes(d, b) }
return d
On Nov 3, 11:48 am, Dave Cheney <d...@cheney.net> wrote:
> I was just about to try +tip to get access to append(), but low and
> behold, here it is in release form!
>
> Keep up the great work, I am enjoying the Go experience immensely.
>
> Cheers
>
> Dave
>
>
>
>
>
>
>
> On Wed, Nov 3, 2010 at 2:24 PM, Andrew Gerrand <a...@google.com> wrote:
> > We've just tagged a new Go release, release.2010-11-02. As usual, you
> > can update by running:
> > hg pull
> > hg update release
>
> > This release includes a language change: the new built-in function, append.
> > Append makes growing slices much simpler. See the spec for details:
> > http://golang.org/doc/go_spec.html#Appending_and_copying_slices
>
> > Other changes:
> > * 8l: pe generation fixes (thanks Alex Brainman).
> > * doc: Effective Go: append and a few words about "..." args.
> > * build: fiddle with make variables.
> > * codereview: fix sync and download in Python 2.7 (thanks Fazlul Shahriar).
Gabor
I wish, I could test it in the Go Playground
but that seems to be based on an earlier version.
How much earlier ?
On Nov 3, 4:24 am, Andrew Gerrand <a...@google.com> wrote:
> We've just tagged a new Go release, release.2010-11-02. As usual, you
> can update by running:
> hg pull
> hg update release
>
> This release includes a language change: the new built-in function, append.
> Append makes growing slices much simpler. See the spec for details:
> http://golang.org/doc/go_spec.html#Appending_and_copying_slices
>
> Other changes:
> * 8l: pe generation fixes (thanks Alex Brainman).
> * doc: Effective Go: append and a few words about "..." args.
> * build: fiddle with make variables.
> * codereview: fix sync and download in Python 2.7 (thanks Fazlul Shahriar).
Andrew Gerrand
> Append is great, thank you.
>
> I wish, I could test it in the Go Playground
> but that seems to be based on an earlier version.
> How much earlier ?
It's two releases behind right now. It will be updated within the next 24 hours.
Andrew
Johann Höchtl
.
> * debug/pe, cgo: add windows support (thanks Wei Guangjing <vcc....@gmail.com>).
The blog post
http://blog.golang.org/2010/11/debugging-go-code-status-report.html
says debuging on windows using GDB is not supported. But there have
been little tweaks here and there for PE support. Is there sthg.
already working?
Johann
.
> Andrew
Wei guangjing
try this CL: http://codereview.appspot.com/2124041/ 8l: emit DWARF in Windows PE.
you will can debuging on windows ;-)
Wei guangjing
Johann
.
> Andrew
Eleanor McHugh
> This release includes a language change: the new built-in function, append.
> Append makes growing slices much simpler. See the spec for details:
> http://golang.org/doc/go_spec.html#Appending_and_copying_slices
I feel a drastic code cull coming on :)
Ellie
Eleanor McHugh
Games With Brains
http://feyeleanor.tel
----
raise ArgumentError unless @reality.responds_to? :reason
⚛
> can update by running:
> hg pull
> hg update release
>
> This release includes a language change: the new built-in function, append.
> Append makes growing slices much simpler. See the spec for details:
> http://golang.org/doc/go_spec.html#Appending_and_copying_slices
feature or not. The non-obvious pros and cons seem to be:
Cons:
- It reduces the need for generic types in Go, thus further delaying
their (inevitable?) introduction.
- If introduction of generics is inevitable, then the "temporary hack"
in the form of "append" might not be best idea in the long run.
Pros:
- The compiler understands what "append" means (as opposed to the
situation when "append" is just another user-defined generic function
whose purpose is unknown to the compiler). This understanding can
eventually be used for better/faster type checking and for better
optimization of generated code.
Jessta
> I was thinking about whether it is possible to tell "append" is a good
> feature or not. The non-obvious pros and cons seem to be:
>
> Cons:
> - It reduces the need for generic types in Go, thus further delaying
> their (inevitable?) introduction.
> - If introduction of generics is inevitable, then the "temporary hack"
> in the form of "append" might not be best idea in the long run.
Generics may not be inevitable. Reducing their needs in the most
needed places may reduce their need
and interface{} can handle a lot of the additional cases.
I would prefer that most generic stuff be controlled by the language,
thus reducing the ability for
people go off and create their own mini languages within the
language(which is the real problem with generics and templating)
- jessta
--
=====================
http://jessta.id.au
Andrew Gerrand
The playground has been updated to the latest release; you can play
with append now. :-)
Andrew
Uriel
> On Thu, Nov 4, 2010 at 6:13 AM, ⚛ <0xe2.0x...@gmail.com> wrote:
>> I was thinking about whether it is possible to tell "append" is a good
>> feature or not. The non-obvious pros and cons seem to be:
>>
>> Cons:
>> - It reduces the need for generic types in Go, thus further delaying
>> their (inevitable?) introduction.
I find baffling that somebody could think it is bad to reduce the need
for a complex and controversial feature.
This is where discussion of the issues and advantages of generics ends
and we almost enter the world of dogma, where the end is taken for
granted rather than questioned, and any means to reach that end become
justified, and anything that brings us closer to a different end is
considered bad.
The real end is not to have feature X, or feature Y, it is to help
people write good code as easily and simply as possible, append() does
this.
Generics on the other hand: maybe, if somebody can come up with a good
enough design, which nobody has done so far.
So for now the alternatives are append() and nothing, I think i will
take append(), thank you.
>> - If introduction of generics is inevitable, then the "temporary hack"
>> in the form of "append" might not be best idea in the long run.
Nothing is ever inevitable, people have been very productive writing
code in all kinds of languages without generics, and I don't see why
making the life easier of people writing Go code today could be
considered a bad thing.
Assuming somebody comes up with an acceptable design for generics, I
doubt append() would be considered an obstacle to implementing it.
And if append() is to be considered "a temporary hack" bound to be
replaced with something better when somebody can come up with that
something, the same is true of everything else in the language.
Should we remove channels and goroutines because maybe someday
somebody will come with with a better concurrency model? Should we not
add more libraries to the stdlib, because they all will eventually be
replaced by ones with better APIs?
> Generics may not be inevitable. Reducing their needs in the most
> needed places may reduce their need
> and interface{} can handle a lot of the additional cases.
>
> I would prefer that most generic stuff be controlled by the language,
> thus reducing the ability for
> people go off and create their own mini languages within the
> language(which is the real problem with generics and templating)
This can't be repeated often enough, and is perhaps the best argument
against full blown generics and operator overloading.
Every time I hear somebody claiming that they can
build/bolt-on/hack-up a 'DSL' on top of an existing general purpose
language by using generics, operator overloading, industrial amounts
of syntactical sugar, etc., instead of writing a *real* DSL, I want to
strangle them with my bare hands.
C++ and specially Ruby developers are the biggest sinners in this.
They have corrupted and distorted the concept of domain specific
language far beyond recognition, and turned it from one of the most
beautiful and powerful concepts in programming into a horrid
Frankenstein.
sed, make, /bin/sh, TeX are all DSLs.
Ruby 'DSLs' and the like are not DSLs, the are just hideously
convoluted and totally unpredictable APIs that lack any transparency
or clarity.
Sorry for being bitter, but I love DSLs and it makes me very upset
that whole generations of programmers are growing up having a totally
incorrect understanding what DSL are, and what makes them so powerful
and beautiful.
Peace
uriel
⚛
> On Thu, Nov 4, 2010 at 1:18 AM, Jessta <jes...@jessta.id.au> wrote:
> >> I was thinking about whether it is possible to tell "append" is a good
> >> feature or not. The non-obvious pros and cons seem to be:
>
> >> Cons:
> >> - It reduces the need for generic types in Go, thus further delaying
> >> their (inevitable?) introduction.
>
> I find baffling that somebody could think it is bad to reduce the need
> for a complex and controversial feature.
> This is where discussion of the issues and advantages of generics ends
> and we almost enter the world of dogma, where the end is taken for
> granted rather than questioned, and any means to reach that end become
> justified, and anything that brings us closer to a different end is
> considered bad.
wouldn't be there already. The need for generics in a language stems
from the *observation* that there are certain recurring programming
patterns. A prime example of this is that virtually any typed language
that does not have a generic list (it has just arrays) will contain
code that tries to implement the list, and this code will be seen all
over the source code written in the typed language without generics.
Since it is a typed language, the programmers want the code to be type
safe, and thus if you have [a list of apples] and [a list of oranges],
you will find codes that differ from each other *only* in the type
"apple" and "orange".
Existence of generics isn't controversial, it is natural.
> The real end is not to have feature X, or feature Y, it is to help
> people write good code as easily and simply as possible, append() does
> this.
>
> Generics on the other hand: maybe, if somebody can come up with a good
> enough design, which nobody has done so far.
>
> So for now the alternatives are append() and nothing, I think i will
> take append(), thank you.
>
> >> - If introduction of generics is inevitable, then the "temporary hack"
> >> in the form of "append" might not be best idea in the long run.
>
> Nothing is ever inevitable, people have been very productive writing
> code in all kinds of languages without generics, and I don't see why
> making the life easier of people writing Go code today could be
> considered a bad thing.
> Assuming somebody comes up with an acceptable design for generics, I
> doubt append() would be considered an obstacle to implementing it.
*not* be an obstacle to any future Go language developments.
> And if append() is to be considered "a temporary hack" bound to be
> replaced with something better when somebody can come up with that
> something, the same is true of everything else in the language.
I doubt that.
> Should we remove channels and goroutines because maybe someday
> somebody will come with with a better concurrency model? Should we not
> add more libraries to the stdlib, because they all will eventually be
> replaced by ones with better APIs?
> > Generics may not be inevitable. Reducing their needs in the most
> > needed places may reduce their need
> > and interface{} can handle a lot of the additional cases.
>
> > I would prefer that most generic stuff be controlled by the language,
> > thus reducing the ability for
> > people go off and create their own mini languages within the
> > language(which is the real problem with generics and templating)
>
> This can't be repeated often enough, and is perhaps the best argument
> against full blown generics and operator overloading.
>
> Every time I hear somebody claiming that they can
> build/bolt-on/hack-up a 'DSL' on top of an existing general purpose
> language by using generics, operator overloading, industrial amounts
> of syntactical sugar, etc., instead of writing a *real* DSL, I want to
> strangle them with my bare hands.
>
> C++ and specially Ruby developers are the biggest sinners in this.
> They have corrupted and distorted the concept of domain specific
> language far beyond recognition, and turned it from one of the most
> beautiful and powerful concepts in programming into a horrid
> Frankenstein.
>
> sed, make, /bin/sh, TeX are all DSLs.
them (precedence, syntax) are also a DSL. Yet, this DSL is embedded in
many general purpose languages (counterexamples are Smalltalk and pure
Lisp). What is your interpretation of this?
⚛
"testing.InternalBenchmark". What is so "internal" about it? You could
easily name the new function "RunBenchmark()", instead of
"Benchmark()". In addition, to keep the naming consistent, shouldn't
be the type "testing.Test" renamed to "testing.InternalTest" now?
Please, revert it back, and rename the function "Benchmark()" to
"RunBenchmark()".
roger peppe
> On Nov 3, 4:24 am, Andrew Gerrand <a...@google.com> wrote:
>> * testing: add Benchmark (thanks Roger Peppe).
>
> Why has been the type "testing.Benchmark" renamed to
> "testing.InternalBenchmark". What is so "internal" about it? You could
> easily name the new function "RunBenchmark()", instead of
> "Benchmark()". In addition, to keep the naming consistent, shouldn't
> be the type "testing.Test" renamed to "testing.InternalTest" now?
i think i tend to agree with you, but i chose the names on russ's suggestion,
and names are ever a tricky issue. i had an interim version that used
the names you suggest. russ?
Russ Cox
> "testing.InternalBenchmark". What is so "internal" about it?
No hand-written code outside the testing package should refer to it.
If it weren't for the auto-generated code that comes out of gotest
it would be called benchmark with a lower case b. Although it has
to be public, it doesn't have to be a pretty name, and it doesn't
have to tie up a name that is more useful for something else.
It got renamed to make room for the function called Benchmark,
which hand-written code might actually call.
> You could
> easily name the new function "RunBenchmark()", instead of
> "Benchmark()". In addition, to keep the naming consistent, shouldn't
> be the type "testing.Test" renamed to "testing.InternalTest" now?
Sure. http://golang.org/doc/contribute.html
> Please, revert it back, and rename the function "Benchmark()" to
> "RunBenchmark()".
No thanks.
Russ
⚛
> > Why has been the type "testing.Benchmark" renamed to
> > "testing.InternalBenchmark". What is so "internal" about it?
>
> No hand-written code outside the testing package should refer to it.
> If it weren't for the auto-generated code that comes out of gotest
> it would be called benchmark with a lower case b. Although it has
> to be public, it doesn't have to be a pretty name, and it doesn't
> have to tie up a name that is more useful for something else.
>
> It got renamed to make room for the function called Benchmark,
> which hand-written code might actually call.
>
> > You could
> > easily name the new function "RunBenchmark()", instead of
> > "Benchmark()". In addition, to keep the naming consistent, shouldn't
> > be the type "testing.Test" renamed to "testing.InternalTest" now?
>
> Sure. http://golang.org/doc/contribute.html
company? Wouldn't my contribution increase its power even further?
If Google wants something get done it can easily hire (any conceivable
number of) developers, whatever the intent and purpose of the project
might be. Bad, good, pointless, groundbreaking - it doesn't matter.
The developers are given commands, and perform them. Quite simple. In
contrast to that, I am unable to do such a thing, whatever the intent
and purpose of my project is.
What would be the logical basis for contributing to Go? I don't see
Google or the Go team contributing any code to me, or helping me in
any way. In this situation, contributing code to Go appears to be
illogical.
Abdulla Kamar
What would be the logical basis for contributing to Go? I don't see
Google or the Go team contributing any code to me, or helping me in
any way. In this situation, contributing code to Go appears to be
illogical.
--
Abdulla
⚛
> > What would be the logical basis for contributing to Go? I don't see
> > Google or the Go team contributing any code to me, or helping me in
> > any way. In this situation, contributing code to Go appears to be
> > illogical.
>
> Aren't they contributing to your code by giving you all these tools?
Uriel
> What would be the logical basis for contributing to Go? I don't see
> Google or the Go team contributing any code to me, or helping me in
> any way.
If you don't find Go useful in any way, why are you here?
> In this situation, contributing code to Go appears to be
> illogical.
Same claim has been applied by some to contributions to any open source project.
If you don't understand the concepts of collaboration and shared goals
there isn't much to discuss.
uriel
⚛
> > What would be the logical basis for contributing to Go? I don't see
> > Google or the Go team contributing any code to me, or helping me in
> > any way.
>
> If you don't find Go useful in any way, why are you here?
Would you find that a viable explanation?
> > In this situation, contributing code to Go appears to be
> > illogical.
>
> Same claim has been applied by some to contributions to any open source project.
>
> If you don't understand the concepts of collaboration and shared goals
> there isn't much to discuss.
<start repeat>
company? Wouldn't my contribution increase its power even further?
If Google wants something get done it can easily hire (any conceivable
number of) developers, whatever the intent and purpose of the project
might be. Bad, good, pointless, groundbreaking - it doesn't matter.
The developers are given commands, and perform them. Quite simple. In
contrast to that, I am unable to do such a thing, whatever the intent
and purpose of my project is.
Google or the Go team contributing any code to me, or helping me in
illogical.
<end repeat>
Cory Mainwaring
André Moraes
open/free software project is: Freedom to adapt to your needs.
If you don't want to give back that contribution to Go you can just
fork it (Mercurial does that), put in you private server, make the
change and be forever happy with a language that only you can
maintain.
And, another really important question:
What is the problem with RunBenchmark?
Another thing, I really don't see the need for Generics in Go, using
interface{} is more than fine, and the type assertions and switch can
handle almost everything that generics does. Another thing, In Go you
don't need to reimplement a list to every type, just use the default
List and make the casts for your type.
Any language feature don't replace good programmers, you can have the
most feature full language and a bad programmer still can make really
bad programs.
--
André Moraes
http://andredevchannel.blogspot.com/
Ian Lance Taylor
> Why would I contribute to a project backed by a multi-billion dollar
> company? Wouldn't my contribution increase its power even further?
Go is an open source project. Open source projects work via
collaboration by all interested developers.
> If Google wants something get done it can easily hire (any conceivable
> number of) developers, whatever the intent and purpose of the project
> might be. Bad, good, pointless, groundbreaking - it doesn't matter.
> The developers are given commands, and perform them. Quite simple. In
> contrast to that, I am unable to do such a thing, whatever the intent
> and purpose of my project is.
It's a natural mistake to confuse Google, the company, with the team
working on Go. Google, the company, does have a lot of power when it
comes to writing software. However, while the company can do almost any
specific thing in that area, it can not do everything in that area. It
must make choices. Google could decide to put 100 developers on Go.
However, so far, it has not made that choice. The Go team at Google is
fairly small. While the Go team has the luxury of focusing full-time on
the language, in numbers it is dwarfed by the external, presumably
mostly part-time, contributors to Go.
> What would be the logical basis for contributing to Go? I don't see
> Google or the Go team contributing any code to me, or helping me in
> any way. In this situation, contributing code to Go appears to be
> illogical.
Google has contributed the entire Go language and libraries to you.
That may not help you, but it's silly for you to say that Google has not
contributed anything. You're quite right that if Go does not help you,
there is no reason for you to help the Go project. But you actually are
helping the Go project simply by commenting on the mailing list. Why
are you spending time on that?
Ian
Sven Engelhardt
Why would I contribute to a project backed by a multi-billion dollar
company? Wouldn't my contribution increase its power even further?
I'm tempted to recommend you look at D. It's got templates and overloading and all the other fine language features you won't find in Go. It has plenty of competing run-time libraries and split-up community resources that come with it. It's probably underfunded enough to address your anxiety adequately. Things won't progress as fast though because of that.
On the contrary Go is still a very young language and one of the first things I learned about it was that it is still unstable both as a language and the library. Keeping track of such changes however has never been a problem thus far. The introduction of append was by far the biggest change yet, and took me a mere 30 minutes to get 30k lines of code cleaned up from using containers and reslicing. We may or may not get generics some day, I'm not sure they will make (my) code easier to comprehend, which is one of the most outstanding features of Go as we speak, and I'm happy to see Russ is actually paying attention to keeping things that way. And I don't think we need generics. If your algorithms are really type agnostic, interfaces will work just fine and if they are not interfaces will force you to think adequately about how to address specific types in your code. In this case Go will force you to do some excessive casting, which is usually a sign of you doing something very very wrong. And I think it's kind of cool how the language provides such feedback straight into my fingertips.
-Sven
Michael Jones
:
Why would I contribute to a project backed by a multi-billion dollar
company? Wouldn't my contribution increase its power even further?
If Google wants something get done it can easily hire (any conceivable
number of) developers, whatever the intent and purpose of the project
might be. Bad, good, pointless, groundbreaking - it doesn't matter.
The developers are given commands, and perform them. Quite simple. In
contrast to that, I am unable to do such a thing, whatever the intent
and purpose of my project is.
What would be the logical basis for contributing to Go?
I don't see
Google or the Go team contributing any code to me, or helping me in
any way. In this situation, contributing code to Go appears to be
illogical.
--
Michael T. Jones
Chief Technology Advocate, Google Inc.
1600 Amphitheatre Parkway, Mountain View, California 94043
Email: m...@google.com Mobile: 650-335-5765 Fax: 650-649-1938
Organizing the world's information to make it universally accessible and useful
fango
> That you want to help make something good be greater,
Fango
Joseph Poirier
> <start repeat>
> Why would I contribute to a project backed by a multi-billion dollar
> company? Wouldn't my contribution increase its power even further?
You shouldn't. And no.
> If Google wants something get done it can easily hire (any conceivable
> number of) developers, whatever the intent and purpose of the project
> might be. Bad, good, pointless, groundbreaking - it doesn't matter.
> The developers are given commands, and perform them. Quite simple.
I think you're misinformed on how things work in the real world.
> In
> contrast to that, I am unable to do such a thing, whatever the intent
> and purpose of my project is.
Sounds like a personal problem/situation, why bring it up here.
> What would be the logical basis for contributing to Go?
That's something you'll need to sort out on your own.
> I don't see
> Google or the Go team contributing any code to me, or helping me in
> any way.
Are you sure; you don't sound 100% confident.
> In this situation, contributing code to Go appears to be
> illogical.
It seems you do have it figured out. Good.
-joe
Skip Tavakkolian
> Google or the Go team contributing any code to me, or helping me in
> any way. In this situation, contributing code to Go appears to be
> illogical.
for some it is for altruistic reasons (which may have evolutionary
benefits for the altruist). for the majority, it is because they
believe Go will provide them an efficient and elegant way to write
sophisticated distributed systems without the need for massive code or
software teams.
-Skip
andrey mirtchovski
elements a slice must have since I am allowed to do this with append
now:
package main
import "fmt"
func main() {
z := []byte(nil)
z = append(z, []byte("test")...)
fmt.Println(string(z[0:4]))
}
any gotchas i'm missing? of particular importance to me is that i must
return a slice of length 0 if nothing ever is appended to it. will
this always be true?
Rob 'Commander' Pike
not sure what you're driving at. []byte("test") already does the counting.
you could do
z := append([]byte(nil), []byte("test")...)
but
z := []byte("test")[:]
is simpler. or you could go with
z := [...]byte{1,2,3,4,5}[:]
-rob
andrey mirtchovski
"make" anymore -- I can just append to a nil slice. that saves me a
lot of make() calls when I'm processing an unknown number of elements
(which number may be 0). the way i did it before usually meant that
i'm overcommitting memory to a slice that will end up not being filled
in. append may also overcommit in the end, but i trust it to be doing
it more elegantly than i would.
I can see myself wanting to have File.ReadBlock() (or something more
aptly named) that takes no arguments but returns however much data it
could gobble in a single attempt, which could also be the
optimum-sized block for single reads for that particular OS/network
connection/interconnect/etc. That will go away with all the pesky
"bytes read" returns. Who knows, it may even make EOF redundant :)
GreatOdinsRaven
> Would you find that a viable explanation?
opposite of what you suggest in order for Go to succeed? ;-)
No generics it is then, for the glory of Go!
On Nov 5, 4:01 am, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
> On Nov 5, 9:47 am, Uriel <ur...@berlinblue.org> wrote:
>
> > On Fri, Nov 5, 2010 at 9:14 AM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
> > > What would be the logical basis for contributing to Go? I don't see
> > > Google or the Go team contributing any code to me, or helping me in
> > > any way.
>
> > If you don't find Go useful in any way, why are you here?
>
>
deepak
can you give a concrete example of how ruby does not let you write
good DSL's
and how do you define a good DSL
cheers,
deepak
On Nov 4, 8:55 am, Uriel <ur...@berlinblue.org> wrote:
> On Thu, Nov 4, 2010 at 1:18 AM, Jessta <jes...@jessta.id.au> wrote: