Thoughts on fireside chat

[Brendan Tracey]

If any of you haven't seen, the fireside chat is up https://www.youtube.com/watch?v=p9VUCp98ay4 . Here are some thoughts I had while watching it

It was commented that profiling tools are very good, which helped bring speed increases: Except for OSX, at least the last time I tried. Is there a chance that this will be fixed anytime soon?

Dependency management: I know this issue has been making the rounds for a while, and I agree with the Go team that people should be aware what they're doing when they use go get. That said, I know what I'm getting into when I download "some random person's github", but I'm not sure what the best practices are with it. A lot of the code I write is for my own uses, as opposed to for production, but at the same time, sometimes I do like to give code to collaborators. Not having a version control specification has positives, one of which is that it makes it easy to gain features and performance from the github package as it is worked on. On the other hand, if the github writer isn't as particular about backward compatibility as I thought, the github code might change in a backward incompatible way. If I'm not continually updating my local copy, I might not realize this change. I am hoping to get advice on best practices in dealing with these issues.

What would you take out?

Ampersand a struct: This feels so natural to me. What else would you do?

The number of ways to declare a variable is too high: What would you take out? I can see that new and struct literals are highly overlapping.

Colon equals for overwrite: Totally agreed. I avoid overwriting variable names. However, could someone point me to a use case where it's well done? I'd be interested in seeing the positive use cases.

Named result parameters: Please keep these in. They are really useful in remembering the order of outputs when you're returning several things. func([]input) (float64, float64) is less clear than func([]input) (sum float64, prod float64)

Variable reused in a for loop being confusing, especially for closures: I'm not sure what this means. Could you give an example of a proper and improper closure with it?

