Go 1
Russ Cox
Please post comments in this thread. Thanks.
André Moraes
Or will only replace those?
If it will only replace why not keep goinstall as the tool name?
--
André Moraes
http://andredevchannel.blogspot.com/
André Moraes
The exp package will still live in the tip and will be removed only on
the "Go N" versions?
Brian Ketelsen
On Oct 6, 2011, at 9:08 AM, Russ Cox wrote:
> See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
> Please post comments in this thread. Thanks.
Is the plan to incrementally change the current tree to meet these goals? How many releases (weekly/monthly or otherwise) do you envision between now and Go 1? The most invasive changes from my perspective[1] are the package rearrangements and the move to error.Value from os.Error. I think it would be beneficial to make these structural changes as soon as possible. The other changes are more subtle.
Brian
Brandon Mercer
following a short term release cycle? I've not seen any issue in
things being maintained the way they are now.
J.L.vanderZwan
should be an m.
Reliability is important, so this is a good development. Other than
that, I know that I don't know enough about programming to weigh in on
the discussion as to what should be in Go 1 - I'll just keep watching
on the sidelines.
On Oct 6, 3:08 pm, Russ Cox <r...@golang.org> wrote:
> Seehttp://blog.golang.org/2011/10/preview-of-go-version-1.html.
roger peppe
> See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
> Please post comments in this thread. Thanks.
LGTM
particular +1s to: composite literals, map deletion, no function equality,
composite map keys, package renaming.
not sure about: error.Value as a name, go/types noncompletion,
i'll miss gotry, although i doubt anyone else will.
Vincent Vanackere
> See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
> Please post comments in this thread. Thanks.
>
equality
The current language does not define equality on struct and array values. It does define equality on function and map values. Function equality is problematic in some contexts and map equality compares pointers, not the maps’ content. Only types with defined equality can be used as map keys.
Go 1 will define equality on struct and array values composed from fields on which equality is also defined (element-wise comparison).
This one will be a great improvement. If I understand the implication correctly, it will make mappings much more powerful and in most cases remove the need to use an encoding scheme (typically to a string value) for complex keys. :-)
It will remove equality on function and map values except for comparison with nil.
However this particular change seems a bit drastic... Isn't it possible to keep the possibility to compare function and map values for equality while disallowing their usage as a part of map keys ? Could you elaborate on the potential problems with function equality ?
Vincent
Florian Weimer
> See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
> Please post comments in this thread. Thanks.
Regarding composite literals, can they used for unnamed parameters, as
in:
type Entry struct {
Name string
Value float64
}
var f func(*Entry)
...
f({Name: "pi", 3.14})
?
I still think it would make sense to aim for more consistent error
handling (callers always have to check the error return).
yy
instead of the syntax which has been proposed before: m[k] = _
I just think the number of builtins should be minimized, but I may be
missing something. (By the way, the same syntax could be applied to
closing channels too: c <- _, then the restriction to close
receive-only channels would be evident.)
Also, I don't really like error.Value, but I don't have a better
proposal and I agree os.Error was not right.
Anyway, I'd like to say that in general terms I like very much the
suggested changes and the idea of a stable release. In particular, I
find the go command very nice and the solution to shadowing return
values quite original.
--
- yiyus || JGL .
Eleanor McHugh
> See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
> Please post comments in this thread. Thanks.
My main disappointment is that Go 1 won't include a succinct literal form for user-defined function types as the current need to type cast anonymous functions is ugly, ugly, ugly, ugly, ugly.
Ellie
Eleanor McHugh
Games With Brains
http://feyeleanor.tel
----
if _, ok := reality.(Reasonable); !ok { panic(reality) }
⚛
"Go 1 will continue to exclude equality for slices. (In the general
case it is infeasible.)"
I don't understand the reasoning behind this. Is the reason
performance, or complexity of implementation, or something else?
Paulo Pinto
1 list.
Having them added afterwards might create issues, assuming that they
will "eventually"
be in Go.
--
Paulo
Peter Bourgon
For me, this is by far the most exciting part of the proposal. I'd
love to hear as much detail as possible about this new tool.
Specifically, I'm interested in how the authors propose to address
dependencies of packages on both runtimes and other packages. Also, it
would be great to see a clear definition of where "go"-installed
packages can possibly reside (if that would differ from the current
implementation).
Mateusz Czapliński
> The new "Go" tool will have more features than goinstall + make
> Or will only replace those?
> If it will only replace why not keep goinstall as the tool name?
it will effectively work around the special treatment Windows gives to
executables containing 'install' or 'setup' in name. (Really funny
thing, this.)
As of the rest, it's an interesting reading. I enjoy especially
'deletion from map', 'return with named arguments', 'Go tool' and
'official Windows binaries'. Also the fact that some pretty big
changes are planned at all, and Go 1 is to emerge soon.
I pity lack of announced plans for a solution to the problem with :=
assignment.
regards
/Mateusz Czaplinski.
Gustavo Niemeyer
> Please post comments in this thread. Thanks.
Fantastic news there. Exciting times.
As a detail, for the append improvement it'd be nicer to see a fix for
issue 2204 instead, since it's a generic desire to be able to handle
an underlying string byte-by-byte without incurring in gratuitous
allocation. The issue describes a few different cases in addition to
the append support that come from the same problem.
--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog
-- I never filed a patent.
tux21b
tiny_dust
by "_"
example:
f,_:=os.Open("xxx")
=>
f,err01:=os.Open("xxx");check(err01) //func check(err os.Error)
{if err!=nil{panic(err)}}
it is bad idiom to ignore error by "_" without this feature.
this feature will improve robust of error handling.
in many situations(not all), error handling is a crosscutting
concerns,such as deployment problem,programming bugs.
normal logic need not handle these things everywhere. (os.Error is
like the CheckedException of Java)
On 10月6日, 下午10时14分, Florian Weimer <f...@deneb.enyo.de> wrote:
> * Russ Cox:
>
> > Seehttp://blog.golang.org/2011/10/preview-of-go-version-1.html.
Sebastien Binet
On Oct 6, 5:22 pm, Paulo Pinto <paulo.jpi...@gmail.com> wrote:
> Not to raise a big discussion about it, but I miss generics on the Go
> 1 list.
>
> Having them added afterwards might create issues, assuming that they
> will "eventually"
> be in Go.
-s
chris dollin
> Not to raise a big discussion about it, but I miss generics on the Go
> 1 list.
I can't see that for a Go 1 "early next year" that there's enough time
to devise, implement, and soak-test generics for Go.
Much as I would like to have them myself ...
Chris
--
Chris "allusive" Dollin
Douwe Gelling
"container/vector - not in Go 1
Scheduled for deletion."
Maybe I'm the only one using this package, but why is it removed? I
really
like being able to use a list that automatically grows. Or will there
be some
replacement?
Riton
Jesse McNelis
Been stuck under a rock for a while? anyway, the append() built-in
offers all the functionality of container/vector for any type of slice.
http://golang.org/doc/go_spec.html#Appending_and_copying_slices
http://code.google.com/p/go-wiki/wiki/SliceTricks
Andrew Gerrand
yy
> i think compiler should check error automaticly when user ignore it
> by "_"
Errors are just values. The compiler doesn't know that what you are
ignoring is an error.
Douwe Gelling
>
> The built-in append and copy functions make container/vector largely
> redundant. See:
>
> http://code.google.com/p/go-wiki/wiki/SliceTricks
>
> Andrew
chris dollin
> Will string be implemented as []rune then ?
I doubt it. That would make most strings a lot fatter than they need be.
You can cast to and from []int already if you need to -- that will just become
[]rune.
> We could finally use :
> s:= "世界"
> len(s) // 2
> s[1] // 世
(s[0], not s[1])
> range
range works on strings already.
--
Chris "allusive" Dollin
Andrew Gerrand
The new "Go" tool will have more features than goinstall + make
Or will only replace those?If it will only replace why not keep goinstall as the tool name?
Ugorji Nwoke
Riton
Andrew Gerrand
On Thursday, October 6, 2011 6:44:18 AM UTC-7, Brian Ketelsen wrote:
Is the plan to incrementally change the current tree to meet these goals? How many releases (weekly/monthly or otherwise) do you envision between now and Go 1? The most invasive changes from my perspective[1] are the package rearrangements and the move to error.Value from os.Error. I think it would be beneficial to make these structural changes as soon as possible. The other changes are more subtle.
Ugorji Nwoke
Riton
chris dollin
Strings aren't implemented as []byte.
Even if they were, implementing something as []byte doesn't demand that
all accesses be to bytes.
The inconsistency is that s[x] gets you raw bytes but range gets you codepoints.
It's a compromise that keeps strings slim and [] access fast. Most of
the time there's
no problem, and there are no problem-free constructs ...
chris dollin
> On 6 Oct 2011, at 14:08, Russ Cox wrote:
>> See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
>> Please post comments in this thread. Thanks.
>
> My main disappointment is that Go 1 won't include a succinct literal form for user-defined function types as the current need to type cast anonymous functions is ugly, ugly, ugly, ugly, ugly.
When does one type-cast anonynous functions?
Or do you mean that an anonymous function comes with a heavy-weight
func ... syntax? It's not clear to me that you could leave it out and preserve
Go's type-safety.
Andrew Gerrand
Another thing I forgot to put in the last post:The exp package will still live in the tip and will be removed only on
the "Go N" versions?
Andrew Gerrand
On Thursday, October 6, 2011 7:02:08 AM UTC-7, Vincent wrote:
It will remove equality on function and map values except for comparison with nil.
However this particular change seems a bit drastic... Isn't it possible to keep the possibility to compare function and map values for equality while disallowing their usage as a part of map keys ? Could you elaborate on the potential problems with function equality ?
⚛
It is currently possible to easily iterate over the individual bytes
of "[]byte" or "string" using a for loop:
for i:=0; i<len(s); i++ {
fn(s[i])
}
On the other hand, should range over a Go string be byte-oriented (as
opposed to rune-oriented), there wouldn't be an easy method of how to
iterate over the runes of a string. Iterating over the runes would
look like this:
for i:=0; i<len(s); {
rune, size := utf8.DecodeRune(s[i:])
fn(rune)
i += size
}
That it is *longer* (less succinct) than:
for _, rune := range s {
fn(rune)
}
The reason behind the choice to have "range s" iterate over runes is
that the language *already* has a succinct method of how to iterate
over the bytes of a string (see the 1st code snippet). Without "range
s" returning runes, there wouldn't exist a succinct method of how to
iterate over the characters of a Go string.
Andrew Gerrand
I'd like to know what is the reason to add the "delete" builtin
instead of the syntax which has been proposed before: m[k] = _I just think the number of builtins should be minimized, but I may be
missing something. (By the way, the same syntax could be applied to
closing channels too: c <- _, then the restriction to close
receive-only channels would be evident.)
André Moraes
>
> http://code.google.com/p/go/source/browse/src/cmd/go/script.txt
>
> As you can see, it does more than just installation, so "goinstall" isn't really an apt name anymore.
After reading that text the name change really makes sense.
As a suggestion a "pack" command could be placed there.
It will use the same logic for list, but instead of just listing it
will copy to some dir and pack as a zip/tar.gz/etc...
Of course that the user can just use the list command with some other
tool to achive the same result.
--
André Moraes
http://andredevchannel.blogspot.com/
Riton
Julian Phillips
> See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
> Please post comments in this thread. Thanks.
There's a lot of nice stuff in there.
However, I just can't bring myself to like error.Value. It seems such
an ... icky name for something that I find myself using all the time
when writing library code.
Can't we promote it further to a builtin type "error"?
error.New could be a cast instead - i.e. error("foo")
If that isn't acceptable, how about a "lang" package for such things?
Then we could have lang.Error and lang.NewError. This could also be a
home for things like lang.Version ...
--
Julian
yy
> We want to keep different concepts in Go orthogonal.
> m[x] = _ is cute but gives _ two unrelated meanings.
I was thinking in _ as some sort of /dev/null, so the two meaning were
not so unrelated, at least in my head.
> A new function name is clear and does not interfere with other parts of the
> language.
Fair enough. I just wanted to know the reason the other option was
discarded. Thanks for your answer.
And by the way, thanks for asking. You did not only make your
(mid-term?) plans public, you asked for opinion. That's very kind of
you.
Florian Weimer
It might make sense to error out if *any* return value is ignored, not
just os.Error. Explicitly ignoring errors when there are other result
values does not appear common. Most reports to the mailing list
seemed to involve functions which return nothing but an error.
But this is only part of the problem. Currently, for io.Reader and
similar interfaces, you have to check the non-error value before the
error-value, and for most other functions, you have to check the error
value before anything else. This leads to bugs.
Miki Tebeka
1. Make testing.T an interface
2. Allow conversion of []T to []interface{} (as in http://golang.org/doc/go_faq.html#convert_slice_of_interface)
3. Add sort.GenericSort(items interface{}, func cmp(a, b interface{}) int)
David Roundy
> On Oct 6, 3:08 pm, Russ Cox <r...@golang.org> wrote:
>> Seehttp://blog.golang.org/2011/10/preview-of-go-version-1.html.
>> Please post comments in this thread. Thanks.
>
>
> "Go 1 will continue to exclude equality for slices. (In the general
> case it is infeasible.)"
>
> I do I understand the reasoning behind this. Is the reason
> performance, or complexity of implementation, or something else?
I would presume because the value of slices can change, and it
normally doesn't make sense to copy them, which makes them not so
useful as map keys. On the other hand, if you *did* copy slices, then
I don't see any particular problem with having them as map keys under
the same constraints.
David
David Roundy
One is regarding the lack of specification for rejection due to
shadowing of result variables:
> Go 1’s compilers will reject a return statement without arguments when any of the result variables has been shadowed. This rule will not be defined in the language spec, by analogy with the rules about when a function is missing a return statement. Not specifying the behavior, while enforcing with the compilers, makes it easier to adjust the rules as we continue to explore this area of the Go language.
I can understand the appeal of this (allowing for future refinements
to the "fatal warnings" algorithms), but it seems like it seriously
undermines the utility of having a specification: if it's not
possible to determine whether a given program is valid from the
specification seems like a real problem, particularly in a stable
release. Once go 1 is released, I presume that these checks will be
frozen in stone... or at least the compiler will only become more
liberal. Otherwise valid go 1 programs will fail to compile under go
1.1 or later. If this is the case, it'd be nice to have careful
wording in the spec that indicates which programs will *not* fail.
I guess a commitment that programs that compile under go 1 are
guaranteed to compile in go 1.x. On the other hand, that still makes
the compiler itself a de facto language specification, which seems
inelegant and potentially dangerous (e.g. what happens if gccgo and gc
are found to differ on a given case). Probably this won't happen, but
bugs in compilers have been known to be found in the past...
David
barnex
+1 for the equality
+1 for the long-term stability. As a Go developer I don't mind
gofixing my code from time to time. But sometimes people want to
contribute to C or python parts of my project and they need Go to
compile the entire source tree. For them, it's not so trivial to
install the correct Go release since the project sometimes lags the Go
revisions.
Thanks for the effort!
-Arne.
Jonathan Amsterdam
for anonymous functions:
func applyTwice(f func(int)int, x int) int { return f(f(x)) }
...
applyTwice(func(i int) int { return i+1}, 3)
The compiler could do type inference here so that the call could look
something like
applyTwice(func(i) { return i+1 }, 3)
or, since the func keyword might be confusing here (since the syntax
for arg and return values are so different):
applyTwice(\i{return i+1}, 3)
> Or do you mean that an anonymous function comes with a heavy-weight
> func ... syntax? It's not clear to me that you could leave it out and preserve
> Go's type-safety.
available in some other way.
Paulo Pinto
On 6 Okt., 18:40, chris dollin <ehog.he...@googlemail.com> wrote:
> On 6 October 2011 16:22, Paulo Pinto <paulo.jpi...@gmail.com> wrote:
>
> > Not to raise a big discussion about it, but I miss generics on the Go
> > 1 list.
>
> I can't see that for a Go 1 "early next year" that there's enough time
> to devise, implement, and soak-test generics for Go.
>
> Much as I would like to have them myself ...
Kyle Consalus
Evan Shaw
version 1 won't have every feature I want. :) I am happy with most of
the changes in the Go 1 plan, though.
I might be jumping the gun, but where will development effort be
focused after the release? Will it be aimed towards improving the
release or will development on "Go 2" begin immediately? Somewhere in
between?
- Evan
Jonathan Amsterdam
with the delete function. Namely, it's not a function: it doesn't
evaluate its argument. I understand that many of the built-in
functions are special -- some take types as arguments, and the types
of some cannot be expressed in Go -- but delete would be the only one
that doesn't evaluate a non-type argument. There's a simple fix for
that:
delete(m, x)
Is the cuteness of writing delete(m[x]) worth the confusion and
weirdness?
Michael Shields
Jonathan Amsterdam
as map keys. That is a step forward.
My concern is that a lot of types will now be comparable by "==", and
some of those shouldn't be -- any type for which elementwise equality
is wrong. E.g., types with pointers, or where only part of a field is
used.
I suppose you are going to tell me to make at least one field in my
struct unexported, and then equality, like copying, will be turned off
outside of the package. Fine. I'm not happy about linking behavior to
exportability, but I guess that's for another thread.
But I'm curious why you didn't go in another direction: why not say a
type T can be a map key if it defines Hash() int and Equals(T) bool
(or is one of the builtin types that supports ==)?
Steven Blenkinsop
My concern is that a lot of types will now be comparable by "==", and
some of those shouldn't be -- any type for which elementwise equality
is wrong. E.g., types with pointers, or where only part of a field is
used.
Go 1 will allow abbreviating a composite literal of the form &T{...} initializing a value of type *T, by omitting the &T.
Or do you mean that an anonymous function comes with a heavy-weightfunc ... syntax? It's not clear to me that you could leave it out and preserve
Go's type-safety.
Jim Whitehead II
I have to echo this. Even though it's not implemented as a function,
it appears to be a function call and its very 'magical'. It says
'delete the entry x from map m' but it does it in a way that looks
like we're deallocating the value contained at m[x]. It looks a but
too much like a free() to me.
delete(m, x) is a great suggestion for making this syntax clear and
easy to read and write. It says to delete the value associated with
the key x in the map m.
- Jim
Andrew Gerrand
> A later version of Go will change rune to be an alias for int32, which will make it> reasonable to change int to be 64 bits.Why have you postponed this change?
On Thursday, October 6, 2011 12:46:54 PM UTC-7, mshields wrote:
I like the plan to create a "rune" type alias, but I'm concerned about waiting until "a later version" to make int 64-bit. Slices larger than 2**31 elements are increasingly reasonable, and over the lifetime of Go 1 will become more so. Is there a reason that using too much space for runes until they can become int32s is a major concern?
Andrew Gerrand
On Oct 6, 3:08 pm, Russ Cox <r....@golang.org> wrote:
> Seehttp://blog.golang.org/2011/10/preview-of-go-version-1.html.
> Please post comments in this thread. Thanks.
The Go 1 preview document says:
"Go 1 will continue to exclude equality for slices. (In the general
case it is infeasible.)"
I don't understand the reasoning behind this. Is the reason
performance, or complexity of implementation, or something else?
Andrew Gerrand
Regarding composite literals, can they used for unnamed parameters, as
in:type Entry struct {
Name string
Value float64
}var f func(*Entry)
...
f({Name: "pi", 3.14})?
I still think it would make sense to aim for more consistent error
handling (callers always have to check the error return).
Richard Crowley
> ... icky name for something that I find myself using all the time when
> writing library code.
>
> Can't we promote it further to a builtin type "error"?
>
> error.New could be a cast instead - i.e. error("foo")
>
> If that isn't acceptable, how about a "lang" package for such things? Then
> we could have lang.Error and lang.NewError. This could also be a home for
> things like lang.Version ...
+1 for lang.Error, lang.NewError, etc.
I'm saddened that "uses of operating system errors (for example, the
uses of os.EINVAL and os.ERANGE by package strconv) will be
discouraged." Error numbers are very attractive to me because they're
machine-actionable and can be propagated outside the Go runtime.
Within Go, type switches on values that implement os.Error are great
but syntactically tedious.
Use of plain-string errors like os.stringError should be what's discouraged.
Dave Cheney
The plan for Go version 1 look great.
On Fri, Oct 7, 2011 at 12:08 AM, Russ Cox <r...@golang.org> wrote:
> See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
> Please post comments in this thread. Thanks.
I have two comments on the proposal, both of with have been raised
already in this thread:
1. map delete syntax - I agree that adding a new builtin to replace
the old map delete syntax is a good improvement, but I think Jonathan
and Jim have a good point that delete(m[k]) is a little strange. What
is the type of the single argument passed to delete, m, or k? I think
delete(map, key) fits pattern established by append and copy. There is
also the issue of someone new to the language attempting to use
delete() as some form of free(). A two argument delete builtin would
make such incorrect usage a syntax error.
2. error.Value - I agree completely that os.Error needs addressing but
am not sure that error.Value is a good replacement for the following
reasons.
* error.Value is 3 characters longer than os.Error, which is a small
footprint increase on disk, but does run contrary to Go's emphasis on
concise syntax and variable names. A possible replacement could be
error.E, which follows the pattern set by the testing package. However
this does not fully address my next point.
* import "error" removes error as a possible variable name. We saw
that identified during the development of exp/sql, which decided
against using the use of "db" as the package name for this reason.
* error.Value implies might imply that there are other types inside
the error package. While this probably isn't the case, it sets a
precident for a package that contains only a single interface type and
a few helper functions.
* While importing os, just to get the os.Error type may be overkill,
having to import the error package simply to return an error, which
most likely came from the function your package is calling, is just as
clunky.
I have two suggestions, which may or may not be feasable
* go.Error, in the package go. At least it's the same count as
os.Error, and does not consume error as a variable name. I am not sure
if this would conflict with the go statement.
* Some new type for errors, which itself is a built in alias for fmt.Stringer.
Cheers
Dave
Kyle Lemons
switch p.Value { // p.Error makes a lot more sense.
case ...
}
}
David Christensen
> See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
> Please post comments in this thread. Thanks.
Thank you to everyone who has made Go possible to this point. I look
forward to enjoying Go 1. :-)
Two ideas stated by Frederick P. Brooks, Jr., have resonated with me
ever since I read them [1]. I've found that they apply to far more than
software projects:
1. The Programming Systems Product (pp. 4-6).
2. Conceptual Integrity (pp. 42-43).
In context of the subject, the following quotation also comes to mind (I
am unable to find a source attribution):
"A programming language is only as good as its library."
I encourage the implementers of Go 1 to aim for nothing less than
exemplary achievement in all regards, including the above. Given the
personnel, technical, and financial resources of Google, this should be
possible.
A final idea -- release Go 1 when it is ready; no sooner.
David
References:
[1] Frederick P. Brooks, Jr.,, 1995, "Mythical Man-Month The: Essays on
Software Engineering, Anniversary Edition", Addison Wesley Longman,
Inc., ISBN 0-201-83595-9.
kortschak
Andrew Gerrand
Mikio Hara
- Issue 1875: rename ReadFrom/WriteTo to WriteFrom/ReadTo?
Perhaps Go 1 is a good and final chance to do this.
- Please add os/inotify to the package rearrangement packing list
Bobby Powers
tiny_dust
could treat it the same as the built-in "ok" syntax:
a:=map[int]int{}
v,ok:=a[3] //checked
v:=a[3] //panic if the i is not the key of a
there are many such beautiful things in built-in types or functions,
but the user-defined ones can not benefit from it .........
On Oct 7, 12:49 am, yy <yiyu....@gmail.com> wrote:
> 2011/10/6 tiny_dust <ustc.li...@gmail.com>:
> > i think compiler should check error automaticly when user ignore it
> > by "_"
>
> Errors are just values. The compiler doesn't know that what you are
> ignoring is an error.
>
> - yiyus || JGL .
Rob Thornton
delete map +1 and go tool +1.
I'm curious though, why has no 'remove' or 'uninstall' command has
been implemented in goinstall or the new go tool? I have goinstall'd
libraries to test them and it would be handy, and I imagine simple to
implement, to simply 'go remove package/cmd' and/or it's depends
(optional?).
On Oct 6, 6:08 am, Russ Cox <r...@golang.org> wrote:
> Seehttp://blog.golang.org/2011/10/preview-of-go-version-1.html.
Steven Blenkinsop
Mark Summerfield
Overall I think Go 1 sounds good. All the language changes seem like
improvements and so does the package reorganization.
However:
- I prefer the delete(map, key) that several people have suggested
(although I still like the "cute" m[k] = _ best of all)
- Replacing os.Error with error.Value seems a bit ugly (although
sensible in terms of packages)
Suggestion #1: Although illogical, move Error into the go package so
that we replace os.Error with go.Error (oh, Dave Cheney already
suggested this:-)
Suggestion #2: call the error package err (precedents: strconv,
syscall, fmt), so we get err.Value
Suggestion #3: as #2 but use Info for the interface, so we get
err.Info
--
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
C++, Python, Qt, PyQt - training and consultancy
"Programming in Python 3" - ISBN 0321680561
http://www.qtrac.eu/py3book.html
Jesse McNelis
> Suggestion #2: call the error package err (precedents: strconv,
> syscall, fmt), so we get err.Value
Do you realise that this would break every piece of Go code out there?
naming the package "err" would mean that "err" wouldn't be usable as a
variable name in any package that needed to import err and "err" is used
as a variable pretty much everywhere.
error.Value seems a bit weird to me.
- jessta
Russel Winder
> On 07/10/11 18:23, Mark Summerfield wrote:
> > Suggestion #2: call the error package err (precedents: strconv,
> > syscall, fmt), so we get err.Value
>
> Do you realise that this would break every piece of Go code out there?
> naming the package "err" would mean that "err" wouldn't be usable as a
> variable name in any package that needed to import err and "err" is used
> as a variable pretty much everywhere.
On the other hand, now is the time for breaking changes, before things
reach version 1.0. If breaking changes cannot happen whilst a system is
experimental, how do you introduce improvements?
> error.Value seems a bit weird to me.
?
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
⚛
> On Thursday, October 6, 2011 8:11:29 AM UTC-7, ⚛ wrote:
>
> > On Oct 6, 3:08 pm, Russ Cox <r....@golang.org> wrote:
> > > Seehttp://blog.golang.org/2011/10/preview-of-go-version-1.html.
> > > Please post comments in this thread. Thanks.
>
> > The Go 1 preview document says:
>
> > "Go 1 will continue to exclude equality for slices. (In the general
> > case it is infeasible.)"
>
> > I don't understand the reasoning behind this. Is the reason
> > performance, or complexity of implementation, or something else?
>
> Since slices and maps can refer to themselves indirectly,
> general equality
> would require cycle detection in order to be guaranteed to finish. That's
> more expensive than we'd like.
compile-time. The language spec would say that equality on such types
is not defined.
In relation to map keys: the strategy would be to make a copy of the
slice. (... with the hope that a future optimizing Go compiler will be
able to detect if the copy can be elided)
Peter Bourgon
> here:
> http://code.google.com/p/go/source/browse/src/cmd/go/script.txt
Nice. Two immediate comments,
> To run gofix with specific options, run gofix itself.
> To run gofmt with specific options, run gofmt itself.
> (etc.)
"go" as simply a wrapper for "goxxx" commands, rather than a proper
replacement, seems half-hearted and incorrect. Seems better to fold
every "goxxx" into "go" completely, and do away with the separate
binaries.
> usage: go get [importpath...]
> . . .
> . . . it uses the default version for
> the version control system: HEAD for git, tip for Mercurial,
> and so on.
"tip" is not the default version for Mercurial. It's simply the most
recently committed changeset, regardless of what branch it happens to
be on. Probably what you want here is "default".
Nigel Tao
>> > I don't understand the reasoning behind this. Is the reason
>> > performance, or complexity of implementation, or something else?
>>
>> Since slices and maps can refer to themselves indirectly,
>
> I see. For example: type T []T
Or: var x []interface{}; x = append(x, x).
Nigel Tao
> Or: var x []interface{}; x = append(x, x).
I meant: x := make([]interface{}, 1); x[0] = x. But the point is that
it's not just recursive types.
Riton
- I prefer the delete(map, key) that several people have suggested
(although I still like the "cute" m[k] = _ best of all)
Mostafa Hajizadeh
"go" as simply a wrapper for "goxxx" commands, rather than a proper
replacement, seems half-hearted and incorrect. Seems better to fold
every "goxxx" into "go" completely, and do away with the separate
binaries.
chrisfarms
tiny_dust
any //for interface{}
error // for os.Error, Key-Error of map operation .....
iterator //for range statement
roger peppe
i wonder if the error interface could be treated as special because the
runtime knows about it - it's the only interface that has special
mention in the specification:
http://golang.org/doc/go_spec.html#Run_time_panics
perhaps this might be sufficient rationalisation for giving it
its own place in pkg/builtin.
type error {
String()
}
specific error constructors would live in particular packages, as
currently.
roger peppe
> type error {
> String()
> }
oops, i meant:
type error interface{
String()
}
of course.
gauravk
other suggestions made so far.
Albert Strasheim
On Oct 6, 3:08 pm, Russ Cox <r...@golang.org> wrote:
> See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
Have you considered making a list of bugs to fix before the Go 1
release?
Overall, we've found the packages to be in great shape, but there are
two issues in net which are a constant thorn in our sides:
http://code.google.com/p/go/issues/detail?id=2122
http://code.google.com/p/go/issues/detail?id=2116
and maybe:
http://code.google.com/p/go/issues/detail?id=1692
We've looked at tackling them (they've been tagged HelpWanted), but
doing it right is tricky and maybe a job best left to the
professionals. :-)
Regards
Albert
sambeau
On Oct 7, 11:42 am, chrisfarms <chrisfa...@gmail.com> wrote:
>
> os.Error -> err.Error
>
+1. Seems more Go-ish to me.
Ian Lance Taylor
> Suggestion #1: Although illogical, move Error into the go package so
> that we replace os.Error with go.Error (oh, Dave Cheney already
> suggested this:-)
This suggestion can't work, because "go" is a keyword in the language.
"package go" is a syntax error.
Ian
Mark Summerfield
Ah, I'd been looking at http://golang.org/pkg/go/ but actually that only
has packages inside the directory; I hadn't noticed before that it isn't
a package itself.
--
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
C++, Python, Qt, PyQt - training and consultancy
"Advanced Qt Programming" - ISBN 0321635906
http://www.qtrac.eu/aqpbook.html
Anschel Schaffer-Cohen
On Friday, October 7, 2011 4:20:31 AM UTC-4, Peter Bourgon wrote:
> usage: go get [importpath...]
> . . .
> . . . it uses the default version for
> the version control system: HEAD for git, tip for Mercurial,
> and so on."tip" is not the default version for Mercurial. It's simply the most
recently committed changeset, regardless of what branch it happens to
be on. Probably what you want here is "default".
Volker Dobler
Append
- Currently only slices have a builtin to bulk update the
content append(s, v...). Should be append be allowed on
maps? In the sense of that append(m1, m2) will add all
new keys from m2 and update all the existing in m1?
Map Deletion
- The syntax of map deletion is a bike shed color discussion:
I would prefer m[k] = _ but a new keyword is fine!
- If a new delete keyword is introduced: Will it be useable
a a rvalue: lastRemoved := delete(m[k])
- Should delete be allowed on slices in the form delete(s[i])
with an (inefficient) semantics of s = append(s[:i], s[i+1:]...)
be allowed? Maybe too returning the deleted element?
os.Error
- error.Value is ugly: You want to return (or store, ...) an
error, not a Value. You wouldn't name a struct with information
about a person "Value" even if the package is called person:
Returning person.Value just feels strange and is not very clear.
Any of the other suggestions are fine.
- I like the builtin interface error { String() } most: Handling
errors is so common (should be so common) that it's worth an
extra builtin.
Goroutines during init:
- Feels like running init.d scripts in parallel. Good luck with
the experiment...
Package time
- Types for durations are (almost) useless if they do not handle
time zone shift (daylight saving) properly.
- How will timezones be handled? Will there be any function to
convert (nano)seconds to other timezones than UTC and local?
Regards, Volker
Russ Cox
> I'm curious though, why has no 'remove' or 'uninstall' command has
> been implemented in goinstall or the new go tool? I have goinstall'd
> libraries to test them and it would be handy, and I imagine simple to
> implement, to simply 'go remove package/cmd' and/or it's depends
> (optional?).
It's on the to-do list.
Russ
Gustavo Niemeyer
> runtime knows about it - it's the only interface that has special
> mention in the specification:
>
> http://golang.org/doc/go_spec.html#Run_time_panics
That's actually runtime.Error, not os.Error.
> perhaps this might be sufficient rationalisation for giving it
> its own place in pkg/builtin.
(...)
> specific error constructors would live in particular packages, as
> currently.
That sounds like a very good idea, though. I was also unhappy with
error.Value, but had no better idea.
os.Error is certainly a widely used type in Go code across the board,
so having it as a standard type always available and with shorter name
would be very handy.
Warm +1.
--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog
-- I never filed a patent.
⚛
> Map Deletion
> - The syntax of map deletion is a bike shed color discussion:
> I would prefer m[k] = _ but a new keyword is fine!
> - If a new delete keyword is introduced: Will it be useable
> a a rvalue: lastRemoved := delete(m[k])
keyword.
Julian Phillips
No, HEAD is right. For a remote, HEAD tells you which is the default
branch, i.e. the branch you will be tracking if you just run git clone.
This is often master (being the default), but it doesn't have to be.
For example, if you clone git://github.com/libgit2/libgit2 you will get
a branch called development, not master.
Locally HEAD refers to what is currently checked out.
In neither case does it behave like tip.
--
Julian
Eric ROSHAN EISNER
Richard Crowley
-1 The fact that some Git subcommands are part of the Git binary and
some are dispatched to git-whatever is confusing, especially when
looking at man pages. I would much prefer Go retain separate tools,
separately documented. Is there any technical advantage to gofmt
being in the same binary as goinstall, anyway?
jimmy frasche
that the former fixedly runs on the tree that go acts on. I can see
the handiness of the shorthand. I don't see why this means gofix and
gofmt need to be jammed in the go binary. Maybe a go walk that
returns all the files that would be effected so you could do mygotool
`go walk` ?
I too do not feel comfortable with error.Value, but I haven't seen a
better suggestion in this thread. Making Error a built-in interface
comes close, because while not special it is certainly ubiquitous and
fundamental. I don't see the worth of jamming any extra interfaces
into builtins, however. Maybe have the Error interface built in and
keep the error package with just:
type Value string
func New(s string) Error { return Value(s) }
func (v Value) String() string { return string(v) }
inside so we still have a place for easily making plain jane string ->
Error values without tying it to a particular package, such as os.
That would give us Error for the type, error for the package, and err
for the variable name.
And +1 for delete(m, k) over delete(m[k]).
Peter Bourgon
Separate tools, separately documented is what we have now. It works
OK. I imagine the Go authors have a good reason to combine them into
one; I would prefer it slightly, as an end user, in the same way I
prefer "hg foo bar" over "git-foo bar".
My point is only that having a simple "wrapper" binary, providing
explicitly limited functionality to other binaries, is the best of no
worlds. It violates the One And Only One edict: the minute you need to
do something slightly complex with eg. gofmt, you're changing not only
the flags but the command. That's confusing and bad. Enabling *some*
common workflows through a special lens on a pool of tools is a false
economy. Better if users know, and use, the authoritative and
unambiguous source.
> It looks like the difference between go fix/fmt and gofix/gofmt is
> that the former fixedly runs on the tree that go acts on.
I understood them as identical, except "go fix" provides only a subset
of the functionality of "gofix." If they do fundamentally different
things, even more reason to eliminate the duplicity. Separate tools,
nearly identically named, with fundamentally different semantics?
Eish, I hope not.