1. 14
  1. 4

    You can simplify this with http.Handle("/", http.FileServer(content))

    1. 3

      Zig’s @embedFile is particularly nice as you can use it at both runtime and comptime; you can e.g. check the file contents at comptime to make sure it’s what’s expected, and then serve it at runtime (or whatever).

      1. 1

        I haven’t gotten to try out io.fs yes, but seeing that fs.File implements io.Reader, you could probably also use io.Copy, instead of buffering the content in a byte slice + converting to a string and writing it over and over again.

        Of course, if it’s just a static application st3fan’s suggestion is probably even better, but at that point, you might just as well use a regular web server.

        1. 1

          It’s worth pointing out that Go is far from the only language that can do this, though I did also learn it in Go.

          Janet and Nim both have answers for this, just to start with, and .NET core has the ability to bundle resource files , dlls, and so on into an executable.

          I definitely like this ability from a “deploy the code” standpoint.

          1. 2

            Yeah, in D there’s a built in import("file") thing that pulls in the file to the executable as a string literal as if you typed it in the code.

            I actually avoid it though because replacing files separately is nice. Like hitting recompile to see a css change feels like such a drag (even though the recompile is pretty fast, like 1.5 s on my stuff usually, it isn’t as fast as just hitting save and then refreshing the browser).

            But perhaps for deployment it is ok, just users might want to edit those same files too….