1. 24

So many buzzwords in one article.

So golang is no longer the hawtness. Rust on wasm on krustlets in obviously the future.

  1.  

  2. 29

    Please don’t add commentary to the story text field.

    From the submission guidelines:

    When submitting a URL, the text field is optional and should only be used when additional context or explanation of the URL is needed. Commentary or opinion should be reserved for a comment, so that it can be voted on separately from the story.

    1. 3

      You triggered me to submit a feature proposal aimed to try and help counter this in future: https://lobste.rs/s/pyxvyo/feature_idea_for_stories_w_extra_text_help

    2. 11

      I know you were probably kidding, but that’s not really why writing an app in Go and compiling it down to wasm is a stupid idea. The Go runtime is a lot larger than the Rust runtime, which is practically nonexistent in comparison. As a result, Go includes a lot of features that would otherwise not be present in a “systems” language, such as garbage collection and extremely fast compile times, because it can offload a lot of the heavy work to its runtime. Rust, on the other hand, forces the developer to manage their own memory, and the compiler is very thorough but quite slow. The trade-off there is that the final binary (including the runtime) ends up being very small, which is exactly what is necessary for the wasm compile target, because a WebAssembly program needs to be fully downloaded before it’s able to execute. This makes Rust an ideal candidate for native application development, in my opinion.

      This is fascinating to me as someone interested in how (and why) programming languages get developed. Go was a language designed to make writing cloud infrastructure easier, while Rust was designed to make cross-platform applications easier to build. Since Go was never designed to run anywhere other than a controlled server (or, more accurately, thousands of them), it didn’t need to worry about the size of its runtime in comparison with the rest of the program. After all, disk space is cheap!

      Go and Rust are both designed for radically different purposes. Even though they can be compared in many ways, I think the real core of their philosophy stems from this fact. It really comes down to which trade-offs you feel are appropriate. Do you want fast compile times, but don’t care about binary sizes? Or how about slower, extremely thorough compiles, but at the end you get a much smaller binary?

      Personally, I’m glad we have a choice of “safe” languages these days. You don’t have to risk runtime safety in order to get good performance anymore, and that’s a huge step up from the last decade.

      1. 10

        As a result, Go includes a lot of features that would otherwise not be present in a “systems” language, such as garbage collection and extremely fast compile times, because it can offload a lot of the heavy work to its runtime. Rust, on the other hand, forces the developer to manage their own memory, and the compiler is very thorough but quite slow.

        Rust requires more thought about memory than Go to pass the compiler, but I’m not sure I’d really count that as “managing [my] own memory” in this case. To use the (perhaps always overused) car metaphor:

        C is a manual transmission that requires you to clutch and manage every shift.

        Go is an automatic that you can set into PRNDL but that’s about it.

        Rust has a very high quality flappy-paddle gearbox that requires no manual clutch, and has a decent automatic mode as well.

        I’ve written code in all three languages, but Rust put a major hook in me and I’ve written more Rust than Go and C combined now.

        1. 3

          The Go runtime is a lot larger than the Rust runtime, which is practically nonexistent in comparison.

          I’m no Rust expert, but I don’t think it has a runtime.

          Go includes a lot of features that would otherwise not be present in a “systems” language, such as garbage collection and extremely fast compile times, because it can offload a lot of the heavy work to its runtime.

          C has a very fast compile time.

          Since Go was never designed to run anywhere other than a controlled server

          Why do they also have a build target for Android then?

          1. 3

            I’m no Rust expert, but I don’t think it has a runtime.

            Depends somewhat on what you count (eg: unless building with no-std, you have a memory allocator which is arguably a runtime library).

            1. 2

              Hummm. Then what’s the difference between rust compiling this memory management and using malloc in C ?

              I mean, with this reasoning, malloc is a memory allocator as a runtime library then.

              1. 6

                Yes, by that reasoning C also ships a runtime library (the ‘standard lib’).

                You could, of course, avoid the runtime library and its overhead (eg by hardcoding all the memory addresses you plan to use, manually ensuring they do not overlap). That’s what my friend in automotive electronics usually has to do, because dynamic allocations can fail. He literally can’t afford the overhead of the C runtime library.

                That sort of nonsense is actually easier to achieve in no-std rust than in C, because you can use the same memory for different things at different times and it can statically check that they never collide. Unfortunately even if there were an LLVM target for the chips he uses there’s no way he’d be able to get a rewritten version into production - the existing stuff has already been tested.

                1. 4

                  C absolutely requires something to provide it malloc, stdio abstractions, atexit cleanups, etc. People tend to forget that it exists, because every OS ships some form of a C “runtime”.

                  It’s especially annoying when people say C makes small executables, because printf("Hello World\n") is X bytes. It’s X bytes that can’t print a thing, and links to a multimegabyte dynamic library (30MB on macOS, for example).

                  1. 1

                    Thanks, never thought about this!

            2. 1

              I’m no Rust expert, but I don’t think it has a runtime.

              It does, definitely more akin to the (very small) C/C++ runtime rather than something like Python or Ruby, whose “runtime” consists of a VM in which it compiles and executes code. Even Java kind-of takes the latter approach (more on that later). Steve Klabnik broke it down pretty succinctly IMO in this talk: https://youtu.be/CMB6AlE1QuI?t=567

              C has a very fast compile time.

              Agreed (well, depending on how big the project is…), but it also suffers from many of the problems that Rust and Go attempt to solve. Also, I’ve never worked on a huge C++ project before…but apparently those take a while to compile as well? One of the “origin stories” for Go was that the motivation behind designing any new language at all was frustration over the massively long compile times that Google was dealing with at the time. It might have been Java but I thought it was C++, can’t quite remember off the top of my head.

              Why do they also have a build target for Android then?

              I’m not sure that Android target always existed. Just googling around I couldn’t find any evidence that it was introduced along with Go in 2009, but I might be wrong. I don’t develop Android apps so it’s not something I would have been paying attention to at the time. At any rate, most of the talks Rob Pike gives about the origins of Go and why it was designed in such a way seem to suggest that its intended audience were C/C++ programmers who worked on large backend systems (like, for example, the world’s largest search engine), and not higher-level application developers. This is why Go can probably now be seen as the “lingua franca” of cloud infrastructure software, because cloud infrastructure was what its creators were trying to build with it.

          2. 10
            1. 2

              Since quite a long time ago, I wonder if we’re going to see CPU designs (or even just extra support) aimed at running WASM bytecode straight on the CPU.

              1. 6

                Ah, the eternal cycle continues.

                1. 3

                  Yep, it’s feeling almost crispy at this point.

              2. 1

                meanwhile, binary sizes are currently getting optimized in go https://twitter.com/bradfitz/status/1256348714198654976?s=20