1. 30

  2. 18

    Another fun fact, compiling natively has 100% native speed.

    I don’t see the point if you aren’t using the sandboxing to be honest.

    1. 9

      Having recently been through the rigmarole of trying to build & distribute a DLL for various platforms, I can safely say I would much, much rather distribute a single wasm blob, especially if it’s going to run just as fast.

      It’s still far too hard to release cross-platform software.

      1. 2

        I don’t understand how you think WASM will help that case? If it is is the third party libraries that cause the problem, wasm has no extra help for you other than statically linking, which you could do anyway.

        To me you are saying that DLL’s and dependencies suck, not that WASM is of any use there. There are lots of ways we could solve dependency hell.

        1. 4

          The key word is “various platforms”. WASM helps by reducing various platforms to one platform.

          1. 2

            I don’t agree that it does in the context of this article - Not until they develop a cross platform WASM gui standard and system emulation layer, you still need to call the platform specific API’s like Win32 or linux, or BSD specifics different/missing syscalls.

            I suppose it is removing one variable, the cpu arch - which removes one subset of problems, like integer width. All the other problems seem to be there.

            1. 3

              The specific case I had recently was developing a native extension (a customized cuckoo filter implementation) to package in a rubygem.

              In a world where most high-level languages had native support for loading WASM modules, I’d be able to easily build it once and ship the compiled extension. Would be a huge improvement over the current state of the art (which is that everyone has to have build tools installed, so native extensions can only be c or c++).

              1. 1

                In that case the ruby runtime will need to ship a WASM compiler. If they wanted to ship a compiler they could have shipped a C compiler already and not worried about which is installed.

                edit: oh - you are right about the language thing.

                1. 2

                  For good or for ill, I forsee a future where most high-level interpreted languages ship a WASM compiler (probably mostly using the same one, like they do with openssl for crypto).

                  The added complexity will be considerable, but the convenience isn’t nothing.

                  1. 1

                    Not if you can just have a wasm module turn into native code.

        2. 4

          I think the point is to distribute the same binary which is compiled and cached at install time.

          1. 8

            Didn’t we go through this twenty years ago with Java? Which was inspired by then twenty year old technology known as UCSD Pascal?

            1. 9

              Yes, and it has been a huge success, though the JVM and Java bytecode is rather Java-centric. Something more language agnostic like Wasm would be fantastic.

              1. 6

                or the AS/400 system.

              2. 2

                I don’t really see why that couldn’t be accomplished by caching and compiling source code, and getting 100 percent native performance, if it was something people really wanted. (Actually we have this - package managers).

                I can see the real problem being all the platform specific syscall hiccups and incompatibilities causing huge problems, even with this approach, and perhaps even worse.

                1. 5

                  I don’t really see why that couldn’t be accomplished by caching and compiling source code, and getting 100 percent native performance, if it was something people really wanted.

                  Proprietary code.

                  But other than that, yes, I think this is mostly a way of attaching buzzwords. This may fool people into thinking native code is hype-worthy.

                  1. 2

                    I consider inNative as Gentoo ebuild competitor, but without build dependency complications. For example, to build C++17 source code you need C++17 compiler. inNative doesn’t care about C++ frontend standard support.

                    1. 2

                      As someone that used to run FreeBSD and build applications from source… it might work, but is almost certainly a user-hostile solution.

                      I still have the PTSD scars…

                      1. 2

                        I dare you to try and package a complicated program in more than two package managers. It’s a full time job.

                        1. 1

                          This is designed for the cases you DON’T have source code though. What can you do with winword.exe or $RANDOM_ACCOUNTING_SOFTWARE_FOR_WINDOWS_VISTA.exe?

                    2. 5

                      If you think about it, most of your programs run outside a sandbox. This is why we have anti-virus software and “Run As Administrator”, since the kernel doesn’t put many restrictions on what programs can do. We just trust that the programs we install will be well behaved.

                      Maybe we shouldn’t do this so much though. Even we tech-savvy folks are susceptible to social engineering. So we need the protection of sandboxes just as much as everyone else.

                      1. 1

                        Would be interesting to see how this compares to something like wasmtime.

                        I also didn’t see any mention of WASI support, I wonder if they plan to add it?

                        Very cool to see so many WebAssembly projects pop up.

                        1. 3

                          Wasmtime is a JIT and uses Cranelift. inNative is an AOT and uses LLVM. Since it uses LLVM, it probably sucks as a JIT.

                          1. 1

                            That’s one aspect in which they differ, but both allow you to run WebAssembly programs as system software (by which I mean “outside the browser” in this context), so they have a significant overlap in terms of where and when they could be used.