4 ms·
I’m not sure the amount of C code that one wants to run into a server that is not system level code (doesn’t make syscalls itself and implements the server/ bus
by Matthias247 5y ago
I’m not sure the amount of C code that one wants to run into a server that is not system level code (doesn’t make syscalls itself and implements the server/ business logic) is noticeable.
And only if that would be the case the use of WASM would be an advantage. For general extensibility we had Java servlets, Lua modules, PHP modules, etc in webservers for decades.
Maybe it’s interesting for source code obfuscation purposes or in order to allow migration of server logic between different languages. But even that was possible before - and I don’t think the Market need was huge.
- watermelon0 5y agoThere are many tools such as ffmpeg, that you might want to run on untrusted input (e.g. file uploads), and in many cases performance is not that important. Java servlets, Lua and PHP modules cannot be run securely, and there are vulnerabilities for all of them.
- fiddlerwoaroof 5y ago> Java servlets, Lua and PHP modules cannot be run securely, and there are vulnerabilities for all of them The thing is, the JVM was designed with the explicit intention of making it possible to run untrusted code safely: how do we know we got it right this time? The problem really isn't the VM, it's the APIs and authorization model for access to the underlying system's features.
- gpm 5y agoBecause browsers have a good track record of getting this right, and sufficient funding to get this right, and the server-side work gets to piggy-back on that. Also because the API surface area that server side apps need is really just not big, JVM had a lot of problems because it tried to do too much.
- simonw 5y agoI want to use the best-of-breed libraries for image handling, movie decoding and suchlike - and most of those are still written in C.