uriel

This is one of the greatest efficiency advantages of Go over Java, for the same task, Go code uses only a tiny fraction of the memory of what Java uses.

http://shootout.alioth.debian.org/u64/benchmark.php?test=all...

The lack of return statements is rarely missed, although it could be handy in some cases, there are ways around it.

There is nothing weird about ifs' behavior once you understand it.

Byron's rc tried to 'fix' ifs, and made everything worse.

rc is a truly beautiful thing.

I wrote a pretty complex web framework and CMS with it ( http://werc.cat-v.org ), and the more I used it, the more I loved it.

I found it to be extremely well crafted, with every feature fitting beautifully with the rest, it misses many fancy things people expect, but once you know your way around what it has, you can do almost anything.

Like awk, is one of those few languages that you can fully keep in your head, and that plus the power of calling other Unix/Plan 9 commands makes it very effective.

> Not sure what SIP or XMPP are "monstrous" though.

Both SIP and XMPP are way beyond "monstrous", hundreds of specs, and most implementations are not really interoperable beyond the very basics. (XMPP is still barely at the level irc reached almost 20 years ago, and that is after ten years of and ever growing and changing list of specs, which is actually the problem).

This is one of the reasons why I don't buy the whole concept of "intellectual property": the only thing that should matter is the quality and value provided to consumers; not marketing, not ideas, not strategy, but the end result, which as many have pointed out before is mostly execution, but whatever the path one gets there, only product standing on its own merits should matter.

The cost of complexity in the compiler is not only to the persons implementing it.

Also I'm pretty sure the amount of work in the compiler was only one of the considerations, and while I don't doubt your account of your conversation with rob, I doubt it was the main consideration in this design decision.

Channels + select are a pretty good replacement for what one usually uses pattern matching in Erlang.

There are pros and cons for both models, but they are roughly equivalent and I never missed pattern matching in Go.

I think Rob Pike discusses some of the differences between the Go and Erlang CSP-like models:

http://confreaks.net/videos/115-elcamp2010-go

> I think its somewhat naive to think that it won't be hard to surpass the JVM.

Go already surpasses the JVM in many areas, for example it has magnitude orders lower memory usage, and even in performance it already beats it in quite a few benchmarks, see:

http://shootout.alioth.debian.org/u64/benchmark.php?test=all...

And this is without the simple optimizations that are coming soon to Go, and even after that Go still will be able to improve performance greatly without too much effort.

This is another area where Go prefers pragmatism over everything else.

When Go is involved, it is better to compare the 64bit compilers which are the ones used by almost everyone:

http://shootout.alioth.debian.org/u64/benchmark.php?test=all...

Go is already faster than Java in half of the benchmarks, and uses dramatically less memory.

Of the benchmarks where Java wins, at least one (regexp-dna) is not related to the language at all and only to the regexp implementation, the one used there is a toy, Russ Cox already has written a much better high-performance regexp implementation based on re2 for Go which should replace the existing one very soon.

Also, there still plenty of low hanging fruit to optimize in Go, both in the compilers and GC, so surpassing Java wont be hard.

And Go's memory usage is already magnitude orders better than Java.

Yea, self-hosting is neat, but also makes bootstrapping much more complicated, specially when the language is still changing.

Standard Go doesn't need JIT, it is all compiled to native code already.

Your idea sounds a bit like Milton Friedman's negative income tax.

Yes, intellectual property is completely contrary to free markets and personal liberty, in its essence is a system of government-granted and government-enforced monopolies, and how anyone can think that is compatible with liberty economic or personal boggles the mind.

This is a strawman, nobody is arguing that people should not be allowed to demand compensation for their work, authors and musicians were able to demand compensation no differently from anyone else before IP came around, the problem is the demand that they should be granted a monopoly and control over the physical property of others, that is what IP is.

That hasn't stopped taxes on CDs, DVDs and even external hardisks in many countries which supposedly then get redistributed to "creators" (ie., the record/film industry cartels).

So yea, it is pretty horrible, like most of the "intellectual property" system (just look at patents..).

> Whilst I appreciate the effort that people put into these things, I really don't like this sudden obsession of adding another layer of abstraction over everything.

This is one of the reasons I found Google's Go so refreshing, it actually removed layers of abstraction bypassing even libc while providing a clean and portable interface to write my programs. Instead of making the stack of abstractions even higher as for example Java does, they cut it to the root.

Note that the Plan 9 team at the time were already working on Alef ( http://doc.cat-v.org/plan_9/2nd_edition/papers/alef/ ) and would later develop Limbo ( http://doc.cat-v.org/inferno/4th_edition/limbo_language/ ) as the language for the Inferno distributed system ( http://doc.cat-v.org/inferno/ )

Then why I can't easily export my friends list from Facebook to Google+?

> I know OSX uses something like a micro-kernel and it is a perfectly fine desktop OS,

OSX doesn't use anything like a micro-kernel, it runs Mach (which even microkernel fans ridicule, it is bigger than many monolithic kernels like the Plan 9 kernel), with a monolithic BSD-style kernel directly on top, when your microkernel has (being generous) two components, both huge, I don't think it is like what most people consider a microkernel at all.

It is also fun to remember that people also claimed Windows NT was a microkernel, and then they added the graphics system right into the kernel.

Union mount functionality is not something that needs to be done in userspace, Plan 9 has union mounts, but that is one of the few things it does in kernel, for details see: http://man.cat-v.org/plan_9/2/bind

The key thing is to have simple, clean and well defined semantics, this is much harder when your VFS is polluted by stuff like symlinks and other weird kinds of pseudofiles.

I know Al Viro has wanted to have proper union mounts in Linux for many years, but getting proper private namespaces was hard enough, and now nobody uses them, which is sad (but more the fault of the suid-centric userspace environment than of the kernel, if you have to be root to create a new namespace, it is rather pointless).

This is amusing given the topic at hand, and what the Plan 9 people thought of Tanenbaum:

http://harmful.cat-v.org/software/andy_tanenbaum

cough Plan 9[1] cough

[1] http://doc.cat-v.org/plan_9/4th_edition/papers/names

The absurdity of so called "intellectual property" becomes ever more patent.

See this: http://code.google.com/p/go/source/detail?r=35b716c94225

tl;dr: It is Apple's fault, OS X is buggy and so far there are no known good workarounds, if you know any I'm sure Russ would love to hear about it.

Rob Pike and Brian Kernighan warned about this trend in their seminal paper "Program Design in the UNIX Environment" (also known as "cat -v considered harmful" which describes how proper unix programs should be designed:

http://harmful.cat-v.org/cat-v/

This is one more reason why I love dynamic linking, fork/exec for static binaries is much faster than for dynamic ones, even for simple C programs that only use libc.

For anyone interested in this kind of archaeology I have put together a web interface for the 1st Edition manual pages:

http://man.cat-v.org/unix-1st/