Russ Cox is a g'damn genius. You can spend hours being fascinated by his code and writing: http://research.swtch.com/

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.

> 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.

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

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).

Is it just me, or is he really using the equivalent of Forth's CREATE DOES> ...?

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?

> 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.)

Both of us have just as much evidence. A baseless suspicion is all that I intended to give.

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.

In this case though, it'd really benefit from being visible — all non-editable views into public google docs should be accessible

No it doesn't. Visit it in an Incognito window if you don't believe me.

It's asking for your password because you apparently do have a Google account and it wants to verify your identity before it lets you access things that are tied to your account.

I don't understand how that's different than what the parent was saying

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

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.

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

https://code.google.com/p/go-wiki/wiki/DesignDocuments

There are a lot of interesting reads in there.

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).

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

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

iOS actually doesn't have a restriction as strict as this: you can take a page of memory and map it again without issue. This is the technique used by imp_implementationWithBlock, and current versions of libffi can generate closures based on the technique.

http://landonf.bikemonkey.org/2011/04/index.html

RSC's saying that 1.1's new calling convention removed the need for dynamic code generation.

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

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

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

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

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

I think Windows 8.0 or 8.1 Store application do not allow it.

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?

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.)