5 ms·

Some context from top of my head. In the 90s our sector started to look (again) at VMs as viable alternatives for software platforms. The most prominent exampl

Some context from top of my head. In the 90s our sector started to look (again) at VMs as viable alternatives for software platforms. The most prominent example of that is Java. But Inferno was born at the same time at the other side of the Atlantic Ocean[0], sharing the same goals: an universal platform intended for set-top boxes, appliances and the like, with the same write once, run everywhere philosophy. Inferno programs ran on top of a VM called Dis and programs were written in Limbo (designed by Rob Pike). If you use Go nowadays, you're using a descendant of Limbo, as both share a lot of syntax and concepts (and Limbo descended from Aleph, by Rob Pike too, but that's another story) Going back to 90s. This space was in a very "exploratory" state then, and any technology had to probe it's superiority to gain adoption. For example, Inferno creators implemented Java on Dis[1] simply to demonstrate how fast was Dis vs the JVM. I don't know exactly why things were the way the went, but I suppose Sun had more deep pockets to push it's technology and Inferno ended as a the rarity we have today. From a pure tech standpoint, I've studied the Dis VM to write my own (incomplete) interpreter[1] and, IMHO, it's design is far less abstract than the JVM. It seems to be too low level and tied to that era processor design. That make it less future proof (but that's only my own point of view, of course) [0] https://www.vitanuova.com/inferno/ https://www.vitanuova.com/inferno/ [1] http://doc.cat-v.org/inferno/java_on_dis/ http://doc.cat-v.org/inferno/java_on_dis/ [2] https://github.com/luismedel/sixthcircle https://github.com/luismedel/sixthcircle

