- 02:49 Brian Goetz: When I am working on a programming problem and not making progress the root cause usually is that I am not thinking clearly about the data flows. Once you get the data flows right then the code pretty much writes itself.
- 05:23 Joe Duffy: Operating systems of the future should provide type, memory and concurrency-safety (no data races). We should use languages that solve the problems by construction.
- 07:37 Focus on writing simple code!
- 28:29 Richard Feldman: Immutability rules out a lot of concurrency related problems. Will programmers adapt and use different programming paradigms where these problems (concurrency, data-safety, etc.) cannot happen anymore?
- 39:15 Brian Goetz: There is the programming language you program in. And then there is the runtime which really is the important part. That's where all your deployment, debuggability, monitorability, serviceability comes from. Developers (who are focused on code) often think the surface language is the important part. But in a lot of ways the runtimes matter way more than programming languages do.
- 46:53 Sylvan Clebsch: The Actor model programming paradigm makes OOP vs. FP discussions unnecessary.
- 49:22 Sylvan Clebsch: The programming language is a UI to the runtime.
My Comments
I think that software architects and engineers focus way too much on code instead of data flows. Understanding the data flows in a system and arranging them efficiently usually points you to the best and simplest architectures.Brian Goetz definition of programming language runtimes and Sylvan Clebsch comment that we should regard programming languages just as user interfaces to their runtime systems is so true. I would even say that most languages I like, I do that mostly because of their runtime system and not so much for the language itself.
- The Erlang runtime system (programming language) provides me a really nice Actor model paradigm I love to program in, and perfect abstractions how to build reliable, fault-tolerant distributed systems.
- The Android framework to me is a superb runtime on the Java VM that provides much more fun and simplicity for writing correct programs than the standard Java runtime system abstractions. Their Actor model implementation (Handler/Looper/MessageQueue) is far more easy and fun to work with than Java's pure Thread and Executor stuff. Having callbacks run in the application thread (actor) without introducing concurrency issues is just great and must be the norm!
- The main reason for building the Mindroid frameworks/runtimes for Java, C++ and embedded C++ is due to the fact that the standard Java and C++ runtimes do not provide neat, slim and consistent application models (Erlang guys would say behaviors) to work with. Mindroid provides a consistent way to develop Java, C++ and embedded C++ applications using the Actor model design pattern. It bridges language boundaries and helps in building correct, fault-tolerant (distributed) systems.
- Both operating systems and/or programming systems (languages) can provide runtimes that are fun to work with. Besides Erlang, I really loved to work with the QNX operating system since it provides nice, yet easy to understand, abstractions for building modular (distributed) systems using inter-process communication (CSP-style IPC) and resource managers (kind of an Actor model).
- Runtimes standardize ways of doing things and behaviors so that not everybody needs to reinvent the wheel. I think nobody ever tried to implement her/his own Actor model implementation or distribution transparency mechanism on top of Erlang or Elixir.
- Operating systems and language runtimes should align on basic building blocks like fast message passing as well as inexpensive processes (for isolation) and fast process switching. Furthermore, both should have first-class support for distributed systems including distribution transparency, supervision trees and (topic-based) publish/subscribe messaging.
