
Go 1.1 Function Calls - obilgic
https://docs.google.com/document/d/1bMwCey-gmqZVTpRax-ESeVuZGmjwbocYs1iHplK-cjo/pub
======
staunch
Russ Cox is a g'damn genius. You can spend hours being fascinated by his code
and writing: [http://research.swtch.com/](http://research.swtch.com/)

~~~
waterside81
Not only that, he's really helpful on the Golang Google group in answering
questions to all programmers, new & old. What really hooked me onto Go was
both the helpfulness of the Google group as well as the nice people on
#gonuts.

~~~
chimeracoder
> What really hooked me onto Go was both the helpfulness of the Google group
> as well as the nice people on #gonuts

Same here, which is why I like to idle in the channel when possible (and
occasionally answer questions when I can).

People often underestimate how much impact the community behind a language
has. The Go community has been one of the friendliest, and also one of the
most willing to share its knowledge.

FYI, it's #go-nuts, just in case anybody reading this is inspired to check it
out.

~~~
regularfry
I don't think it's accidental that people used to the same about the ruby
community.

~~~
spoiler
I find the Ruby community is still very friendly (maybe I am just reading too
much into the past tense of your statement) and I was so delighted when I
found out that the Go community was the same.

When reflecting at certain events a few years ago I remember that I was put
off from learning <a language> because I stumbled upon some hostility within
the community (I was just an observer in the incident, but it still affected
me).

Reading some of the comments made me realise the friendly community and
"healthy ecology" of a programming language are _very_ important (Disclaimer:
that's my personal experience).

------
js2
OT: if Google thinks you have an account (based on a cookie I guess) it
requires you to login to access this document. So you either need to login or
delete the cookie or enable incognito/private mode to access the document.

Why doesn't google treat non-logged in users the same as those w/o an account?

~~~
jlgreco
> _Why doesn 't google treat non-logged in users the same as those w/o an
> account?_

I wager what they actually want to do is treat those without an account the
same as those who are not logged in, but realize they can't get away with that
quite yet. (That is to say, I suspect that they would _like_ to turn away all
users without accounts.)

~~~
enneff
That's a baseless assertion.

I'd assume (and I have no insider knowledge) that it's because Google assumes
if you have a Google account that you probably want to be logged into it when
using Google products. Otherwise it would suck if you tried to do something
that requires an account and were told "log in" and then had to refresh the
page, potentially losing state. The up-front login avoids some usability
issues there. (Of course there are many ways to approach this, this is merely
my hypothesis.)

~~~
GauntletWizard
With some insider knowledge: Because this document is commentable for (some)
Googlers, though you don't see the comments on the /pub version that is
accessible externally. Docs would rather force you to verify your state
(Logged in or anonymous) than having some things 'not work' because you're
expecting permissions from login cookies you don't have.

------
apgwoz
Wait. This is pretty much just "closure conversion," which is a standard, and
widely known technique. Did I not read carefully enough?

~~~
barrkel
In the abstract, sure; but what it was doing before was also "closure
conversion". The interesting bit is in the specific implementation details.

Closures need the combination of code and data. There are multiple
implementation strategies to pair the two together though. Delphi, for
example, has implemented method pointers for a very long time as a pair of
pointers, one code and one data.

When I added anonymous method support, that wouldn't fly because it doesn't
handle account memory management (Delphi is not garbage collected). So I
implemented a different form, using COM-style interfaces, where the code
pointer is the first method after QI, Addref and Release. Since Delphi had
auto-refcounting support for COM pointers, this solved the dynamic closure
allocation problem; and since it was language independent, it solved the C++
interop problem.

------
kisielk
There's a list of various Go design documents maintained on the Go wiki:

[https://code.google.com/p/go-
wiki/wiki/DesignDocuments](https://code.google.com/p/go-
wiki/wiki/DesignDocuments)

There are a lot of interesting reads in there.

------
micro_cam
I got something like a 30% speed up switching go 1.0 to go 1.1 with some code
that used a closure.

It is number crunching code (random forests) but go 1.1 is faster then gccgo
as well (though i haven't tried the latest version of that).

------
twotwotwo
Not much to look at, but you can easily play with bound instance methods like
the r.Read example in the doc at the playground:
[http://play.golang.org/p/lnfidH3usx](http://play.golang.org/p/lnfidH3usx)

------
safetydank
Ios disallows dynamic code generation at runtime - what other environments
could Go target with these restrictions?

~~~
mortdeus
Native Client, Android, ummm, pretty much any environment that is encapsulated
in a sandbox.

~~~
safetydank
Ah yes, Native Client. I assume Android allows it since it runs V8.

~~~
mortdeus
I guess Android has a different kind of sandbox than most typical software
fault isolation based sandboxes (e.g. NaCl).

Its more reminiscent of plan9's per process namespaces than anything else.
[http://plan9.bell-labs.com/sys/doc/names.html](http://plan9.bell-
labs.com/sys/doc/names.html)

Regardless, the main issue that was preventing Go from running on Android was
the linker's inability to link go pkgs as a shared library. Fortunately
support for external linking on ARM is scheduled to land in the go1.2 release.

[http://tip.golang.org/doc/go1.2#gc_changes](http://tip.golang.org/doc/go1.2#gc_changes)

When it comes to go support for NaCl, llgo is imho the most promising solution
for that. [http://github.com/axw/llgo](http://github.com/axw/llgo)

------
andrewcooke
is 10 possible combinations of function and call a good thing? it seems odd to
me. are other languages like that? having such a large number(?) seems to
imply that the language has lots of special cases. which is worrying, isn't
it? wouldn't it be better (all other things being equal) to have a smaller
number of ways that function calls work?

~~~
gsg
It's fine since all the detailed goop is at the implementation level.
Programmers need not care.

Making a distinction between known and unknown calls in the implementation is
not only a good thing, but in a language with first-class functions it is all
but inevitable because the performance win is so large. (The majority of calls
are known, and known calls can be compiled significantly more efficiently than
any general purpose call machinery.)