bheadmaster 3y ago
Nice piece of history. From what I remember reading, JVM is a stack machine, while Dis is a register machine, right? Is there any other significant difference that would make Dis less "future proof"?
- jimsimmons 3y ago
  Why is stack more future proof
  - rollcat 3y ago
    It isn't, unless you consider SPARC the future. SPARC had an interesting register architecture, where making a function call would renumber registers 9-16 to 1-8, and give the function a fresh set of 9-16; IIRC most SPARC CPUs had 128 or so registers total, with this "sliding window" that went up and down as you called and returned, which essentially gave you something like a stack. The rest of the world's CPUs have normal registers, which is one aspect of what makes register-based VM bytecode easier to JIT to the target architecture, which was one of Dis' original design goals (with an interpreter being a fallback). It also happens that we know a lot more about actually optimising register-based instructions (rather than stack-based), so even if you had to fall back on an interpreter, the bytecode could've gone thru an actual proper optimisation pass.
    - _a_a_a_ 3y ago
      Not an expert but I'd argue a stack is somewhat more future proof in the sense that it's less tied to a particular number of physical registers, whereas a register machine must be. Which is exactly what makes it a bit harder to optimise for, but that's what abstractions tend to do :-) The sparc sliding register window turned out to be a very bad idea, but I guess you already know that.
      - amelius 3y ago
        > The sparc sliding register window turned out to be a very bad idea, but I guess you already know that. Yikes, that triggered flashbacks of 8086 segmented memory.
        _a_a_a_ 3y ago
        It wasn't really like that AIUI. Using a stack introduced hardware complexity while also serialising instruction processing (because you only work from the top of the stack, unlike a register set where you can access any part of it at any time) which caused the chip not to be the raging speed demon the designers thought it was going to be. I'd very much like to understood what was going through the sparc designers minds when they did that. Looking back on it with my own current understanding of CPU designs and all that, they seem to have made some incredibly basic mistakes, including designing the hardware without talking to the compiler writers (a cockup the Alpha designers very definitely didn't make). It's all very odd. Another mistake they made was apparently deciding to leave out instructions based on counting them in the code – if an instruction didn't appear very often they omitted it. Sounds reasonable but that meant they left out the multiply instruction initially, which might not have been so common in the code was actually executed quite often (e.g. in array lookups) and there were complaints about the new Sparc stations with their new superior chip, that they were slower than the 68000-based CPU that preceded it. Hardware multiply was later added.
Nokinside 3y ago
There were many: 1. Java, 2. Inferno, 3. Oberon System (Niklaus Wirth, ETH Zurich), 4. Squeak (Apple, Walt Disney Imagineering) 5. Erlang (Ericsson, Joe Armstrong) still going strong. IMHO, Technologically Java was the worst and least innovative. Platform adaption is "Worse is Better" so Java won. Oberon, Erlang and Squeak were are all amazing in their own way.
- mike_hearn 3y ago
  Inferno was a Plan9 derivative kinda research OS, not necessarily what people wanted. Squeak/Smalltalk had the issue of programs and runtime images being conflated, making version control awkward (at the time at least). Erlang is a functional language. All the above had relatively small and poorly documented libraries. Java combined an imperative C-like and relatively simple language, with an evolvable bytecode-oriented VM, garbage collector, large and well documented libraries + lots of tutorials, and really intense VM engineering. Easy to forget but Cliff Click and colleagues were the first to show that a JIT compiler could produce code competitive with gcc, Sun also bought/implemented stuff like deoptimization which is still relatively advanced, and then gave that tech away for free. From the end user POV all these things mattered a lot.
  - einpoklum 3y ago
    Java is really not simple, and not at all C-like, except in some of the syntax.
    - pjmlp 3y ago
      It is, in the sense that Objective-C was the inspiration. https://cs.gmu.edu/~sean/stuff/java-objc.html https://cs.gmu.edu/~sean/stuff/java-objc.html
    - dboreham 3y ago
      Quick note for folks not familiar with language history: Java is a C-like language.
pjmlp 3y ago
> In the 90s our sector started to look (again) at VMs as viable alternatives for software platforms. Now we are back at it with WebAssembly, as if it was something new.
- speed_spread 3y ago
  WASM started making is way into browsers just as we removed the last remnants of Java Applets. Now we have too re-secure a whole new stack.
  - overthrow 3y ago
    At least WASM is first-party code written by the browser developers. I'll take that any day over a pile of third-party plugins.
  - naikrovek 3y ago
    the WASM people knew that going in and it's part of the design. it's also why WASM is so slow compared to native executables; security guarantees have a performance cost.
    - pjmlp 3y ago
      Yet several security issues still aren't taken care of, https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat... https://www.usenix.org/conference/usenixsecurity21/presentation/narayan https://www.usenix.org/conference/usenixsecurity21/presentat...
      - naikrovek 3y ago
        well it's not perfect, no. my point stands though. WASM is not ActiveX where the whole applet has admin permission on the computer.
        pjmlp 3y ago
no_wizard 3y ago
God damn it I missed the holy grail era of the computing industry. It’s all so drab compared to the 90s to the early 00s. So much more experimental and willingness to try very new things
- abraxas 3y ago
  I started my career in the early nineties. It's different now. Not sure if worse or better. Different. What I enjoyed about the 90's is that there was still plenty of meaningful work implementing published algorithms. I remember for example, coding Delaunay triangulation, our own Quartenions etc in C++. These days you just download and learn an API to do it. What this means is now you can build comparable stuff much quicker. It's all been implemented and you're mostly gluing libraries. Gluing stuff is a lot less fun than doing it from scratch and you learn much less but it's the only way to stay competitive. If you want to build something rapidly to show off though, today it's much easier. Web development seems to suck more with every year passing. I wasn't all that into it in the 90's as it was very nascent and primarily for text and images due to bandwidth limitations. But VRML was mighty impressive if you used it on a LAN. Web devs seem to reinvent wheels more than other types of devs. Everything is hailed as a breakthrough in productivity that subsequently fails to materialize. They impress each other with how concise the framework du-jour makes the code, forgetting that troubleshooting ease is much more important. Troublueshooting stuff was much easier in the 90's even with the simple tools. Not many systems were distributed. It was considered craziness to build distributed software unless you really needed it and had a massive budget. Everyone builds distributed systems now, whether they need it or not. AI/ML is amazing today. None of this was possible in the 90's we had nothing approaching the crunching power required to produce decent results. So a lot of ML work was deemed a failure even though it's being exonerated now. I think with the resurgence of ML the software engineering field is exciting again. Things were rather boring for the last two decades when hipsters kept reinventing mundane stuff only to go back to tried tested and true (vide resurgence of SSR or RDBMS). Overall, I think the 90's were fun. More fun than what followed. ML/AI might make things fun again.
  - naikrovek 3y ago
    > Web devs seem to reinvent wheels more than other types of devs. Everything is hailed as a breakthrough in productivity that fails to materialize. They impress each other with how concise the framework du-jour makes the code, forgetting that troubleshooting ease is much more important. I really wish more people could see this as you (and I) do. Web development is really its own horribly sheltered community. they are driven to deliver at faster and faster paces and they can't do anything properly if they even wanted to.

bheadmaster 3y ago

Nice piece of history. From what I remember reading, JVM is a stack machine, while Dis is a register machine, right? Is there any other significant difference that would make Dis less "future proof"?

jimsimmons 3y ago
Why is stack more future proof
- rollcat 3y ago
  It isn't, unless you consider SPARC the future. SPARC had an interesting register architecture, where making a function call would renumber registers 9-16 to 1-8, and give the function a fresh set of 9-16; IIRC most SPARC CPUs had 128 or so registers total, with this "sliding window" that went up and down as you called and returned, which essentially gave you something like a stack. The rest of the world's CPUs have normal registers, which is one aspect of what makes register-based VM bytecode easier to JIT to the target architecture, which was one of Dis' original design goals (with an interpreter being a fallback). It also happens that we know a lot more about actually optimising register-based instructions (rather than stack-based), so even if you had to fall back on an interpreter, the bytecode could've gone thru an actual proper optimisation pass.
  - _a_a_a_ 3y ago
    Not an expert but I'd argue a stack is somewhat more future proof in the sense that it's less tied to a particular number of physical registers, whereas a register machine must be. Which is exactly what makes it a bit harder to optimise for, but that's what abstractions tend to do :-) The sparc sliding register window turned out to be a very bad idea, but I guess you already know that.
    - amelius 3y ago
      > The sparc sliding register window turned out to be a very bad idea, but I guess you already know that. Yikes, that triggered flashbacks of 8086 segmented memory.
      - _a_a_a_ 3y ago
        It wasn't really like that AIUI. Using a stack introduced hardware complexity while also serialising instruction processing (because you only work from the top of the stack, unlike a register set where you can access any part of it at any time) which caused the chip not to be the raging speed demon the designers thought it was going to be. I'd very much like to understood what was going through the sparc designers minds when they did that. Looking back on it with my own current understanding of CPU designs and all that, they seem to have made some incredibly basic mistakes, including designing the hardware without talking to the compiler writers (a cockup the Alpha designers very definitely didn't make). It's all very odd. Another mistake they made was apparently deciding to leave out instructions based on counting them in the code – if an instruction didn't appear very often they omitted it. Sounds reasonable but that meant they left out the multiply instruction initially, which might not have been so common in the code was actually executed quite often (e.g. in array lookups) and there were complaints about the new Sparc stations with their new superior chip, that they were slower than the 68000-based CPU that preceded it. Hardware multiply was later added.

Nokinside 3y ago

There were many: 1. Java, 2. Inferno, 3. Oberon System (Niklaus Wirth, ETH Zurich), 4. Squeak (Apple, Walt Disney Imagineering) 5. Erlang (Ericsson, Joe Armstrong) still going strong. IMHO, Technologically Java was the worst and least innovative. Platform adaption is "Worse is Better" so Java won. Oberon, Erlang and Squeak were are all amazing in their own way.

mike_hearn 3y ago
Inferno was a Plan9 derivative kinda research OS, not necessarily what people wanted. Squeak/Smalltalk had the issue of programs and runtime images being conflated, making version control awkward (at the time at least). Erlang is a functional language. All the above had relatively small and poorly documented libraries. Java combined an imperative C-like and relatively simple language, with an evolvable bytecode-oriented VM, garbage collector, large and well documented libraries + lots of tutorials, and really intense VM engineering. Easy to forget but Cliff Click and colleagues were the first to show that a JIT compiler could produce code competitive with gcc, Sun also bought/implemented stuff like deoptimization which is still relatively advanced, and then gave that tech away for free. From the end user POV all these things mattered a lot.
- einpoklum 3y ago
  Java is really not simple, and not at all C-like, except in some of the syntax.
  - pjmlp 3y ago
    It is, in the sense that Objective-C was the inspiration. https://cs.gmu.edu/~sean/stuff/java-objc.html https://cs.gmu.edu/~sean/stuff/java-objc.html
  - dboreham 3y ago
    Quick note for folks not familiar with language history: Java is a C-like language.

pjmlp 3y ago

> In the 90s our sector started to look (again) at VMs as viable alternatives for software platforms. Now we are back at it with WebAssembly, as if it was something new.

speed_spread 3y ago
WASM started making is way into browsers just as we removed the last remnants of Java Applets. Now we have too re-secure a whole new stack.
- overthrow 3y ago
  At least WASM is first-party code written by the browser developers. I'll take that any day over a pile of third-party plugins.
- naikrovek 3y ago
  the WASM people knew that going in and it's part of the design. it's also why WASM is so slow compared to native executables; security guarantees have a performance cost.
  - pjmlp 3y ago
    Yet several security issues still aren't taken care of, https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat... https://www.usenix.org/conference/usenixsecurity21/presentation/narayan https://www.usenix.org/conference/usenixsecurity21/presentat...
    - naikrovek 3y ago
      well it's not perfect, no. my point stands though. WASM is not ActiveX where the whole applet has admin permission on the computer.
      - pjmlp 3y ago

no_wizard 3y ago

God damn it I missed the holy grail era of the computing industry. It’s all so drab compared to the 90s to the early 00s. So much more experimental and willingness to try very new things

abraxas 3y ago
I started my career in the early nineties. It's different now. Not sure if worse or better. Different. What I enjoyed about the 90's is that there was still plenty of meaningful work implementing published algorithms. I remember for example, coding Delaunay triangulation, our own Quartenions etc in C++. These days you just download and learn an API to do it. What this means is now you can build comparable stuff much quicker. It's all been implemented and you're mostly gluing libraries. Gluing stuff is a lot less fun than doing it from scratch and you learn much less but it's the only way to stay competitive. If you want to build something rapidly to show off though, today it's much easier. Web development seems to suck more with every year passing. I wasn't all that into it in the 90's as it was very nascent and primarily for text and images due to bandwidth limitations. But VRML was mighty impressive if you used it on a LAN. Web devs seem to reinvent wheels more than other types of devs. Everything is hailed as a breakthrough in productivity that subsequently fails to materialize. They impress each other with how concise the framework du-jour makes the code, forgetting that troubleshooting ease is much more important. Troublueshooting stuff was much easier in the 90's even with the simple tools. Not many systems were distributed. It was considered craziness to build distributed software unless you really needed it and had a massive budget. Everyone builds distributed systems now, whether they need it or not. AI/ML is amazing today. None of this was possible in the 90's we had nothing approaching the crunching power required to produce decent results. So a lot of ML work was deemed a failure even though it's being exonerated now. I think with the resurgence of ML the software engineering field is exciting again. Things were rather boring for the last two decades when hipsters kept reinventing mundane stuff only to go back to tried tested and true (vide resurgence of SSR or RDBMS). Overall, I think the 90's were fun. More fun than what followed. ML/AI might make things fun again.
- naikrovek 3y ago
  > Web devs seem to reinvent wheels more than other types of devs. Everything is hailed as a breakthrough in productivity that fails to materialize. They impress each other with how concise the framework du-jour makes the code, forgetting that troubleshooting ease is much more important. I really wish more people could see this as you (and I) do. Web development is really its own horribly sheltered community. they are driven to deliver at faster and faster paces and they can't do anything properly if they even wanted to.