Facilitating concurrency across network: I agree, though I personally would like to see a focus on cluster / supercomputer stuff (I realize that I'm in the minority with that), though I imagine there is significant overlap between the two . It would be awesome if it could be nearly as easy as shared memory. Go circuit kind of looks like it, though I haven't had a chance to really play with it to see if that's true.

Lots of speedups from developments to the runtime and scheduler, and a lot more to come: What kinds of things should we expect to see? Any idea on how much more performance that will bring? Another blanket 40%? Just improvements for multi-core? As I begin to push Go, one of the questions I will get is about the computation speed, and in my world, that's mostly number crunching. Will I have to say "It's not quite as fast as C/C++, but it's way better for safety, compile time, ease of coding, GC, etc.", or will I be able to say "It's as fast as C++ and it's way better, etc."

Source transformation tools: There are some specific packages that involve re-writting source code would be very useful, and were such tools to exist well in Go it would make selling the language easier for me. If I wanted to learn how to write these packages, is reading the go fmt source the best way to learn how to do source transformation, or are there better ways?

Writing the go compiler/runtime in go: A good reason is that all of us here write Go. If the compiler and runtime are written in Go it becomes a lot easier for the community to read and understand what's going on. It would also make it easier for the community to submit patches and improvements (not sure how much that would actually happen). 

Our go compiler is better than the C compiler: Did that mean that there is a go compiler written in Go that the team has, or just that compiling Go code is better than compiling C code?

Thanks for the discussion time.

[Brendan Tracey]

Others should feel free to add their thoughts as well.

[minux]

On Mon, May 20, 2013 at 12:57 AM, Brendan Tracey <tracey....@gmail.com> wrote:

It was commented that profiling tools are very good, which helped bring speed increases: Except for OSX, at least the last time I tried. Is there a chance that this will be fixed anytime soon?

It's a kernel bug. the OS X kernel will happily deliver SIGPROF to any thread that doesn't disable or mask

that signal. However, Go want that SIGPROF to be delivered to a thread that's current executing code

(i.e. not blocked waiting for work).

What would you take out?

Ampersand a struct: This feels so natural to me. What else would you do?

The number of ways to declare a variable is too high: What would you take out? I can see that new and struct literals are highly overlapping.

Colon equals for overwrite: Totally agreed. I avoid overwriting variable names. However, could someone point me to a use case where it's well done? I'd be interested in seeing the positive use cases.

Named result parameters: Please keep these in. They are really useful in remembering the order of outputs when you're returning several things. func([]input) (float64, float64) is less clear than func([]input) (sum float64, prod float64)

Variable reused in a for loop being confusing, especially for closures: I'm not sure what this means. Could you give an example of a proper and improper closure with it?

compare these two for loops:

// improper use of variable i   [http://play.golang.org/p/1D91sWLsSV]

for i := 1; i < 10; i++ {

  defer func() { println(i) }()

}

// corrected  [http://play.golang.org/p/_w1TNbYtUF]

for i := 1; i < 10; i++ {

  defer func(i int) { println(i) }(i)

}

see also: http://golang.org/doc/faq#closures_and_goroutines

Facilitating concurrency across network: I agree, though I personally would like to see a focus on cluster / supercomputer stuff (I realize that I'm in the minority with that), though I imagine there is significant overlap between the two . It would be awesome if it could be nearly as easy as shared memory. Go circuit kind of looks like it, though I haven't had a chance to really play with it to see if that's true.

Lots of speedups from developments to the runtime and scheduler, and a lot more to come: What kinds of things should we expect to see? Any idea on how much more performance that will bring? Another blanket 40%? Just improvements for multi-core? As I begin to

for example: precise GC of stacks, preemptive scheduling. 

push Go, one of the questions I will get is about the computation speed, and in my world, that's mostly number crunching. Will I have to say "It's not quite as fast as C/C++, but it's way better for safety, compile time, ease of coding, GC, etc.", or will I be able to say "It's as fast as C++ and it's way better, etc."

it's very difficult to be as fast as C++, but if you're mainly doing number crunching work, gccgo

should be more suitable than gc as it has a better optimizer. 

Source transformation tools: There are some specific packages that involve re-writting source code would be very useful, and were such tools to exist well in Go it would make selling the language easier for me. If I wanted to learn how to write these packages, is reading the go fmt source the best way to learn how to do source transformation, or are there better ways?

yeah, gofmt should be the first one to read, but be aware that most of its functionality is provided

by the go/printer package, so you might want to read other significant go/* package users (e.g.

go/types)

Writing the go compiler/runtime in go: A good reason is that all of us here write Go. If the compiler and runtime are written in Go it becomes a lot easier for the community to read and understand what's going on. It would also make it easier for the community to submit patches and improvements (not sure how much that would actually happen).

i think eliminating C in the runtime has practical use: we don't need to maintain cmd/cc anymore.

the ease of contribution reason doesn't hold IMO as there will surely be more C programmers than

Go programmers.

Rewriting the compiler in Go is worthwhile but it will have bootstrapping problems (i.e. either we

also maintain a toolchain written in C or we distribute pre-built toolchain binary).

But i don't know if everybody will accept the pre-built toolchain binary given that the author

of "Reflections on Trusting Trust" is in the Go Team ;-).

The last time I asked (~10 months ago), the answer to the question of whether to write a Go

compiler in Go is no, but as there is now go.tools/ssa package, perhaps the team has revisited

this question as the existence of go.tools/ssa greatly simplified the task of writing a Go compiler.

At last, please don't forget that we have llgo (github.com/axw/llgo), a promising project aiming to

implement a Go toolchain based on the LLVM technology.

Our go compiler is better than the C compiler: Did that mean that there is a go compiler written in Go that the team has, or just that compiling Go code is better than compiling C code?

i think this means that cmd/6g is better than cmd/6c.

[Brendan Tracey]

Variable reused in a for loop being confusing, especially for closures: I'm not sure what this means. Could you give an example of a proper and improper closure with it?

compare these two for loops:

// improper use of variable i   [http://play.golang.org/p/1D91sWLsSV]

for i := 1; i < 10; i++ {

  defer func() { println(i) }()

}

// corrected  [http://play.golang.org/p/_w1TNbYtUF]

for i := 1; i < 10; i++ {

  defer func(i int) { println(i) }(i)

}

Thanks. Makes sense. 

[Ian Wetherbee]

On Sun, May 19, 2013 at 11:57 AM, Brendan Tracey <tracey....@gmail.com> wrote:

If any of you haven't seen, the fireside chat is up https://www.youtube.com/watch?v=p9VUCp98ay4 . Here are some thoughts I had while watching it

It was commented that profiling tools are very good, which helped bring speed increases: Except for OSX, at least the last time I tried. Is there a chance that this will be fixed anytime soon?

Dependency management: I know this issue has been making the rounds for a while, and I agree with the Go team that people should be aware what they're doing when they use go get. That said, I know what I'm getting into when I download "some random person's github", but I'm not sure what the best practices are with it. A lot of the code I write is for my own uses, as opposed to for production, but at the same time, sometimes I do like to give code to collaborators. Not having a version control specification has positives, one of which is that it makes it easy to gain features and performance from the github package as it is worked on. On the other hand, if the github writer isn't as particular about backward compatibility as I thought, the github code might change in a backward incompatible way. If I'm not continually updating my local copy, I might not realize this change. I am hoping to get advice on best practices in dealing with these issues.

What would you take out?

Ampersand a struct: This feels so natural to me. What else would you do?

The number of ways to declare a variable is too high: What would you take out? I can see that new and struct literals are highly overlapping.

Colon equals for overwrite: Totally agreed. I avoid overwriting variable names. However, could someone point me to a use case where it's well done? I'd be interested in seeing the positive use cases.

Named result parameters: Please keep these in. They are really useful in remembering the order of outputs when you're returning several things. func([]input) (float64, float64) is less clear than func([]input) (sum float64, prod float64)

Variable reused in a for loop being confusing, especially for closures: I'm not sure what this means. Could you give an example of a proper and improper closure with it?

Facilitating concurrency across network: I agree, though I personally would like to see a focus on cluster / supercomputer stuff (I realize that I'm in the minority with that), though I imagine there is significant overlap between the two . It would be awesome if it could be nearly as easy as shared memory. Go circuit kind of looks like it, though I haven't had a chance to really play with it to see if that's true.

Lots of speedups from developments to the runtime and scheduler, and a lot more to come: What kinds of things should we expect to see? Any idea on how much more performance that will bring? Another blanket 40%? Just improvements for multi-core? As I begin to push Go, one of the questions I will get is about the computation speed, and in my world, that's mostly number crunching. Will I have to say "It's not quite as fast as C/C++, but it's way better for safety, compile time, ease of coding, GC, etc.", or will I be able to say "It's as fast as C++ and it's way better, etc."

Source transformation tools: There are some specific packages that involve re-writting source code would be very useful, and were such tools to exist well in Go it would make selling the language easier for me. If I wanted to learn how to write these packages, is reading the go fmt source the best way to learn how to do source transformation, or are there better ways?

I wrote a source-to-source compiler framework for Go as part of my automatic parallelizing compiler research (https://github.com/wetherbeei/gopar), but it isn't separated into it's own package yet. Would there be interest in that?

 

Writing the go compiler/runtime in go: A good reason is that all of us here write Go. If the compiler and runtime are written in Go it becomes a lot easier for the community to read and understand what's going on. It would also make it easier for the community to submit patches and improvements (not sure how much that would actually happen). 

Our go compiler is better than the C compiler: Did that mean that there is a go compiler written in Go that the team has, or just that compiling Go code is better than compiling C code?

Thanks for the discussion time.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Brendan Tracey]

Source transformation tools: There are some specific packages that involve re-writting source code would be very useful, and were such tools to exist well in Go it would make selling the language easier for me. If I wanted to learn how to write these packages, is reading the go fmt source the best way to learn how to do source transformation, or are there better ways?

I wrote a source-to-source compiler framework for Go as part of my automatic parallelizing compiler research (https://github.com/wetherbeei/gopar), but it isn't separated into it's own package yet. Would there be interest in that?

 

Possibly. I actually downloaded your code a while back when I was learning the basics of Go concurrency. Didn't really dig into the source code beyond that, though looking now it looks pretty useful. In theory, I would have interest, but in practice I don't think I'll have time to use it, so I wouldn't worry about it for my sake.

[Ian Lance Taylor]

On Sun, May 19, 2013 at 9:57 AM, Brendan Tracey
<tracey....@gmail.com> wrote:
>
> What would you take out?
> Ampersand a struct: This feels so natural to me. What else would you do?

Let me start by saying that of course the language is not going to change.

&S{} is like nothing else in the language. It's a special case in the
syntax. Another approach would be to extend the composite literal
syntax to support pointers: (*S){}. That is consistent with other
composite literals: you state the type you want, and then you state
the value.

> The number of ways to declare a variable is too high: What would you take
> out? I can see that new and struct literals are highly overlapping.

I'm not sure what this one was about.

> Colon equals for overwrite: Totally agreed. I avoid overwriting variable
> names. However, could someone point me to a use case where it's well done?
> I'd be interested in seeing the positive use cases.

a, err := F()
if err != nil {
return
}
b, err := G() // A new err would mean two variables with the same name
in the same block. Confusing.
// So we get a new b and the same err.

> Named result parameters: Please keep these in. They are really useful in
> remembering the order of outputs when you're returning several things.
> func([]input) (float64, float64) is less clear than func([]input) (sum
> float64, prod float64)

The language is not going to change. And every feature is useful;
otherwise it would not have been added. The question is not whether a
feature has a use. It is whether it's worth it.

> Lots of speedups from developments to the runtime and scheduler, and a lot
> more to come: What kinds of things should we expect to see? Any idea on how
> much more performance that will bring? Another blanket 40%? Just
> improvements for multi-core? As I begin to push Go, one of the questions I
> will get is about the computation speed, and in my world, that's mostly
> number crunching. Will I have to say "It's not quite as fast as C/C++, but
> it's way better for safety, compile time, ease of coding, GC, etc.", or will
> I be able to say "It's as fast as C++ and it's way better, etc."

For pure number crunching, if you can use gccgo, you should get
results comparable to C++. I think you can do slightly better in C++
with careful use of the restrict qualifier on pointers; there is no
way to state the corresponding restriction in Go using slices, and the
issue will arise when passing a slice to a function to hold the
results.

> Our go compiler is better than the C compiler: Did that mean that there is a
> go compiler written in Go that the team has, or just that compiling Go code
> is better than compiling C code?

The Go compiler (cmd/gc) has had more optimization work than the C
compiler (cmd/cc). The C compiler is only used to compile the runtime
package.

Ian

[David Symonds]

On Mon, May 20, 2013 at 10:24 AM, Ian Lance Taylor <ia...@golang.org> wrote:

>> The number of ways to declare a variable is too high: What would you take
>> out? I can see that new and struct literals are highly overlapping.
>
> I'm not sure what this one was about.

This one was Rob's answer, and I believe it was about the duplication among
var x = 4
var x int
x := 4

[Brendan Tracey]

On Monday, May 20, 2013 10:24:21 AM UTC-7, Ian Lance Taylor wrote:

On Sun, May 19, 2013 at 9:57 AM, Brendan Tracey
<tracey....@gmail.com> wrote:
>
> What would you take out?
> Ampersand a struct: This feels so natural to me. What else would you do?

Let me start by saying that of course the language is not going to change.

Yes, of course.

 

&S{} is like nothing else in the language.  It's a special case in the
syntax.  Another approach would be to extend the composite literal
syntax to support pointers: (*S){}.  That is consistent with other
composite literals: you state the type you want, and then you state
the value.

Okay, I see your point

 

> The number of ways to declare a variable is too high: What would you take
> out? I can see that new and struct literals are highly overlapping.

I'm not sure what this one was about.

Meaning my writing is unclear or you weren't sure what Rob meant.

 

> Colon equals for overwrite: Totally agreed. I avoid overwriting variable
> names. However, could someone point me to a use case where it's well done?
> I'd be interested in seeing the positive use cases.

a, err := F()
if err != nil {
    return
}
b, err := G() // A new err would mean two variables with the same name
in the same block.  Confusing.
                 // So we get a new b and the same err.

Yea, of course, I use this all the time. Hard call. It can lead to mistakes in loops, but it's very useful when intentional.

 

> Named result parameters: Please keep these in. They are really useful in
> remembering the order of outputs when you're returning several things.
> func([]input) (float64, float64) is less clear than func([]input) (sum
> float64, prod float64)

The language is not going to change.  And every feature is useful;
otherwise it would not have been added.  The question is not whether a
feature has a use.  It is whether it's worth it.

Yes. I am making a statement that I think it's worth it. It helps make functions more clear, especially when they return multiple values of the same type.

 

> Lots of speedups from developments to the runtime and scheduler, and a lot
> more to come: What kinds of things should we expect to see? Any idea on how
> much more performance that will bring? Another blanket 40%? Just
> improvements for multi-core? As I begin to push Go, one of the questions I
> will get is about the computation speed, and in my world, that's mostly
> number crunching. Will I have to say "It's not quite as fast as C/C++, but
> it's way better for safety, compile time, ease of coding, GC, etc.", or will
> I be able to say "It's as fast as C++ and it's way better, etc."

For pure number crunching, if you can use gccgo, you should get
results comparable to C++.  I think you can do slightly better in C++
with careful use of the restrict qualifier on pointers; there is no
way to state the corresponding restriction in Go using slices, and the
issue will arise when passing a slice to a function to hold the
results.

Thanks for the input. I guess the real answer then is to write some representative code and do benchmarks. Clearly this is a better answer anyway, but if the answer was "it should be as fast as C++ in time", that's an easier answer than "It won't be quite as fast as C++" which leads to the obvious question of "how much slower", which requires some representative benchmarks. 

I read the wiki article on restrict qualifiers, and I understand the point, but could you elaborate a bit on "the issue will arise when passing a slice ...". Is it just that if I have func([]float64, []float64), the compiler doesn't know that they aren't referring to the same array?

[Ian Lance Taylor]

On Mon, May 20, 2013 at 11:35 AM, Brendan Tracey
<tracey....@gmail.com> wrote:
>
> I read the wiki article on restrict qualifiers, and I understand the point,
> but could you elaborate a bit on "the issue will arise when passing a slice
> ...". Is it just that if I have func([]float64, []float64), the compiler
> doesn't know that they aren't referring to the same array?

Yes, and in particular if your function is

func F(a, b []float64) {
for i, v := range b {
a[i] = v *2
}
}

we can't vectorize the loop because a and b might happen to refer to
the same underlying array at slightly different offsets. That would
be a weird thing to write but the compiler can't assume it is not the
case. In C you can use the restrict qualifier to make clear that a
and b do not overlap.

Ian

[Thomas Bushnell, BSG]

Cross-function analysis in the compiler can handle this in nearly all practical cases. The easiest way (there are cleverer ones) is to compile two versions of the function, and then link the correct one at the call site. If at the call site you can't tell, you do the same thing. In most cases, the whole thing collapses, because it can be determined at compile time (from a whole-program perspective) that the arrays do not in fact overlap.

I strongly believe that when in practical cases a sufficiently clever compiler could figure it out, the right place to spend energy is in teaching the compiler how, and not larding up the language with hints.

Thomas

[minux]

Agree. Go is doing much better in the regard than C.

However, some of these optimization require whole program analysis, can we afford the compilation

overhead?

For example, given a sufficiently smart compiler, (almost) all readonly use of []byte(string) could

be identified, and we might even be able to inline across interfaces.

The problem is, will that happen in the near future so that we don't need to add hint to the language

to solve the current performance deficiencies?

as a concrete example,

should we introduce something like readonly slice to Go or wait for a sufficiently smart Go compiler

that eliminates most of unnecessary copied?

[minux]

On Tue, May 21, 2013 at 7:11 PM, Henry Heikkinen <r...@rce.fi> wrote:

I'm pretty sure named result parameters were mentoined only as an example of often problematic situation with the colon equals operator. I'm sure colon equals would be removed instead of named result parameters if they removed something.

what? IMO, := is one of the essential feature of Go.

for example, if we removed :=, we won't be able to write this:

if a, err := f(); err != nil {}

this is actually a good feature because it restrict the scope of a and err to that

of the then (and else) body, and restricting variable scope is always an aid to

understanding (the reader don't need to keep many live variable bindings in

his or her head).

[Henry Heikkinen]

I agree it's good and most of the time makes life easier but I think many of the problems with it should have never been there. I'm pretty sure we would come up with an alternative way to do the same or just different rules without causing all the confusion.

Just to make it clear I didn't mean it should be removed but IMO any sane person would change the colon equals operator to fit a little better rather than removing the named result parameters.

2013/5/21 minux <minu...@gmail.com>

--
Henry Heikkinen

+368 40 046 7708

Kylänevantie 16 B 33

00320 Helsinki

[minux]

On Tue, May 21, 2013 at 8:57 PM, Henry Heikkinen <r...@rce.fi> wrote:

I agree it's good and most of the time makes life easier but I think many of the problems with it should have never been there. I'm pretty sure we would come up with an alternative way to do the same or just different rules without causing all the confusion.

Just to make it clear I didn't mean it should be removed but IMO any sane person would change the colon equals operator to fit a little better rather than removing the named result parameters.

i think we can remove neither of the features. actually, why do you think it's the fault

of := alone? if you look at the relative usage frequency of both features, i think we'd

remove named return value if anything. however, named return value does have some

nice uses like providing documentation and capture return value for defers, so it is

likely to stay.

in fact, the consensus seems to be to only use named return value only when the

function is small and it adds to the documentation (see Andrew's google+ post  https://plus.google.com/+AndrewGerrand/posts/LmnDfgehorU about Brad's thought

on using named return values and bare return statements)

the fact that they don't mix well doesn't mean we should change them at the cost of

extra special cases and hurting orthogonality.

the compiler already refuses programs where at the point of return, some of the

named return value are shadowed.

[Michael Jones]

You can also trivially generate code for the two (or N) cases with a quick switch at the top. Version 1 is general/normal and Version 2 is unrolled & loop jammed, or vectorized, or AVX, or whatever and the guard expression:

"len(a) >= len(b) && addr(a) + minWidth*sizeof(float64) > addr(b)"

computed at the start with a branch to the right place, general or fancy. You have to do the first part of this anyway for memory verification, and the second is just a constant compared with the value in the passed in pointer.

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1 650-335-5765

[Ian Wetherbee]

I have handled the cases of memory aliasing and cross-functional analysis in my gopar parallelizing compiler (https://github.com/wetherbeei/gopar). As for the speed, it analyzes these packages, writes the new AST and runs the go compiler in 13 seconds on my laptop (most is spent in the fmt package):  errors unsafe math unicode/utf8 strconv sync/atomic sync io runtime syscall time os reflect fmt sort flag math/rand nbody_shootout.

Ian Wetherbee

[Paulo Pinto]

Given the compilation speed of Turbo Pascal, Delphi and similar
languages in the late 90's with the available hardware,
I sometimes tend to think there is too much worries about the impact
of changes to Go's compilation speed.

On 21 Mai, 17:48, Ian Wetherbee <ian.wether...@gmail.com> wrote:
> I have handled the cases of memory aliasing and cross-functional analysis
> in my gopar parallelizing compiler (https://github.com/wetherbeei/gopar).
> As for the speed, it analyzes these packages, writes the new AST and runs
> the go compiler in 13 seconds on my laptop (most is spent in the fmt
> package):  errors unsafe math unicode/utf8 strconv sync/atomic sync io
> runtime syscall time os reflect fmt sort flag math/rand nbody_shootout.
>
> Ian Wetherbee
>
>
>
>
>
>
>
> On Tue, May 21, 2013 at 9:25 AM, Michael Jones <m...@google.com> wrote:
> > You can also trivially generate code for the two (or N) cases with a quick
> > switch at the top. Version 1 is general/normal and Version 2 is unrolled &
> > loop jammed, or vectorized, or AVX, or whatever and the guard expression:
>
> > "len(a) >= len(b) && addr(a) + minWidth*sizeof(float64) > addr(b)"
>
> > computed at the start with a branch to the right place, general or fancy.
> > You have to do the first part of this anyway for memory verification, and
> > the second is just a constant compared with the value in the passed in
> > pointer.
>

> > On Tue, May 21, 2013 at 5:32 AM, minux <minux...@gmail.com> wrote:
>
> >> On Tue, May 21, 2013 at 3:16 AM, Thomas Bushnell, BSG <

> >> tbushn...@google.com> wrote:

> >>> compiler *could *figure it out, the right place to spend energy is in

> >>> teaching the compiler how, and not larding up the language with hints.
>
> >> Agree. Go is doing much better in the regard than C.
>
> >> However, some of these optimization require whole program analysis, can
> >> we afford the compilation
> >>  overhead?
> >> For example, given a sufficiently smart compiler, (almost) all readonly
> >> use of []byte(string) could
> >> be identified, and we might even be able to inline across interfaces.
> >> The problem is, will that happen in the near future so that we don't need
> >> to add hint to the language
> >> to solve the current performance deficiencies?
>
> >> as a concrete example,
> >> should we introduce something like readonly slice to Go or wait for a
> >> sufficiently smart Go compiler
> >> that eliminates most of unnecessary copied?
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "golang-nuts" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an
> >> email to golang-nuts...@googlegroups.com.

> >> For more options, visithttps://groups.google.com/groups/opt_out.