Static files in Go

Individual platforms do seem to do it. If I understand Windows resources (and I don't really), they are just file blobs munged into the executable and then accessed through a simple sort of namespace.

Seen that way, resources are over-engineered. The basic compiler feature we weant is something like:

    const char blob[] = __include_binary__("blob.dat");

But if I could do that, then probably the next thing I would do is invent some macro-magic to provide a resource-like namespace on top of the feature.

Windows, Mac OS, BeOS, Symbian and quite a few others offer direct support for it, it is just a matter of using the OS APIs.

This was already like that on the 16 bit days.

For example, with Turbo Pascal for Windows, you only needed to do, after generating the resources via the resource compiler

   {$R resource name}

and then make use of FindResource/LoadResource/LoadFromResourceName

You can always (ab)use the linker! [0]

[0]: (shameless plug) http://stackoverflow.com/questions/8923097/compile-a-binary-...

These tools are simple enough that its easier to start from scratch than to try an understand someone else's code.

It does explain it though, as they all implement `http.FileSystem` which constrains what tricks you can pull of

Yep etags is on my list of things to implement

I've added etag support

I guess it's because the templates don't have to ever be parsed since they're transpiled to Go code at compile-time. It's been a while since I've used Go's template packages but I thought that they're only parsed once no matter how many times you execute it (assuming reuse of the Template struct). So to me, it seems there should really be no difference from just putting the initialization of the template in an init() func.

<DISCLAIMER> I have never written a templating engine. Anything posted here by someone who has probably takes precedence over what I say here. </DISCLAIMER>

A thing can only be fast relative to another thing. If ego were the only templating solution available to software developers it would be meaningless to describe it as "fast". I have never used ego and do not know how much faster it is than the alternatives (if at all).

However, ego templates are compiled to go source which ends up as machine code in your program that just writes out the strings. I believe most alternative templating libraries parse your template into a data structure at run time and then need to walk that data structure every time you want to render the template in a new context.

So, consider a template like "<div> <h1> {{title}} </h1> <p> {{description}} </p> </div>"

Using the ego strategy the code that has to execute to render it amounts more or less to a linear series of 5 calls to a method that appends strings into a buffer.

Using an interpreted-template strategy, i don't know exactly what that machine code is going to look like but it necessarily involves a lot of consulting the parsed template to see what the next step is, and maybe even a lot of lookups of strings in hash tables.

Aside: In the Java world, the fastest template rendering engines probably compile a template into JVM bytecode which can then be loaded and executed in the current process, yielding what could reasonably be considered the best of both worlds.

Ego is as fast as it gets for tenplating, as it compiles the template to Go code. It probably doesn't matter that much performance wise in this case, I would've used it either way.