5 ms·

I think we're always looking for the silver bullet that shall make computer software development easy. The following technologies were all silver bullets: * A

I think we're always looking for the silver bullet that shall make computer software development easy. The following technologies were all silver bullets: * ActiveX, COM Object model, XPCOM * Unified Modeling Language (UML) * Extensible Markup Language (XML) * Computer-aided software engineering (CASE) * Java Virtual Machine * Ionic, React Native, Qt, Gtk, Flutter Something tells me that the problem is bigger than anyone can chew and the abstraction solution is sometimes more complicated than the underlying thing being abstracted. I think WASI and WASIX is an EXTREMELY important API for the future of computing. It's a chance to create a superior operating system runtime interface.

lifty 3y ago
Why does it have the chance to be superior?
- samsquire 3y ago
  Compiling native application to operating systems that Wasmer is compiled for including the browser and have the code seamlessly work in all of them, I think that's really promising. JVM forces you to write in Java or a JVM targeted language but WASM lets you compile any language that creates a WASM backend.
  - vineyardmike 3y ago
    This > JVM forces you to write in Java or a JVM targeted language And this > WASM lets you compile any language that creates a WASM backend Are basically the same thing. There’s no fundamental reason that all these languages couldn’t target JVM byte code instead of WASM. It never happened, not nearly as much as WASM backends are, but it could’ve.
    - ShroudedNight 3y ago
      It seems that NIH also manifests generationally: ? -> CORBA -> RMI -> SOAP -> REST -> GraphQL? ? -> SOA -> Microservices ? -> EDI / X12 -> XML -> JSON p-code -> ? -> JVM -> WASM
      - pjmlp 3y ago
        Before P-Code there were other ones, there were lots of bytecode based platforms. Burroughs, all Xerox PARC, Lisp Machines, OS/400, Oberon, Limbo, original Modula-2, QuickBasic, Amsterdam Compiler Toolkit, VB, ...
      - paulddraper 3y ago
        Okay, but have you used CORBA? Or EDI? It's like saying we had the Model T, but people just keep inventing new cars.
        ShroudedNight 3y ago
        I have, albeit not terribly extensively. I will readily agree that there are cogent arguments for replacement that pass the Chesterton's Fence test. But I also see quite a lot of "That's too complicated to bother understanding, I'll just do my own thing"
  - laxd 3y ago
    > Compiling native application to operating systems that Wasmer is compiled for including the browser and have the code seamlessly work in all of them. And thanks to stuff like this, contemporary browsers are now so complicated that they only run on the top handful of platforms. So how is it progress? I bet JVM runs more places than modern browsers. > VM forces you to write in Java or a JVM targeted language but WASM lets you compile any language that creates a WASM backend. WASM forces you to write in something that has a WASM backend just like JVM forces you to write in something that has a JVM backend. It's just the same all over again. And again.
the8472 3y ago
> It's a chance to create a superior operating system runtime interface. But they're not doing io_uring style syscall queues.
boricj 3y ago
> I think WASI and WASIX is an EXTREMELY important API for the future of computing. It's a chance to create a superior operating system runtime interface. Superior operating system runtime interface and POSIX don't rhyme. The fossilization of POSIX on Unix-like systems, endlessly piling stuff on top of that creaky foundation is probably the single biggest issue holding back the future of computing. WASIX is probably a pragmatic design if you want to run your existing Unix programs on top of WASM. If anything, it's for the past of computing.
- syrusakbary 3y ago
  I wonder what is the system call ABI that your current operating system uses...
  - boricj 3y ago
    What the system call ABI that my modern operating system ought to have is not one that thinks fork() as a fundamental primitive is fit for purpose on modern computers [1], for starters. Mind you, my grievances on the design and typical implementation of Unix-like operating systems go far beyond fork(), but it's as good an entry point as any for this discussion. I encourage you to read the design documents for the Fuchsia operating system, especially those for the Zircon kernel [2] for a fresh, legacy-free take on a system call interface. [1] https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf https://www.microsoft.com/en-us/research/uploads/prod/2019/0... [2] https://fuchsia.dev/fuchsia-src/concepts/kernel https://fuchsia.dev/fuchsia-src/concepts/kernel
    - tokera 3y ago
      i coded the WASIX fork syscall, so I understand all this (f.y.i. I much prefer rust to C as its got a much better designed threading system). what you must realize is that one does not have to use a syscall if they don't like it in (e.g. just use rust to code your app and it will never call the fork syscall)... but taking that choice away from others who want to use it is unfair as its denying them access to the WASM ecosystem (e.g. bash)

