Please keep them coming. Will watch every single one, multiple times! Loved hearing your thought process and confidence with what was being typed. Now when I code I pretend I'm talking to either of you. It's not weird, right?
Not to take away from the awesome videos now, but I'm a bit sad we won't see anything like this from the LiveJournal/memcached/Danga era - that would have been great watching, I suspect, from my memory of yours and whitaker's posts :-D
The port is Go 1.4+, and it's based on upstream dev.cc branch.
I intend to propose for inclusion into Go 1.5 after finding a way
to test it (either build each test as an App, or use the open source
xnu/arm port). Brad mentioned that inclusion of iOS support might
happen in Go 1.5 in his talk the state of the gopher
I believe it really will happen.
The iOS port is my first Go OS port, but it's the only one that takes
almost 3 years to complete. :)
Go build iOS Apps. Let's see when can we see a Go based App in
Ken and I ported Plan 9 to the SPARC in 6 days over one fun Christmas break.
I wrote the disassembler (for the debugger) and Ken wrote the assembler, so we could cross-check each other's work. The hardest problem other than fighting register windows occurred when we both misread the definition of an instruction the same incorrect way.
> An explicit goal for Go from the beginning was to be able to build Go code using only the information found in the source itself, not needing to write a makefile or one of the many modern replacements for makefiles. If Go needed a configuration file to explain how to build your program, then Go would have failed.
And the hope is that go generate would be a hook into the dependency graph of go build. Much like the architecture switches, the naming conventions, etc, it seemed like it really could have solved my project's protobuf problem.
But it's not, and for reasons that rob pike's doc and the mailing list did not make clear. It looks like a mis-step to me, and I don't think it's due to my misunderstanding of what `go build` and 6g/gccgo are
The go team has decided that the go language doesn't depend on any build system, but pushes a single build system one that requires source code compatibility and provides no benefit over many existing and easy to use build systems (makefiles, tup, etc).
The original motivation for putting it into the standard library is so the 'go' command can use it, to watch the filesystem and know what needs to be rebuilt before you even run "go install" or "go build".