“Coroutines are computer program components that generalize subroutines to allow multiple entry points for suspending and resuming execution at certain locations. Now, I can already hear the gophers scream “CHANNELS”! Yes, spoiler alert, channels will be summoned, but the goal is to build a higher-level abstraction that mimics as close as possible Lua’s coroutine.* API and features…”
“To understand Go’s memory management it’s necessary to dig a little into the Go run-time code. There are two separate processes that take care of identifying memory that is no longer used by the program (that’s garbage collection) and returning memory to the operating system when it doesn’t look like it will be used again (that’s called scavenging in the Go code)…”
“After running Go for two years in production at Iron.io, I wanted to share our experience/feelings about it. We were one of the first companies to use Go (golang) in production and we didn’t know what to expect in the long run, but so far, so great.
I talked a little about about this in a previous post about switching to Go from Ruby, but this will go into specific things that we love about the language, the things we learned along the way. In no specific order, here they are: Performance, Memory, Concurrency, Reliability, Deployment, Talent…”
“Building the backend infrastructure at Tamber, we have to solve difficult challenges with limited resources and tight budgets. Our entire infrastructure, making real-time recommendations for thousands of users, runs on a simple Amazon EC2 setup for $150/month. We need to make every CPU cycle count.
One of our greatest challenges has been building a flexible, yet high-performance search engine that interfaces with our Go backend. The result is the open-source project Ferret – it handles error correction, sorts the results, and doesn’t hog resources
Below is a demo running on a single micro EC2 server (free tier)…”
“I’m gonna eat my own dog food here, and start you off with a collection of links and ideas of people using Redis. Redis’ particular way of treating data requires some rethinking how to store your data to benefit from speed, atomicity and its data types. I’ve already written about Redis in abundance, this post’s purpose is to compliment them with real-world scenarios. Maybe you can gather some ideas on how to deal with things.
There’s a couple of well-known use cases already, the most popular of them being Resque, a worker queue. RestMQ, an HTTP-based worker queue using Redis, was just recently released too. Both don’t make use yet of the rather new blocking pop commands like Redactor does, so there’s still room for improvement, and to make them even more reliable.
Ohm is a library to store objects in Redis. While I’m not sure I’d put this layer of abstraction on top of it, it’s well worth looking at the code to get inspiration. Same is true for redis-types…”
“twemproxy (pronounced “two-em-proxy”), aka nutcracker, is a fast and lightweight proxy for memcached and redis protocol. It was primarily built to reduce the connection count on the backend caching servers. Twemproxy was created within Twitter to initially support Memchace with Redis support being added 4 months ago…”
“Our follower graph has millions of nodes and billions of edges, making it an interesting challenge to maintain and scale data as we build out the interest graph. The model is similar to those of Twitter or Facebook, but with some key differences based around interests that we account for in the product development and design phases.
The final version of the Pinterest follower service was developed, migrated and deployed in about 8 weeks with one full time engineer and 2-3 part time engineers.
Here I’ll explain how the service-oriented architecture has helped us develop and maintain the service as a unit of its own…”