5 ms·

Lambdas (in the cloud): see CGI scripts and inetd. Containers: see BSD jails, Solaris zones. WASM: see JVM and Smalltalk VM. Async / futures / actors: see Er

by nine_k 2y ago

Lambdas (in the cloud): see CGI scripts and inetd. Containers: see BSD jails, Solaris zones. WASM: see JVM and Smalltalk VM. Async / futures / actors: see Erlang, Lua, Oz. The cool type system of Typescript: see OCaml and Haskell. Numpy: see APL. Through the list above, there's usually a 20 to 40-year gap between the first availability and the turning into "new hotness".

nequo 2y ago
Generally agreed. About WASM, it is not the first sandboxed bytecode interpreter but the first that runs in a browser and that has usable toolchains to compile not “browsers first” languages into it. I’d argue that that’s where the novelty is.
- NomDePlum 2y ago
  Did Java applets arguably not do this 20+ years ago?
  - jimbob45 2y ago
    I thought those were interpreted by the JVM, which was subject to security issues. WASM faces no such security issues, no?
    - 3np 2y ago
      Oh, sweet summer child
    - lmz 2y ago
      The JVM implemented properly should not have security issues. The class library however... (i.e. it's a lot easier to sandbox things if you start without any classes that interact outside the sandbox).
    - Earw0rm 2y ago
      At least in so far as the higher level (DOM, browser runtime) and lower level (memory access, to the extent that it's mediated by the WASM VM) have no security issues... The VM itself is pretty tight, but abstractions have a nasty habit of being leaky.
    - pjmlp 2y ago
      WASM also has potentials for security exploits, but those selling it are quite silent on those. Everything Old is New Again: Binary Security of WebAssembly https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat... Just one of the many articles that are slowly surfacing, now that WebAssembly is interesting enough as possible attack vector. While there is a sandbox, you can attack WASM modules the same way as a traditional process via OS IPC, by misusing the public API in a way that corrupts internal memory state (linear memory accesses aren't bound checked), thus fooling future calls to follow execution paths that they shouldn't. With enough luck, one gets an execution path that e.g. validates an invalid credential as good.
    - swiftcoder 2y ago
      The JVM is fairly good at sandboxing, as these things go. Turns out sandboxing arbitrary software is an extremely hard problem (as the WASM folks are starting to encounter in the wild)
  - nequo 2y ago
    Maybe you know this better than me. Were non-JVM native languages available 20 years ago for Java applets? My conception of it is that they were pretty much Java only (with Clojure and Scala also available in the later years before they got deprecated?). Is this conception wrong?
    - nine_k 2y ago
      Yes, you could write applets in other languages. The choice was rather narrow, but you could use [Python], [Scala], or [JRuby]. [Python]: https://www.jython.org/jython-old-sites/archive/21/applets/index.html https://www.jython.org/jython-old-sites/archive/21/applets/i... [Scala]: https://cs.trinity.edu/~mlewis/ScalaApplet/scalaWebApplet/WebAppletsInScala/WebAppletsInScala.html https://cs.trinity.edu/~mlewis/ScalaApplet/scalaWebApplet/We... [JRuby]: https://www.jruby.org/getting-started https://www.jruby.org/getting-started — offers to run as an applet in the first few lines.
      - eecc 2y ago
        also JavaScript. See https://en.wikipedia.org/wiki/Nashorn_(JavaScript_engine) https://en.wikipedia.org/wiki/Nashorn_(JavaScript_engine)
    - fulafel 2y ago
      Some other >20 year old JVM languages not yet mentioned in sibling commins: Kawa (a Scheme) and Groovy (a JVM native dynamic language)
  - deleted 2y ago
    [deleted]
  - antupis 2y ago
    Well yeah but the problem was that you still needed that runtime, WASM should solve this.
  - Cthulhu_ 2y ago
    Java, Flash, Silverlight, ActiveX? There were loads of technologies to run different languages in a browser, but they were all proprietary to a point; none of them were a web standard, they all needed separate installation or a specific browser, and they were all basically black boxes in the browser. Whereas (from what I understand) wasm is a built-in browser standard. There was (is?) also asm.js, which IIRC was a subset of JS that removed any dynamicness so it would be a lot faster than vanilla JS. But again, no broadly carried / w3c standard.
throw1230 2y ago
There's always a push and pull between old and new tech and I agree some of the hot new tech is regurgitated old tech, but most of your examples aren't really comparable.
- nine_k 2y ago
  I would say that my examples are rhymes, different developments of the sane theme. They are not literal repetitions, of course; comparable, not identical.
sjrd 2y ago
It's not every day that we see Oz mentioned here! I was very involved in writing the Mozart/Oz 2.0 VM. I also wrote a "toy" (read: for school) dialect of Scala compiling to Oz and therefore turning every local variable or field into what Scala calls a Future, for free. Performance was abysmal, though! But in terms of language idioms, it was quite nice. --- Unrelated: about Wasm, none of what it does is new, obviously. What's interesting about it is that a) browser vendors agree to do it together, and b) the design grows to accommodate many source languages. This used not to be the case but the eventual arrival of WasmGC significantly redistributed the cards of the game. Relevant background here: I'm the author of the Scala to JavaScript compiler, and now co-author of the Scala to Wasm compiler.
away271828 2y ago
I'm a bit hesitant to describe $NEW_CONCEPT/TECH as just $OLD_CONCEPT/TECH. Echoes of older things in a new context can really amount to something different. Yes, VMware didn't create the idea of virtualization and Docker et al didn't create containerization but the results were pretty novel.
- nine_k 2y ago
  I'd rather say that good ideas keep on returning, no matter whether they are remembered or getting reinvented. It's not that those who reapplied the old concept in new circumstances are not innovators; they are! Much like the guy who rearranged the well known thread, needle, and needle eye and invented the sewing machine, completely transforming the whole industry. But seeing the old idea resurfacing again (and again) in a new form gives you that feeling of a wheel being reinvented, in a newer and usually better form, but still very recognizable.
  - xyzzy123 2y ago
    The plumbing behind Docker is not particularly novel but the porcelain was imho a major advance. There were plenty of ways to do "containers" (via vservers, jails, zones etc) but the concept of image never caught on before Docker. You could sling tarballs of chroots around and at times this did happen but it was a sort of sysadmin thing to do, there was no coherent "devex".
motohagiography 2y ago
about 15 years ago the joke was, `cat /etc/services | mail apply@ycombinator` as at the time it seemed like startups were just doing file transfer, email, network file systems, etc. it wasn't far off, as unix is file based, and the internet is also file based.
- Cthulhu_ 2y ago
  And to a point they were correct; file transfer 15 years ago was closely linked to piracy and dodgy websites that scam you into pressing an ad instead of a download button. It's only thanks to e.g. dropbox / cloud file storage suppliers, wetransfer, etc that that bit has been resolved. Dunno about email though, the last real innovation in that space that I can remember with lasting impact was gmail. There were a few more tidbits like inbox (RIP), the inbox zero methodology, and Airmail (?) but none of them really took off.
davidgay 2y ago
I have to say that all your “old” ideas (they are all from the 90s AFAICT) seem new to me ;) For example, for Haskell [1990] (ok, not so much the type system bits, but…), see FP [1977] (https://en.m.wikipedia.org/wiki/FP_(programming_language) https://en.m.wikipedia.org/wiki/FP_(programming_language))
- nine_k 2y ago
  1990s happened three decades ago. 80486, Doom, Win 95, JavaScript did not exist half of that decade, Linux was a hot new thing, etc. Remember these? It's like referring to ideas from 1960s as "old" in 1994. Not ancient, but already not really recent.
  - davidgay 2y ago
    I think you missed my point that what you're describing as the "old" idea were actually the "new" idea with a corresponding "old" idea. For instance, you mention OCaml's typing, but OCaml is from 1996 and Milner's type-inference work (which was for an early version of ML) is from 1982. And ML itself is from 1973 according to https://en.wikipedia.org/wiki/ML_(programming_language) https://en.wikipedia.org/wiki/ML_(programming_language) ... [My personal experience from doing related-work searches for research papers is that there was often an at least somewhat relevant reference from the 60s...]
galdosdi 2y ago
Couple more: (1) Garbage collection in every high level language: Java, which was the first mainstream language to do it-- people were seriously using cpp for high level business logic at the time, and were suspicious of GC for its performance. But Java itself got it from LISP, which had introduced GC without it ever going mainstream decades prior (2) No SQL had already been tried as hierarchical databases in the 70s or 80s iirc. Relational model won because it was far more powerful. Then in the early 2010s, due to a sudden influx of fresh grads and boot campers etc, who often hada poor grasp on SQL, schemaless stuff became very popular... And thankfully the trend died back down as people rediscovered the same thing. Today's highly scalable databases like Spanner and Cassandra don't ostentatiously abandon relational calculus, they reimplement a similar model even if it isn't officiallu SQL (3) And then there's the entire cycle that's gone back and forth several times of client based vs server based: First there were early ENIAC type computers that werr big single units. I would consider that similar to thick client. Then as those developed we had a long era of something more similar to cloud, in that a single computer developed processes to support many partitioned users who submitted punch card batches. That developed even further into the apex at the time of cloud style computing: terminal systems like ITS, MULTIcS, and finally in the 70s, UNIX. Then the PC revolution of the 80s turned that totally on its head and we went back to very very thick client, in fact often no servers at all (having a modem was an optional accessory) We stuck with that through the 90s , the golden age of desktop software. A lot of attempts were made to go back to thinner clients but the tech wasn't there yet. Then of course came the webapp revolution started by Gmail's decision to exploit a weird little used API called XMLHttpRequest. The PC rapidly transformed over the next decade from a thick client to a thin vessel for a web browser, as best exemplified by the Chromebook, where everything happens in the cloud -- just like it did in the mainframe and terminal days 50 yeara ago... The trend could stay that way or turn around -- it's always depended in hardware performance balance changes.
- nine_k 2y ago
  To be honest, NoSQL makes sense where the stream of writes is very intense, so ACID guarantees are impossible to enforce along with relational guarantees, like referential integrity. See stuff like Cassandra. Schemaless has its place for document storage and the like, but it requires a much more careful approach, else it can devolve into insanity.
kjs3 2y ago
Cloud: IBM mainframes and Service Bureaus.

by nine_k 2y ago

nequo 2y ago

Generally agreed. About WASM, it is not the first sandboxed bytecode interpreter but the first that runs in a browser and that has usable toolchains to compile not “browsers first” languages into it. I’d argue that that’s where the novelty is.

NomDePlum 2y ago
Did Java applets arguably not do this 20+ years ago?
- jimbob45 2y ago
  I thought those were interpreted by the JVM, which was subject to security issues. WASM faces no such security issues, no?
  - 3np 2y ago
    Oh, sweet summer child
  - lmz 2y ago
    The JVM implemented properly should not have security issues. The class library however... (i.e. it's a lot easier to sandbox things if you start without any classes that interact outside the sandbox).
  - Earw0rm 2y ago
    At least in so far as the higher level (DOM, browser runtime) and lower level (memory access, to the extent that it's mediated by the WASM VM) have no security issues... The VM itself is pretty tight, but abstractions have a nasty habit of being leaky.
  - pjmlp 2y ago
    WASM also has potentials for security exploits, but those selling it are quite silent on those. Everything Old is New Again: Binary Security of WebAssembly https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat... Just one of the many articles that are slowly surfacing, now that WebAssembly is interesting enough as possible attack vector. While there is a sandbox, you can attack WASM modules the same way as a traditional process via OS IPC, by misusing the public API in a way that corrupts internal memory state (linear memory accesses aren't bound checked), thus fooling future calls to follow execution paths that they shouldn't. With enough luck, one gets an execution path that e.g. validates an invalid credential as good.
  - swiftcoder 2y ago
    The JVM is fairly good at sandboxing, as these things go. Turns out sandboxing arbitrary software is an extremely hard problem (as the WASM folks are starting to encounter in the wild)
- nequo 2y ago
  Maybe you know this better than me. Were non-JVM native languages available 20 years ago for Java applets? My conception of it is that they were pretty much Java only (with Clojure and Scala also available in the later years before they got deprecated?). Is this conception wrong?
  - nine_k 2y ago
    Yes, you could write applets in other languages. The choice was rather narrow, but you could use [Python], [Scala], or [JRuby]. [Python]: https://www.jython.org/jython-old-sites/archive/21/applets/index.html https://www.jython.org/jython-old-sites/archive/21/applets/i... [Scala]: https://cs.trinity.edu/~mlewis/ScalaApplet/scalaWebApplet/WebAppletsInScala/WebAppletsInScala.html https://cs.trinity.edu/~mlewis/ScalaApplet/scalaWebApplet/We... [JRuby]: https://www.jruby.org/getting-started https://www.jruby.org/getting-started — offers to run as an applet in the first few lines.
    - eecc 2y ago
      also JavaScript. See https://en.wikipedia.org/wiki/Nashorn_(JavaScript_engine) https://en.wikipedia.org/wiki/Nashorn_(JavaScript_engine)
  - fulafel 2y ago
    Some other >20 year old JVM languages not yet mentioned in sibling commins: Kawa (a Scheme) and Groovy (a JVM native dynamic language)
- deleted 2y ago
  [deleted]
- antupis 2y ago
  Well yeah but the problem was that you still needed that runtime, WASM should solve this.
- Cthulhu_ 2y ago
  Java, Flash, Silverlight, ActiveX? There were loads of technologies to run different languages in a browser, but they were all proprietary to a point; none of them were a web standard, they all needed separate installation or a specific browser, and they were all basically black boxes in the browser. Whereas (from what I understand) wasm is a built-in browser standard. There was (is?) also asm.js, which IIRC was a subset of JS that removed any dynamicness so it would be a lot faster than vanilla JS. But again, no broadly carried / w3c standard.

throw1230 2y ago

There's always a push and pull between old and new tech and I agree some of the hot new tech is regurgitated old tech, but most of your examples aren't really comparable.

nine_k 2y ago
I would say that my examples are rhymes, different developments of the sane theme. They are not literal repetitions, of course; comparable, not identical.

sjrd 2y ago

It's not every day that we see Oz mentioned here! I was very involved in writing the Mozart/Oz 2.0 VM. I also wrote a "toy" (read: for school) dialect of Scala compiling to Oz and therefore turning every local variable or field into what Scala calls a Future, for free. Performance was abysmal, though! But in terms of language idioms, it was quite nice. --- Unrelated: about Wasm, none of what it does is new, obviously. What's interesting about it is that a) browser vendors agree to do it together, and b) the design grows to accommodate many source languages. This used not to be the case but the eventual arrival of WasmGC significantly redistributed the cards of the game. Relevant background here: I'm the author of the Scala to JavaScript compiler, and now co-author of the Scala to Wasm compiler.

away271828 2y ago

I'm a bit hesitant to describe $NEW_CONCEPT/TECH as just $OLD_CONCEPT/TECH. Echoes of older things in a new context can really amount to something different. Yes, VMware didn't create the idea of virtualization and Docker et al didn't create containerization but the results were pretty novel.

nine_k 2y ago
I'd rather say that good ideas keep on returning, no matter whether they are remembered or getting reinvented. It's not that those who reapplied the old concept in new circumstances are not innovators; they are! Much like the guy who rearranged the well known thread, needle, and needle eye and invented the sewing machine, completely transforming the whole industry. But seeing the old idea resurfacing again (and again) in a new form gives you that feeling of a wheel being reinvented, in a newer and usually better form, but still very recognizable.
- xyzzy123 2y ago
  The plumbing behind Docker is not particularly novel but the porcelain was imho a major advance. There were plenty of ways to do "containers" (via vservers, jails, zones etc) but the concept of image never caught on before Docker. You could sling tarballs of chroots around and at times this did happen but it was a sort of sysadmin thing to do, there was no coherent "devex".

motohagiography 2y ago

about 15 years ago the joke was, `cat /etc/services | mail apply@ycombinator` as at the time it seemed like startups were just doing file transfer, email, network file systems, etc. it wasn't far off, as unix is file based, and the internet is also file based.

Cthulhu_ 2y ago
And to a point they were correct; file transfer 15 years ago was closely linked to piracy and dodgy websites that scam you into pressing an ad instead of a download button. It's only thanks to e.g. dropbox / cloud file storage suppliers, wetransfer, etc that that bit has been resolved. Dunno about email though, the last real innovation in that space that I can remember with lasting impact was gmail. There were a few more tidbits like inbox (RIP), the inbox zero methodology, and Airmail (?) but none of them really took off.

davidgay 2y ago

I have to say that all your “old” ideas (they are all from the 90s AFAICT) seem new to me ;) For example, for Haskell [1990] (ok, not so much the type system bits, but…), see FP [1977] (https://en.m.wikipedia.org/wiki/FP_(programming_language) https://en.m.wikipedia.org/wiki/FP_(programming_language))

nine_k 2y ago
1990s happened three decades ago. 80486, Doom, Win 95, JavaScript did not exist half of that decade, Linux was a hot new thing, etc. Remember these? It's like referring to ideas from 1960s as "old" in 1994. Not ancient, but already not really recent.
- davidgay 2y ago
  I think you missed my point that what you're describing as the "old" idea were actually the "new" idea with a corresponding "old" idea. For instance, you mention OCaml's typing, but OCaml is from 1996 and Milner's type-inference work (which was for an early version of ML) is from 1982. And ML itself is from 1973 according to https://en.wikipedia.org/wiki/ML_(programming_language) https://en.wikipedia.org/wiki/ML_(programming_language) ... [My personal experience from doing related-work searches for research papers is that there was often an at least somewhat relevant reference from the 60s...]

galdosdi 2y ago

Couple more: (1) Garbage collection in every high level language: Java, which was the first mainstream language to do it-- people were seriously using cpp for high level business logic at the time, and were suspicious of GC for its performance. But Java itself got it from LISP, which had introduced GC without it ever going mainstream decades prior (2) No SQL had already been tried as hierarchical databases in the 70s or 80s iirc. Relational model won because it was far more powerful. Then in the early 2010s, due to a sudden influx of fresh grads and boot campers etc, who often hada poor grasp on SQL, schemaless stuff became very popular... And thankfully the trend died back down as people rediscovered the same thing. Today's highly scalable databases like Spanner and Cassandra don't ostentatiously abandon relational calculus, they reimplement a similar model even if it isn't officiallu SQL (3) And then there's the entire cycle that's gone back and forth several times of client based vs server based: First there were early ENIAC type computers that werr big single units. I would consider that similar to thick client. Then as those developed we had a long era of something more similar to cloud, in that a single computer developed processes to support many partitioned users who submitted punch card batches. That developed even further into the apex at the time of cloud style computing: terminal systems like ITS, MULTIcS, and finally in the 70s, UNIX. Then the PC revolution of the 80s turned that totally on its head and we went back to very very thick client, in fact often no servers at all (having a modem was an optional accessory) We stuck with that through the 90s , the golden age of desktop software. A lot of attempts were made to go back to thinner clients but the tech wasn't there yet. Then of course came the webapp revolution started by Gmail's decision to exploit a weird little used API called XMLHttpRequest. The PC rapidly transformed over the next decade from a thick client to a thin vessel for a web browser, as best exemplified by the Chromebook, where everything happens in the cloud -- just like it did in the mainframe and terminal days 50 yeara ago... The trend could stay that way or turn around -- it's always depended in hardware performance balance changes.

nine_k 2y ago
To be honest, NoSQL makes sense where the stream of writes is very intense, so ACID guarantees are impossible to enforce along with relational guarantees, like referential integrity. See stuff like Cassandra. Schemaless has its place for document storage and the like, but it requires a much more careful approach, else it can devolve into insanity.

kjs3 2y ago

Cloud: IBM mainframes and Service Bureaus.