Awesome talk! The speaker makes presenting look easy. It sounds like the pendulum is swinging back in the direction of functional programming. Lightweight processes that are isolated. If you want that process to trigger a side effect, pass a function into it.
This is an awesome solution for highly secure next-generation application. I have one question, although it is still in the early stage, could we estimate the overhead caused by those permission constraints of WASI compare with the old school application?
Huh. What about Wasmer?! This industry is starting to become fragmented right from the start. What is the reason for leaving Wasmer out? Pretty sure Wasmer won't refuse such an offer.
I don't think that parent (nano)processes should be able to pass access rights DIRECTLY to their "child" nanoprocesses. That should go through the WASI VM/runtime "conductor" (as with the memory copy memory "cartoon"). AND access rights should only be doled out on a function-call by function-call basis. The parent nanoprocess should inform the "conductor" of exactly what access to exactly what files or sockets or memory the called nanoprocess requires to accomplish a specific task and the "conductor" actually does the work of making the calls to the operating system API. In fact, one could literally keep the child nanoprocess completely in the dark as to which resources it was actually accessing. For instance: The parent nanoprocess could tell the "conductor" that they are calling a function in the child nanoprocess. Said function call would be given a unique identifier. The parent nanoprocess would tell the "conductor" that the child nanoprocess should be allowed to read from a specific network socket and write to a specific file. The "conductor" then passes two generic (and genetically named) streams to the child nanoprocess. One for reading and one for writing. The child nanoprocess has no clue where it is reading from or where it is writing to. It can wrap those generic streams inside of more specific streams to make reading and writing specific data types easier. So the child nanoprocess knows exactly what it is writing and the exact format in which said data is written, but still has no clue where it is going. It is kinda hard to maliciously write to the wrong file if you don't even know whether you are writing to a file or a network socket or a printer or the screen.
@@theoligarchist1503 that was my meaning as well. The way most js apps bring in outside dependencies willy nilly is batshit crazy insane. JS community has been reinventing everything done in computer science since the 1970s - badly. It's really nuts.
yes these guys dance with joy over composition in Elm while Rustlang is baked from ground up in Composition and never have to even mention it. And Scala had real Mixins for more than a decade, so JS is counting its last days now, their Karma is finally catching up with them.
Awesome talk! The speaker makes presenting look easy. It sounds like the pendulum is swinging back in the direction of functional programming. Lightweight processes that are isolated. If you want that process to trigger a side effect, pass a function into it.
Absolutely excellent video. Thanks yet again Lin, and all the WA folks!
This is a wonderful talk, and wonderful cartoons too!
16:00 If the data is immutable, can the copying be avoided?
Function-passing, memory-isolation, & interface-types. Brilliant!
such was done in the 90s for com dcom by M$
This is an awesome solution for highly secure next-generation application. I have one question, although it is still in the early stage, could we estimate the overhead caused by those permission constraints of WASI compare with the old school application?
Your cartoons are awesome
Huh. What about Wasmer?! This industry is starting to become fragmented right from the start.
What is the reason for leaving Wasmer out? Pretty sure Wasmer won't refuse such an offer.
Mozilla monopoly
The Oligarchist isn’t Mozilla a non profit?
I don't think that parent (nano)processes should be able to pass access rights DIRECTLY to their "child" nanoprocesses. That should go through the WASI VM/runtime "conductor" (as with the memory copy memory "cartoon"). AND access rights should only be doled out on a function-call by function-call basis. The parent nanoprocess should inform the "conductor" of exactly what access to exactly what files or sockets or memory the called nanoprocess requires to accomplish a specific task and the "conductor" actually does the work of making the calls to the operating system API. In fact, one could literally keep the child nanoprocess completely in the dark as to which resources it was actually accessing.
For instance: The parent nanoprocess could tell the "conductor" that they are calling a function in the child nanoprocess. Said function call would be given a unique identifier. The parent nanoprocess would tell the "conductor" that the child nanoprocess should be allowed to read from a specific network socket and write to a specific file. The "conductor" then passes two generic (and genetically named) streams to the child nanoprocess. One for reading and one for writing. The child nanoprocess has no clue where it is reading from or where it is writing to. It can wrap those generic streams inside of more specific streams to make reading and writing specific data types easier. So the child nanoprocess knows exactly what it is writing and the exact format in which said data is written, but still has no clue where it is going.
It is kinda hard to maliciously write to the wrong file if you don't even know whether you are writing to a file or a network socket or a printer or the screen.
So Now its clear , its dangerous to write JS code
Always was. 😎
i mean Dangerous in the sense as a security risk, not just in terms of Bugs
@@theoligarchist1503 that was my meaning as well. The way most js apps bring in outside dependencies willy nilly is batshit crazy insane. JS community has been reinventing everything done in computer science since the 1970s - badly. It's really nuts.
yes these guys dance with joy over composition in Elm while Rustlang is baked from ground up in Composition and never have to even mention it. And Scala had real Mixins for more than a decade, so JS is counting its last days now, their Karma is finally catching up with them.