[Detrus]

But in practice, how many bad abstractions are there? From what I understand the Go team sees VMs as bad abstractions and they're ubiquitous.

The Go compiler can be fast, essentially as fast as a VM. Go can already run ~3x slower than C and they haven't put much effort into optimization. V8 is ~5x slower with a larger team working longer, 50,000 LOC compared to ~12,000 LOC of Go. To get the security of a VM they discourage the use of low level stuff by putting it into an unsafe package. This makes the binaries compatible with NativeClient, which actually checks for malicious programs. Go code can be sent as text and compiled quickly enough client side.

So they get many of the features of a VM while cutting down on complexity with some clever tradeoffs. The language is not for everyone's tastes, but their fundamental approach will surely lead somewhere.

In practice people make bad abstractions constantly and build huge legacy on top of them. Lately people have been trying to clean up the mess by starting from a pretty low level, like Go and Redis.

[dantheman]

GO is designed for distributed systems that can't afford a garbage collection hit. A function is running on one machine, and it calls out for data from 10 other machines - if one of those has a hiccup to garbage collection (i.e. it responds 1 minute later instead of 10ms) then function fails, or is delayed tying up resources.

This is my understanding of why Google is developing, I'm not too familiar with it though.

[jonburs]

Go is a garbage collected language: http://golang.org/doc/go_faq.html#garbage_collection

[dantheman]

thanks, i was misinformed.