lifty 3y ago

Why does it have the chance to be superior?

samsquire 3y ago
Compiling native application to operating systems that Wasmer is compiled for including the browser and have the code seamlessly work in all of them, I think that's really promising. JVM forces you to write in Java or a JVM targeted language but WASM lets you compile any language that creates a WASM backend.
- vineyardmike 3y ago
  This > JVM forces you to write in Java or a JVM targeted language And this > WASM lets you compile any language that creates a WASM backend Are basically the same thing. There’s no fundamental reason that all these languages couldn’t target JVM byte code instead of WASM. It never happened, not nearly as much as WASM backends are, but it could’ve.
  - ShroudedNight 3y ago
    It seems that NIH also manifests generationally: ? -> CORBA -> RMI -> SOAP -> REST -> GraphQL? ? -> SOA -> Microservices ? -> EDI / X12 -> XML -> JSON p-code -> ? -> JVM -> WASM
    - pjmlp 3y ago
      Before P-Code there were other ones, there were lots of bytecode based platforms. Burroughs, all Xerox PARC, Lisp Machines, OS/400, Oberon, Limbo, original Modula-2, QuickBasic, Amsterdam Compiler Toolkit, VB, ...
    - paulddraper 3y ago
      Okay, but have you used CORBA? Or EDI? It's like saying we had the Model T, but people just keep inventing new cars.
      - ShroudedNight 3y ago
        I have, albeit not terribly extensively. I will readily agree that there are cogent arguments for replacement that pass the Chesterton's Fence test. But I also see quite a lot of "That's too complicated to bother understanding, I'll just do my own thing"
- laxd 3y ago
  > Compiling native application to operating systems that Wasmer is compiled for including the browser and have the code seamlessly work in all of them. And thanks to stuff like this, contemporary browsers are now so complicated that they only run on the top handful of platforms. So how is it progress? I bet JVM runs more places than modern browsers. > VM forces you to write in Java or a JVM targeted language but WASM lets you compile any language that creates a WASM backend. WASM forces you to write in something that has a WASM backend just like JVM forces you to write in something that has a JVM backend. It's just the same all over again. And again.

the8472 3y ago

> It's a chance to create a superior operating system runtime interface. But they're not doing io_uring style syscall queues.

boricj 3y ago

> I think WASI and WASIX is an EXTREMELY important API for the future of computing. It's a chance to create a superior operating system runtime interface. Superior operating system runtime interface and POSIX don't rhyme. The fossilization of POSIX on Unix-like systems, endlessly piling stuff on top of that creaky foundation is probably the single biggest issue holding back the future of computing. WASIX is probably a pragmatic design if you want to run your existing Unix programs on top of WASM. If anything, it's for the past of computing.

syrusakbary 3y ago
I wonder what is the system call ABI that your current operating system uses...
- boricj 3y ago
  What the system call ABI that my modern operating system ought to have is not one that thinks fork() as a fundamental primitive is fit for purpose on modern computers [1], for starters. Mind you, my grievances on the design and typical implementation of Unix-like operating systems go far beyond fork(), but it's as good an entry point as any for this discussion. I encourage you to read the design documents for the Fuchsia operating system, especially those for the Zircon kernel [2] for a fresh, legacy-free take on a system call interface. [1] https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf https://www.microsoft.com/en-us/research/uploads/prod/2019/0... [2] https://fuchsia.dev/fuchsia-src/concepts/kernel https://fuchsia.dev/fuchsia-src/concepts/kernel
  - tokera 3y ago
    i coded the WASIX fork syscall, so I understand all this (f.y.i. I much prefer rust to C as its got a much better designed threading system). what you must realize is that one does not have to use a syscall if they don't like it in (e.g. just use rust to code your app and it will never call the fork syscall)... but taking that choice away from others who want to use it is unfair as its denying them access to the WASM ecosystem (e.g. bash)