kcup-go VS session-scheduler

Definitely a memory leak, but the code is like < 50 lines -- it's a memory leak (and/or my bone-headed misuse) in the underlying library, fasthttp.

I got some help with fixing it from a reader though:

https://gitlab.com/mrman/kcup-go/-/merge_requests/7

Again, the goal was to serve a single file -- I should point out that v1 was using net/http and it did quite well (memory scaled up and down as necessary), but the combination of resource contraints (on my side, I only gave it 100MB of RAM), and use of fasthttp that wasn't ideal/correct caused the issues. It went something like this:

v1 - net/http

Either way, I've made a ticket to use http.ServeFile instead and will likely to change to those when I check the memory impact, thanks for the suggestion.

This is the actual code that caused me to write the ticket above (be warned, I wouldn't consider it amazing code; my first foray into writing a web app as a side project, just trying to get something that works):

https://github.com/gwd/session-scheduler/blob/master/handle_...

Basically, I have several pages I'm rendering, which have common prerequisites regarding checks, and common handling processes (passing some sanitized data to a template). The GetDisplay() functions take a structure from the "database" layer and sanitize it / process it for handing to the templates. The two GetDisplay() functions return pointers to two different types, appropriate for the template to which they will be passed; and return nil if there's an issue.

So I have a map, `data` of type `map[string]interface{}` that I pass into the templates; and two different paths set `data["Display"]`; then at the end I want to check if either of the GetDisplay() functions returned `nil`. So naturally, the first version of the code checked `data["Display"] == nil`, which was always false, since it was implicitly checking `data["Display"] == interface{}(nil)`, but the value in case of an error would be either `DiscussionDisplay(nil)` or `*UserDisplay(nil)`.

I mean, sure, there are other ways to structure this; I could return an error or a boolean rather than returning nil. But 1) the only reason to do that is to work around this language limitation 2) it's a "foot gun" that it's easy to fall into.

And sure, a golang developer who'd shot themselves in the foot a few times with this would catch it during review; but I don't think a bunch of newer developers would catch it, even if they had extensive experience in other languages.

> Checking to see whether the interface "contains" a nil pointer is almost always an error. It is not something you should ever do when you have an interface value.

So here's where I do that:

https://github.com/gwd/session-scheduler/blob/master/handle_...

The pattern is basically:

    var foo = interface{}