4 ms·

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 s

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?

frou_dh 14y ago
Bikeshedding what constitutes Systems Programming has been done to death in Go-related discussions.
pretoriusB 14y ago
>The author doesn't know what system programming is No, it's that systems programming is not what it was. The term now also applies to large scale server side systems, not just drivers and lower level work. See also how Go was presented as a "systems language" for these same uses. >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". I/O 101? You'd be surprised. Take a look around the industry, and even HN posts, and you'll find out this is far far from the truth.
- jeremiep 14y ago
  I couldn't agree more, if this is I/O 101 then most network programmers I've met weren't even aware this course existed! Heck, back when I was in CS I had one teacher who was saying "use Java applets for web forms, its more secure since you can't right click to view the source to see the field names in order to forge a request". Somehow most of his students ended up on government contracts..
mariusaeriksen 14y ago
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 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 14y ago
  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 14y ago
    > 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 14y ago
      I wholeheartedly agree about your second point - I blogged about it recently - http://blogea.bureau14.fr/index.php/2012/11/function-composition-in-c11/ http://blogea.bureau14.fr/index.php/2012/11/function-composi...

frou_dh 14y ago

Bikeshedding what constitutes Systems Programming has been done to death in Go-related discussions.

pretoriusB 14y ago

>The author doesn't know what system programming is No, it's that systems programming is not what it was. The term now also applies to large scale server side systems, not just drivers and lower level work. See also how Go was presented as a "systems language" for these same uses. >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". I/O 101? You'd be surprised. Take a look around the industry, and even HN posts, and you'll find out this is far far from the truth.

jeremiep 14y ago
I couldn't agree more, if this is I/O 101 then most network programmers I've met weren't even aware this course existed! Heck, back when I was in CS I had one teacher who was saying "use Java applets for web forms, its more secure since you can't right click to view the source to see the field names in order to forge a request". Somehow most of his students ended up on government contracts..

mariusaeriksen 14y ago

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 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 14y ago
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 14y ago
  > 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 14y ago
    I wholeheartedly agree about your second point - I blogged about it recently - http://blogea.bureau14.fr/index.php/2012/11/function-composition-in-c11/ http://blogea.bureau14.fr/index.php/2012/11/function-composi...