
Systems Programming at Twitter - DanielRibeiro
http://monkey.org/~marius/talks/twittersystems/
======
halayli
This is more about Scala than systems programming.

~~~
rudasn
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

~~~
alexdias
Yes, it would work. "==" is a method like any other, and you're overriding it.

You should download the Scala IDE and play with a feature called the
"Worksheet".

See here: [https://github.com/scala-ide/scala-worksheet/wiki/Getting-
St...](https://github.com/scala-ide/scala-worksheet/wiki/Getting-Started)

~~~
rudasn
Cool thanks.

Isn't this ability a bit dangerous or worrisome? It means that for every Scala
package you use you need to review the code. It does make a good prank though
:)

~~~
weego
There is a library called Dispatch that has/had this problem entirely, the
author decided to use symbols instead of natural language method names and
left it fairly undocumented, so you had to spend time reading the source to
have any idea what was going on. To the point where a kindly soul decided to
write a periodic table (<http://www.flotsam.nl/dispatch-periodic-table.html>)
to help people with its use.

I wouldn't say it was particularly dangerous, but it is a massive pain to deal
with (it also means you can google for any help with a particular method).

------
duncans
Off-topic somewhat, but I appreciate the way the slides used
`location.replace('#'+n)` so my browser history wasn't littered with slide
navigations, hence the back button brought me back here (but slides are still
bookmarkable).

------
shin_lao
Scala is interesting but as others have pointed out, I think it gives a
disservice to the presentation to call it "Systems programming at Twitter" .

To me it shows two things:

* The author doesn't know what system programming is;

* Future, promises and generally speaking asynchronous operations are I/O management 101. It doesn't paint your company in a good light to exhibit these techniques as "how we do things".

Am I too pedantic?

~~~
mariusaeriksen
Hello from the author. Indeed the vernacular has changed, and “systems
programming” refers also to the distributed systems server software.

 _Composable_ futures and promises are still fairly new in use; I would wager
our systems are some of the largest using the techniques described therein.

While this talk focused on composable IO and services, there is much more to
it. Finagle (<https://github.com/twitter/finagle>) is where the rubber meets
the road. Its interfaces are described in these terms and it makes great use
of their power.

Also, as with any talk, it is difficult to convey the message using only the
slides.

~~~
shin_lao
Thanks for taking the time to write an answer.

Generally speaking futures and promises are new labeled "as is" but
asynchronous I/O really isn't and is actually a requirement if you want to
write something efficient.

I understand that slides convey a small percentage of information and I really
hope I didn't come up as snarky.

That being said, when you say _"I would wager our systems are some of the
largest using the techniques described therein"_ I think you should visit a
stock exchange. ;)

As for us, we've stopped using futures and promises for asynchronous
operations as we've found faster way to manage operations (our system is
written in C++11).

The best is to design your system in a way that you never have to
wait/synchronize at all.

~~~
mariusaeriksen
> As for us, we've stopped using futures and promises for asynchronous >
> operations as we've found faster way to manage operations (our system > is
> written in C++11). The best is to design your system in a way that > you
> never have to wait/synchronize at all.

I think you've perhaps misunderstood: the futures described in the
presentation are not at all like, say for instance std::future or
java.util.concurrent.Future - that's why I called them "composable futures".
`flatMap` is the key to great power.

Our systems, using this variant of a "future", do not wait or synchronize at
all, as you describe.

Another thing that I highlight _a lot_ in the presentation itself, but does
not come through in the slides is that this doesn't really have anything to do
with asynchronous IO at all, it has to do with composing your operations from
smaller operations. It's possible to use asynchronous IO (as we do—with
asynchronous operations throughout, and with no waiting), but that is not
necessary. The important bit is this: composing larger operations from smaller
ones leads to inherently modular code; code that composes well within the
context of larger systems. That's the important bit. That it is also easy to
implement a performant execution system for this is gravy.

~~~
shin_lao
I wholeheartedly agree about your second point - I blogged about it recently -
[http://blogea.bureau14.fr/index.php/2012/11/function-
composi...](http://blogea.bureau14.fr/index.php/2012/11/function-composition-
in-c11/)

------
codewright
Do the dispatches from engineering-land from Twitter strike anyone else as:

"Please learn Scala, we can't hire people that already know Scala.

Please?

Learn Scala."

The last presentation of any substance I saw re: Twitter Engineering was their
cute BitTorrent based deployment stack.

~~~
DanielRibeiro
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-
googl...](http://highscalability.com/blog/2010/4/27/paper-dapper-googles-
large-scale-distributed-systems-tracing.html)

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

~~~
zxypoo
Twitter open sourced Zipkin, their distributed tracing system based on the
Dapper paper: <http://twitter.github.com/zipkin/>

------
smegel
Yawn. Headline should have been "Scala tutorial".

------
abhijat
It appears to have an error on slide 23, where the flatMap should return 1, -1
at the beginning rather than 1, -2?

I don't know enough Scala to say with certainty but that seems to be an error:

Seq(1,2,3,4) flatMap { x => Seq(x, -x) } == Seq(1,-2,2,-2,3,-3,4,-4)

~~~
domlebo70
Yeah you're right.

------
fkaminski
I agree this is more about scala than system programming..

I was very happy back then when scala shows up.. but with time i think
computer languages should just get out of your way.. be simple as possible..

nowadays im more a Dennis Ritchie/Ken Thompson fan.. they had make simple
tools with C and Unix, that just worked..

This is also the Go language school of thought.. Languages must get out of our
way, get things done in the simplest way possible..

Functional language people , are more passionate about proving some
theoretical points like using immutability all way down.. even if this will
blow out your memory resources, or make your code longer..

i think language designers need to be more pratical, and i like when the
simplicity way of thought like the one seen in Go comes around the table, to
make discussion a little bit more interesting..

We nee more simplicity, work less, so we can be more with our children or
family.. and spending less time on our computer.

------
mattdw
When all you have is a flatMap, everything looks like a nested list ;).

(The author seems to be shoe-horning a lot of different concepts into flatMap
via traits. I count several different Monads in there.)

~~~
sanderjd
It is possible that you're making the same mistake you accuse the author of
making. "You have a hammer and are seeing everything as a nail, but I have a
screwdriver and all those things are actually screws."

------
jebblue
I can't get my head around stuff like a function is a value (I can what it's
doing, it's the syntax that boggles me) :

val f: Int => Int = { x => x*2 } f(123) == 246

~~~
mrcrassic
If you do more functional programming, it will become second-hand to you.

------
ChrisArchitect
err <http://news.ycombinator.com/item?id=4732958>

------
pionar
OT, but it took me way too long to figure out how to make the slides advance.
I'm an idiot :)

------
duaneb
Whatever presentation software is used appears to be nigh unusable on the
iPad.

~~~
wtracy
I don't know if this helps you, but the presentation is quite readable on a
browser that has JavaScript completely disabled.

~~~
duaneb
Not being a web developer, I really have no idea what the problem is. But it
would be fixed with links that connect the slides.

------
tzury
Well,

    
    
        aapl < goog == true
    

Should be false, at least by real market values.

;-)

