That's a lie. There must be a half dozen providers for high-speed Internet service where I live, in podunk Spokane, WA (pop. 205,500).
Okay, is it a truly free market? No, usually a lot of the private infrastructure is paid for in taxes, which is certainly not free. But there sure as hell are options (2+) in most mid-sized cities and higher. Don't forget about wireless and third-party DSL providers.
So, what has Go brought to the table?
Go is designed with internal messaging capabilities, intended to simplify the creation of applications running on different nodes, and improve their performance.
"It's a way to try to address how to write concurrent software that's more robust, as opposed to using the old threading model of Java and others," Voss said.
In this regard, Go offers "a new programming paradigm" that makes it easier to solve a wide variety of programming problems by simplifying many types of parallel processing.
No, Go doesn't bring anything new to the concurrency table. The two things I've seen about Go concurrency that are regarded as special are M:N/"green" threads and CSP-style channels.
M:N threading is an implementation detail of a language runtime. Whereas the standard library of a language might specify how threads are available to client applications (programs written in the language), it's best left to the implementation (runtime or compiler) to decide how to translate those threads onto the machine. Some implementations might want to focus on scalable, high-performance threading, and so they'd choose M:N. Some others might emphasize simplicity, and map language threads directly to OS threads. What Go has done is standardized this implementation detail into the language specification. (I don't think that's a good idea, but that's a matter of taste.) Other language implementations offer M:N threading, including GHC and (I think) Erlang.
On channels: they're cool. I love them. But there's a lot of prior art here, and many languages have great CSP-style channel libraries written for them that offer the same great flavor of relatively safe message passing and alternation between sets of channels:
- Communicating Sequential Processes for Java (JCSP)
- CHP: Communicating Haskell Processes
- Plan 9 libthread for C (and not just Plan 9, thanks to plan9port)
- and my own: Calispel for Common Lisp
In summary, I just don't get what the buzz with Go is about, besides that it's Google's very own language.
There's little or nothing original that's being presented here. The Phantom people claim originality to the idea of orthogonal persistence, but they are flat-out wrong:
Q: File system?
A: Nope. Sorry. Nobody needs files in Phantom. All the operating system state is saved across shutdowns. Phantom is the only global persistent OS in the world, AFAIK. All the state of all the objects is saved. Even power failure is not a problem, because of the unique Phantom's ability to store frequently its complete state on the disk.
To illustrate the utility and awesomeness of persistence, there's a famous story about KeyKOS, an earlier OS that embraced this notion:
At the 1990 uniforum vendor exhibition, key logic, inc. found that their booth was next to the novell booth. Novell, it seems, had been bragging in their advertisements about their recovery speed. Being basically neighborly folks, the key logic team suggested the following friendly challenge to the novell exhibitionists: let's both pull the plugs, and see who is up and running first.
Now one thing Novell is not is stupid. They refused.
Somehow, the story of the challenge got around the exhibition floor, and a crowd assembled. Perhaps it was gremlins. Never eager to pass up an opportunity, the keykos staff happily spent the next hour kicking their plug out of the wall. Each time, the system would come back within 30 seconds (15 of which were spent in the bios prom, which was embarassing, but not really key logic's fault). Each time key logic did this, more of the audience would give novell a dubious look.
Eventually, the novell folks couldn't take it anymore, and gritting their teeth they carefully turned the power off on their machine, hoping that nothing would go wrong. As you might expect, the machine successfully stopped running. Very reliable.
Having successfully stopped their machine, novell crossed their fingers and turned the machine back on. 40 minutes later, they were still checking their file systems. Not a single useful program had been started.
Figuring they probably had made their point, and not wanting to cause undeserved embarassment, the keykos folks stopped pulling the plug after five or six recoveries.
The notion of a language-based OS exploiting the semantics of pointerless/"safe" programming languages in order to isolate processes, rather than the norm of executing untrusted native machine code in different address spaces, is nothing new either.
If these ideas shift your bits, take a look at some real, interesting work done by real people that have more clue than fashion:
- Coyotos, an OS whose orthogonal persistence falls out of the capability model of security that they embrace. Coyotos is written in BitC, a purpose-built high-level programming language with special focus on formal semantics and reasoning.
- Singularity, a language-based OS in development by none other than Microsoft Research. (Certainly the most interesting Microsoft project that I am aware of.) Singularity exploits language semantics to isolate processes.
- TUNES, a collective wet-dream of what the OS, programming language, and generally computing system of tomorrow should look like. With all due respect towards the insurmountable difficulty and endless complexity of a task like this, it must be said that TUNES is just vaporware.
The brilliant thing about anarchocapitalism is that if I dislike a company, I can choose to not do business with them. With the current system, I can wait until election time, try writing letters, and waste a lot of time drumming up support and persuading people. Or expatriate. With everything that I don't like about the US, that would be a full-time job to do properly.
I believe a private system is more fluid to change than a bureaucratic one.