1. 12
  1. 5

    I’m definitely not sure adding wasm helps anything. It seems to just be a redundant layer and another point of failure on a server.

    We have an artifact that can be stored and upgraded, which is source code.

    I don’t understand this.

    1. 1

      Reproducing the artifacts of source code requires reproducing the build environment, up to an unknown tolerance. If you have legacy source code and build environments and lose the artifacts, it’s not as much of a problem as having the legacy artifacts and losing the legacy source code and build environments. You’re stuck having to dig up and reverse engineer much more.

      Wasm makes this not sting as much. It’s failing better. Failure is undesired, but still engineered for.

      1. 1

        wasm doesn’t help any of what you just said. Tools like nix and guix do however.

        1. 1

          I’ve lost derivations with Nix before. It’s a pain to deal with. Cross-compilation and linking is still a pain. Wasm serves different goals, though they may be in similar areas.

          1. 1

            Did you lose the source code (original nix expressions)?

            1. 1

              Effectively? If you’re using a channel that got upgraded, you have to figure out what VCS revision you were on before, and then coordinate rolling back everything and substituting in those rolled back source copies to rebuild.

              This isn’t as much of an issue if that generation is still hanging around in history, but what if you’ve got a result hanging around from an ad-hoc nix-build, that was sent via nix-copy-closure without its source(s)?

              Wasm handles running whatever binaries on any platform, and giving you a consistent representation for analysis. Nix doesn’t really touch any of that. Nix, Nixpkgs, and NixOS all tackle building artifacts on platforms reproducibly, and also extending that style of artifact to the system level and using those reproducibility tools to cross-compile with a bit less pain.

              1. 1

                wasm doesn’t handle that at all until they make a portable syscall interface.

    2. 5

      Beautifully written. I’ll add that a lot of this is addressed by verified compilers. Two examples. That’s where humans try to be as perfect as gods when they design and code them. Results vary. Maybe verified (or verified-enough) compilers that are modular for easy modification with better UI for programmer telling them their expectations. It could just be modes (esp backward compatible vs modern), targets (GCC vs WebAssembly), etc. Nim’s ability to use a bunch of back-ends is an example.

      Regarding WebAssembly, I agree with the others it might not change anything far as what internal gears do. You previously had (portable or non-portable source) -> intermediate code w/ optimizations -> native code. Now, you have (portable or non-portable source) -> WebAssembly -> native code. I still say non-portable because specific browsers might do things in their implementations that change how a WA program behaves vs others. If not, you at least get portability at WebAssembly level. From there, you get varying performance or side channels based on each ones’ JIT’s: another set of gears that have even less time than an ahead-of-time compiler to do the job wisely.

      1. 6

        I don’t really see how wasm changes anything in your metaphor.

        Yes, you have a binary that is interoperable, and can be upgraded, but you still need a lower level that translates your bytecode to assembly, and that’s the part that really matters.

        You’re just moving the problem one level up the abstraction layer, just like the JVM or any other bytecode interpreter does. If your chip architecture changes, who’s going to do the work to change your V8s, your runtimes? If anything, the fact that so many other programs depend on the speed and correctness of the runtime and interpreters makes it even more important that architectures don’t change important things: we wouldn’t have ARM adding JavaScript-specific floating point instructions, or Java processors otherwise.

        1. 2

          In addition, I assume there will still be insecurities baked into old compiled wasm files (eg libraries). The same problem you will find with old static binaries or old java jars/class-files. They may still run, but they may run very insecurely.

          1. 1

            See @swifthand’s reply elsewhere in this thread: https://lobste.rs/s/xpdzz8/gears_gods#c_vgvl30

          2. 3

            I just wanted to say that I appreciate the imagery used here. I understand that it doesn’t necessarily affect the technical merits of the argument (which I think is a good one), but it was a pleasure to read. Technical writing that is actively fun to read at the prose level is not common. I am reminded of James Mickens, @aphyr’s Hexing the Interview and Fred Brook’s essays on building castles in the sky.

            1. 2

              James Mickens

              A direct link must be offered: https://mickens.seas.harvard.edu/wisdom-james-mickens. His work is incredible.

            2. 2

              The animated background makes the text unreadable. It is not very accessible this way. If I were you, I’d reconsider this design.

              1. 5

                I thought I did it in a way that was cross-browser friendly. Apparently it is not. I have pushed a commit that restores old behavior (of the snow being occluded by the content frame) as well as a fix for the prefers-reduced-motion CSS query.

                Sorry!

                1. 2

                  Oh thanks, I didn’t know about the “reduced-motion” thingy! Turns out it’s a simple accessiblity setting on most operating systems: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion.

                  1. 2

                    No problem, just thought I’d give some feedback on stuff which was disturbing for me.

                2. 2

                  And THIS is why I’m such a big advocate for WebAssembly on the server. This lets you take the output of the Gods and store it in a way that it can be transparently upgraded to new sets of gearing.

                  You should read up on IBM i (née AS/400). Programs were written to target a virtual architecture called TIMI, and then were translated on first run to the machine’s native instruction set. You could upgrade from a completely different machine (the original AS/400 custom architecture) to PowerPC without changing the binaries in the operating system. All the compilers produced TIMI AFAIK.

                  1. 4

                    I have! That’s where a lot of my inspiration has come from.

                    1. 2

                      Not intended to be trolling, but isn’t this the same sort of promise we had for Java bytecode and so on?

                      1. 4

                        Yes, but Java bytecode wasn’t an effective C/C++ target. WASM has been demonstrated to be an effective C/C++ target for certain things, almost too effective, as you’ve pointed out previously (in terms of making it easier to exploit timing attacks, that sort of thing).

                        1. 3

                          Not addressing the article (consciously), but responding specifically to TIMI, Java bytecode, and so forth, a thought experiment for why “this time will be different”:

                          One major challenge with Java was getting everyday “home users”, or consumers, to download and install a huge, chunky runtime, keep it updated, and so on. To even know how to ask “What’s a ‘Java’?” was when all they wanted to do was install this cool Freeware CD Burning software their friend linked them to over AOL Instant Messenger.

                          Businesses (or hobbyists utilizing professional infra) can and will choose a cool tool or technology. Yes, upgrades in some organizations or some projects can be a bit iffy, but the adoption issues facing Java were not a function of availability or desire by professionals, when compared to consumer adoption.

                          With wasm, the users are already being dragged along by evergreen browsers. Update mechanisms have far less friction than they did in the 00’s for Java. They will have wasm eventually, and the hard part will be done. The businesses and the nerds will have no trouble using it if we want it, and the circle is complete.

                          Now will the foundations or primitives of wasm stand the test of time? That is a different wrinkle, and I don’t know. But thinking about the nature of what shapes that standard, but my thoughts drift to the legal realm: the standardization and ownership structures of the technology itself being in the hands of W3C Community versus being in the hands of Oracle. I can see people having confidence that they could build their own community (or internal corporate) runtime implementation of wasm down the road, because of the precedents: they are free to build their own HTML/CSS rendering engine, even though it might be a fool’s errand requiring a legion of Talmudic scholars.

                          I’m not going to call the W3C saints, but I would never insult them by comparing them to Oracle. It is a meaningful difference, in addition to consumer/everyday user adoption.

                      2. 2

                        I like the gist of this, but my tastes go in a different direction. Specifically, that is: “to hell with the compiler gods,” instead giving the users many of those powers. Lisp is an example of this: it provides a substrate for computation that is a building block, while also being a language.

                        I realize you still need to implement Lisp. But doing so is decoupled from what Lisp is, and how extensible Lisp is. That’s the deep magic.

                        1. 1

                          At the same time, you still have people building compilers from Python to native code. Having a runtime with Common Lisp’s flexibility and power is admirable, but people have shown time and again that they’ll use, develop, and prefer more languages than Lisp. Wasm is a unifying substrate for about the lowest required level of programming.

                          Plus, with a compatible Wasm runtime, emitting “native” code live (e.g. from a Common Lisp) is extremely feasible, with the upside that it’s one target that’ll carry across underlying targets (where Common Lisp suffers from the implementations lacking portability due in part to their native code emission).