Marius Eriksen

So! To recap the bits, and where this all stands now:

The end goal is to implement "Your Server is a Function" https://monkey.org/~marius/funsrv.pdf , that is, built on top of three primitives:

1. Futures

2. Services, which are functions of Request -> Future<Response>

3. Filters, which takes a Request and a Service, and returns a Future<Response>

To do this, Tokio is built up of multiple packages that each have a focus.

At the lowest layer, you have two primitive libraries: futures and mio. Futures are a generic, no-allocation abstraction that looks something like this: https://docs.rs/futures/0.1.6/futures/future/trait.Future.html

pub trait Future {
type Item;
type Error;
fn poll(&mut self) -> Poll<Self::Item, Self::Error>;
}

... and a bunch of more interesting methods built on top of poll. Futures, as you can see, can be generic over the kind of value they produce, as well as possible errors while producing said value. poll drives the future forward, and should never block. Usually, you don't call poll directly, you create a Task, which represents a chain of futures, and tell it to run. It will then handle doing the right thing, calling the right methods in the right ways.

The second component is mio. Mio is a low-level, asynchronous I/O library, that gives you the standard event loop stuff. In other words, it's a very thin wrapper around epoll/kqueue, and has an adapter to make iocp fit. There are deeper reasons that readiness was chosen…

This is about system programming where system must be understood as a composition of several networked systems.

It's different from a single-node system like pure kernel software e.g. hdd drivers, among other things it's higher level.

For instance you have to deal with the Two Generals' Problem. They are "expert systems" which relates more to kernel dev and where kernel knowledge is required, like databases. Expert systems even distributed expert systems are meant to solve well identified problems, they are the CPU, GPU and HDD of the global system.

Usually the higher in the stack you go, the more specification of the logic that must be implemented is loose:

- less standardized

- less identified

Everywhere Logic is a moving target, like so called "business logic", the way you express the logic is very significant. Otherwise, said "code design" and code maintainability is a significant "business asset" as it allows to react quickly to change.

All the thing that are described in the slides are the features of the Scala language and platform that twitter think allows to write code "that is well designed upon which you can react quickly".

Mind the fact there is nothing specific in what was describe only to Scala as language or platform except maybe that it's build upon the JVM and that it's static typed.

Code design, code look'n'feel especially in context that involves concurrency is not a new or specific to distributed systems.

The most important point in the 11th…

The whole point of Linkerd is moving logic out of your app. Linkerd is like a library but, instead of being in-process, it inserts itself between the app and whatever the app needs to talk to. The app just dials http://foo.svc/, and Linkerd sends the connection to the right place; it doesn't need to know where foo.svc is.

Many companies, including mine, already run an internal load-balancer (such as HAProxy) that takes care of routing traffic between microservices. Linkerd replaces this with something that is explicitly designed to deal with inter-app communication. (I believe one way to run Linkerd is as a small sidecar app inside the same Docker container the man app, as opposed to a big central server, which is also a neat way of doing it.)

Re "why not a library" — sure, you can build all sorts of discovery, distribution and resilience into the client itself. But that consolidates all of this intelligence into just that client. What if you use multiple languages? What about third-party client libs (e.g. Memcached, Redis, PostgreSQL) that you don't control and that you don't want to reimplement? You'll find yourself reimplementing the same thing over and over.

> you can't "drop in" resiliency

I recommend reading the documentation, because drop-in resilience is really the whole point. The guys who built Linkerd previously developed Finagle [1], which is Twitter's RPC library, and when they talk about network resilience, they actually know what they're talking about…

I'm using actix-web in my work and am familiar with the project, so I'll try to summarize for everyone why this 1.0 release is so significant.

This is a major milestone for the entire Rust community because we now have the first web framework written in stable Rust with an architecture that a credible author has deemed worthy of maintaining backwards compatibility for and a code base mature enough to have earned a 1.0 designation. This is real progress.

The architecture of actix-web 1.0 is very different from that of 0.7. In many respects, it was a rewrite that began last Summer. The architecture is no longer based on an actor paradigm but rather one of Services, largely inspired by Eriksen et al's finagle work [1] adopted at Twitter. This service architecture is accessible through a library known as actix-net. Essentially, actix-web is a web-based actix-net server. If actix-web were bitcoin, actix-net would be its blockchain. Because of this, actix-net may be even more significant to the broader Rust community. The actor models can still be imported and used but no longer act as the default mechanisms driving the server.

Regarding performance, according to the Tech Empower benchmarks that evaluate hundreds of web frameworks across all major languages, actix-web is top-ranking [2] and first in a few benches. The last benchmark represents a beta version of actix-web from last month and results may have slightly improved with 1.0. actix-web is very modular, allowing…

On topic then, this is the first time I see Scala syntax and was somewhat pleasantly surprised (the only languages I really know are JavaScript and Python).

On slide http://monkey.org/~marius/talks/twittersystems/#16:

case class Stock(ticker: String, price: Double) {
def <(other: Stock) = price < other.price
}

val goog = Stock("GOOG", 675.15)
val aapl = Stock("AAPL", 604.00)

aapl < goog == true
goog < aapl == false

Correct me if I'm wrong but it seems to me that the class Stock gets a method called "<". So appl.< google (or the other way around) would also work. The previous slide also shows this, but the Stock example is makes it even clearer that "Scala is a pure object oriented language: every value is an object." appl and goog are objects, of type Stock, and < is an object, a method of Stock.

I wonder if this kind of method would work

def ==(other: Stock) = price != other.price

and what would happen if it was like this

def ==(other: Stock) = self != other

(where self would be a reference to the Stock instance, ala python, or this in javascript)

and it was invoked like this

appl == goog

and return true

If you take slides 52[1] to 63[2], you can see the emphasis put into run-time diagnosis.

Which is really important for largely distributed systems. Google wrote a little about it when they introduced their global run-time performance tracing tool called Dapper[3] in "Dapper, a Large-Scale Distributed Systems Tracing Infrastructure"[4]"

Modern Internet services are often implemented as complex, large-scale distributed systems. These applications are constructed from collections of software modules that may be developed by different teams, perhaps in different programming languages, and could span many thousands of machines across multiple physical facili- ties. Tools that aid in understanding system behavior and reasoning about performance issues are invaluable in such an environment.

[1] http://monkey.org/~marius/talks/twittersystems/#52

[2] http://monkey.org/~marius/talks/twittersystems/#63

[3] http://highscalability.com/blog/2010/4/27/paper-dapper-googles-large-scale-distributed-systems-tracing.html

[4] http://research.google.com/pubs/pub36356.html