Google Fiber's Killer App

It has been a little more than three years since the Kansas Cities — both Kansas and Missouri — won a national competition to be the first places to get Google Fiber, a fiber-optic network that includes cable television and Internet running at one gigabit a second. That is about 100 times as fast as the average connection in the United States. [...]

There aren’t really any applications that fully take advantage of Fiber’s speed, at least not for ordinary people. And since only a few cities have such fast Internet access, tech companies aren’t clamoring to build things for Fiber. So it has fallen to locals — academics, residents, programmers and small-business owners — to make the best of it.

That a single application cannot fully consume the bandwidth available through Google Fiber might just be its killer app. Consider, if it is not likely to disrupt a user's primary task, then it becomes much more feasible to have many background tasks consuming significant amounts of bandwidth. Uses like peer-to-peer, Internet of Things, real-time cloud storage synchronization, etc. are free to operate without limit. 

In a bandwidth constrained world, these type of applications might be hampered (or never deployed) for fear of interrupting a user's primary focus (streaming video, web browsing, or any other primary task that is latency/bandwidth sensitive) or blowing their data cap. However, if you can assume that your secondary application will not be able to consume enough bandwidth to interfere with any other use, then you are free to consume it as you please. With unlimited bandwidth, a file stored remotely might be as accessible as something on a local disk. Multiple peer-to-peer applications could be running without concern. Imagine a common consumer app, like Netflix, becoming p2p. Imagine mesh networks transparently bridging over your fiber connection. 

Take these types of applications and multiply them across a few users or devices sharing a single connection and suddenly something with the bandwidth of Google Fiber becomes necessary. I think the key is to make copious amounts of bandwidth pervasive and the use cases will follow. I doubt we will see some brand new killer app that makes use of the entire connection. Instead, it will be all the apps we have now, just a lot more of them running concurrently across numerous devices. 

Etsy CEO on Net Neutrality

“If internet users find it too difficult to load our websites and see our products, it will be impossible for us to grow or succeed.”

Huffington Post Floating Points Podcast

Give it a listen if you'd like to hear Naz and me talk about our work at Squarespace.

Tom Biegeleisen, Katelyn Bogucki and Andrew Schwimmer are joined by Naz Hassan and Doug Jones who are engineers at Squarespace. The crew discusses the de-evolution of Scrabble words and work attire (Peter Thiel does *not* invest in CEOs who wear suits) and the evolution of blogging and web design.

Learning Go

Go is an interesting language, and it seems to be gaining significant traction as a systems programming language, especially in the web and distributed systems domains.

Here's a quick list of some of my favorite features:

• Statically typed
• Compiled
• First-class functions
• Composition over inheritance
• Concurrency is part of the language
• Package system that acknowledges the Internet

It's certainly an opinionated language, but if your opinions align, I think you will find it to be an enjoyable language.

Concurrency is a very important topic today, if you want to take full advantage of modern hardware you need to have multiple threads execute in parallel on more than one CPU core. (Whether the programmer has to manually manage those threads or not is a separate question, in the end there needs to be some mechanism in the language to start concurrent execution.)

To give you a taste of concurrency in Go, here's a short example.

Here is how you might write a function to sum a list of integers. To gain some concurrency, you could break the list in half and concurrently sum the halves.

Here, I create a short wrapper that accepts a list of int and a channel. Channels are essentially thread-safe FIFO queues. In concurrentSum, a channel of int is created. This will be used by the workers to report back partial sums for each half. I use the defer keyword to execute the given statement when this scope exits. It is a very convenient way to deal with cleanup code that you might put in finally blocks in other languages.

The real magic happens with the go keyword. This will execute the given statement concurrently. Here, I use it to start the two workers that will sum each half of the list. In the final line, I read from the channel twice, and sum the two partials to produce the final value.

This is a pretty dense function, and it shows how easily the concurrency primitives can be combined together to do something that would involve more bug prone boiler-plate in other languages. Concurrency is important, but as a programmer you should not have to suffer through low level locking and visibility issues just to get something basic accomplished. With Go, you get nice primitives that hides these concerns with abstraction. (Don't worry, locks and other basic primitives are there, if and when you need them.)

I think there are some powerful concepts here and I'm excited to try them out on a larger project. It seems to be a fantastic mix of high and low level approaches, I can certainly see why Go is gaining traction.