research community that writes papers rather than software.
Systems Software Research is Irrelevant (2000) [pdf]
41–50 of 73 posts
Re: Systems Software Research is Irrelevant (2000) [pdf]
#42Since Rob Pike wrote this note in 2000, there have been many commercially important advances in systems software:
- iOS and Android: Power-efficient mobile systems, wakelocks, etc.
- Docker, Borg and Kubernetes: Container isolation, cluster orchestrators.
- Modern browser environments, with high degrees of isolation.
- Fast JavaScript runtimes and specialized JITs.
- WASM.
- Ruby and metaprogramming, which rose to considerable commercial success and then petered out. But by the standards of 2000, there's some neat language design there.
- Rust, which successfully applied a lot of lesser-appreciated academic ideas including affine types.
- Type systems retrofitted to many dynamic languages, including Typescript. Typescript is really rather remarkable, even though the types are "unsound", in the technical sense.
Some of these trends were already underway in 2000, when Rob Pike was writing. Admittedly, much of the most important implementation work happened in big tech companies, or occasionally startups. Not in academia. But that's largely a question of scale. Even as early as 1990, it was hard for a professor and a few graduate students to directly change the industry. But plenty of the items on the list above do have roots in academic research.
And Rob Pike did get to write Go. He deliberately ignored quite a bit of interesting research to focus on a specific aesthetic vision, which is fine. And a lot of good systems work has been done in Go.
Re: Systems Software Research is Irrelevant (2000) [pdf]
#43I have been working as a scientist in academic and industrial systems research for most of my life now and I have a different view on this. There are plenty of ideas that float around in academia for years or even decades before they get adopted by the industry. Examples have been mentioned here. People declaring some research area dead are usually proven wrong by time (as was Pike), because nobody can foresee which results will be relevant in the future. I tend to think of it as sort of scientific entrepreneurship, you need 100 startups to get one unicorn.
The point is: (academic) scientists have no interest in productization, they are merely interested into the next hot topic and the next paper, because that's their job. Productization is for product managers and engineers. Occasionally the lines are blurred, but I consider this separation of concerns a benefit, not a problem.
Re: Systems Software Research is Irrelevant (2000) [pdf]
#44Since Rob Pike wrote this note in 2000, there have been many commercially important advances in systems software: - iOS and Android: Power-efficient mobile systems, wakelocks, etc. - Docker, Borg and Kubernetes: Container isolation, cluster orchestrators. - Modern browser environments, with high degrees of isolation. - Fast JavaScript runtimes and specialized JITs. - WASM. - Ruby and metaprogramming, which rose to co…
[deleted]
Re: Systems Software Research is Irrelevant (2000) [pdf]
#45I think that i understand the argument, but things changed with the advent of microservices. Suddenly everything turned into a distributed system, and it is hard to cope without some understanding of the subject matter. This lecture series by Martin Kleppman has helped me quite a bit here: https://www.youtube.com/watch?v=UEAMfLPZZhE&list=PLeKd45zvjc... Also see his book 'Designing Data-Intensive Applications', which…
> but things changed with the advent of microservices. Microservices is just a marketing buzzword invented by container orchestration start-ups. Partitioning of large applications across multiple inter-connected processes has been around for decades. Your computer is packed with microservices. On Linux, type `watch date` and enjoy two microservices running and interacting. On Windows, observe a dozen of svchost.exe p…
I have the impression that the microservice architecture lowers the... 'activation energy', if you will, of building components that operate in a different paradigm. It's intensely pursuing the idea that a subservice is only its interfaces. And behind each of those curtains, it would be practical to construct something really weird.
Of course, it's cheaper and intellectually less stressing to just pop up a container, so that's what everyone does... so far. I mean, you need a TCP/IP stack somewhere.
Perhaps a microservice component embodied entirely on a GPU is an easily accessible example, or on one of those fancy ML-specific processors in the bowels of Google..
Re: Systems Software Research is Irrelevant (2000) [pdf]
#46Since Rob Pike wrote this note in 2000, there have been many commercially important advances in systems software: - iOS and Android: Power-efficient mobile systems, wakelocks, etc. - Docker, Borg and Kubernetes: Container isolation, cluster orchestrators. - Modern browser environments, with high degrees of isolation. - Fast JavaScript runtimes and specialized JITs. - WASM. - Ruby and metaprogramming, which rose to co…
> Admittedly, much of the most important implementation work happened in big tech companies, or occasionally startups. Not in academia
> - Rust, which successfully applied a lot of lesser-appreciated academic ideas including affine types.
There's some scepticism going round about a model of technological innovation where academics invent an idea and engineers implement it. While I accept that affine types were known to academics, I recall a precursor to them existed in the form of C++ unique pointers. I'm wondering whether the Rust creators reinvented affine types independently, instead of learning of them from the academic literature.
Also, maybe a better question is how beneficial the literature on affine types was to the Rust creators.
Re: Systems Software Research is Irrelevant (2000) [pdf]
#47Since Rob Pike wrote this note in 2000, there have been many commercially important advances in systems software: - iOS and Android: Power-efficient mobile systems, wakelocks, etc. - Docker, Borg and Kubernetes: Container isolation, cluster orchestrators. - Modern browser environments, with high degrees of isolation. - Fast JavaScript runtimes and specialized JITs. - WASM. - Ruby and metaprogramming, which rose to co…
> - iOS and Android: Power-efficient mobile systems, wakelocks, etc.
- Docker, Borg and Kubernetes: Container isolation, cluster orchestrators.
- Modern browser environments, with high degrees of isolation.
- Fast JavaScript runtimes and specialized JITs.
- WASM.
Would be interesting to know what Rob Pike thinks of all these.
Re: Systems Software Research is Irrelevant (2000) [pdf]
#48Since Rob Pike wrote this note in 2000, there have been many commercially important advances in systems software: - iOS and Android: Power-efficient mobile systems, wakelocks, etc. - Docker, Borg and Kubernetes: Container isolation, cluster orchestrators. - Modern browser environments, with high degrees of isolation. - Fast JavaScript runtimes and specialized JITs. - WASM. - Ruby and metaprogramming, which rose to co…
> Admittedly, much of the most important implementation work happened in big tech companies, or occasionally startups. Not in academia > - Rust, which successfully applied a lot of lesser-appreciated academic ideas including affine types. There's some scepticism going round about a model of technological innovation where academics invent an idea and engineers implement it. While I accept that affine types were known…
> There's some scepticism going round about a model of technological innovation where academics invent an idea and engineers implement it. While I accept that affine types were known to academics, I recall a precursor to them existed in the form of C++ unique pointers.
There feels like an implicit value judgment here, that the work of "academics" isn't needed because "engineers" figured it out themselves.
> I'm wondering whether the Rust creators reinvented affine types independently, instead of learning of them from the academic literature.
Why would this ever be a good thing? Is it "cool" somehow to be proud of not taking advantage of the hard-won knowledge of other people who actively hoped their work would get used?
Re: Systems Software Research is Irrelevant (2000) [pdf]
#49Earlier quoted context omitted.
Notably just about zero of what you've mentioned is apparent or directly empowering to users. They have better services at their disposal as a result of these systems developments, but almost no users have more personal.xontrol, are better aware & more capable of relliantly doing computing than they had been. In my view we've only made users dependent & less capable, we've given up all ideas of systems to the cult of…
Systems research is about technology not about empowering so and so.
as counter example to your premise, icd cite projects like Node-RED or Yahoo Pipes. These are little micro-os like systems, environmemts for cobbling together computing. They're higher level than what we might often think of, but they are easily im domain to me at least. And they're definitely about empowering!
It's a fault that more systems research isnt about finding more userhfaving abstractions. Naked Objects environments. Oberon. Good abstractions & systems dont just have to be for developers.
Re: Systems Software Research is Irrelevant (2000) [pdf]
#50Since Rob Pike wrote this note in 2000, there have been many commercially important advances in systems software: - iOS and Android: Power-efficient mobile systems, wakelocks, etc. - Docker, Borg and Kubernetes: Container isolation, cluster orchestrators. - Modern browser environments, with high degrees of isolation. - Fast JavaScript runtimes and specialized JITs. - WASM. - Ruby and metaprogramming, which rose to co…
> Admittedly, much of the most important implementation work happened in big tech companies, or occasionally startups. Not in academia > - Rust, which successfully applied a lot of lesser-appreciated academic ideas including affine types. There's some scepticism going round about a model of technological innovation where academics invent an idea and engineers implement it. While I accept that affine types were known…
I was in the space around Rust in the early days: ~10 years ago.
It was 100% research based. Everyone working on the language was familiar with this literature and many of the early contributors were PL Phd people.