I'm not seeing the point here, TBH. What use-case does this author's single-binary satisfy?

1. You just want to serve static files from your blog? Install a webserver and knock yourself out in your editor, creating html and css (and maybe js) files.

2. You want to serve static files, with some dynamic crap stuffed inside here and there like the examples given in the article? Install the mod_php or equivalent for your webserver, and go mad with the editor.

3. You want fully generated content? Install one of the many backend frameworks in any language you want to use, and then go mad in your IDE.

What use-case does "one binary I wrote in Go" satisfy that isn't covered above? From everything I gleaned from the article, the PHP solution is even easier, while still technically being "one single binary".

EDIT: as an example of over-engineering, here is the authors code for a specific use-case:

    func ipHandler(w http.ResponseWriter, r *http.Request) {
     w.Header().Set("Content-Type", "text/plain")
     fmt.Fprintf(w, r.Header.Get("X-Forwarded-For")+"\n")
    }
    ...
    http.HandleFunc("/ip", ipHandler)

And here is the equivalent in PHP:

    header('Content-Type: text/plain');
    echo $_SERVER['REMOTE_ADDR'];

▲ bob1029 2 days ago | parent | next [-]

> What use-case does "one binary I wrote in Go" satisfy that isn't covered above?

In .NET land, one of the top reasons to go all-in with a single exe web server would be performance. Kestrel can be unbelievably fast if you remove all of the layers of indirection like IPC and hosted SQL. I've got dynamic HTML pages that render in <100uS and that includes managing session state and other queries into SQLite.

Concerns like accidentally showing up on the front page of HN or even petty DDOS attempts can be often be ignored when you are able to serve content this quickly.

The other major reason I like it is having everything in one type system and debugger experience. I can set a breakpoint anywhere and inspect everything.

▲ malwrar 2 days ago | parent | prev | next [-]

Easier to deploy? No need for packaging everything or installing runtime stuff, just copy one file on your server and run it.

	▲	dlachausse 2 days ago \| parent \| next [-]
		I think a lot of younger developers don't realize that there was a time where you simply FTPed your files up to a directory on a web server. If you wanted to live dangerously, you could even edit them live on the server through a shell account.
	▲	indigodaddy 2 days ago \| parent \| prev [-]
		Redbean is another good candidate for accomplishing this.

▲ 0x6c6f6c 10 hours ago | parent | prev | next [-]

The author also says they want to be able to understand all of the components of the system. Software that needs upgrades that may not be backwards compatible is an issue. I imagine many web servers can fall under either of these concerns, including Apache and Nginx.

I'm not a fan of Go myself, but I can see how a simple Go HTTP server fits the bill.

▲ jbreckmckye 2 days ago | parent | prev | next [-]

But Go is so simple!

(Points to a myriad of Go functions that do in eight or nine lines what other languages do in two)

	▲	acuozzo 2 days ago \| parent [-]
		I'm not defending Go here, but simplicity can also be used to describe not having to incur the cost of (often leaky) abstractions when things go wrong under the hood or when you need to do something different from the intended use-case(s). For instance, PyTorch is simple until you have a __need__ (e.g., rfft/irfft with bfloat16) to drop to CUDA and, in so doing, break autograd and all kinds of other things. Now you need to write a Torch extension and handle Meta/Fake tensors and the like if you want it to work with torch.compile. A lot of the simplicity goes right out the window. If you run into this a lot, then you're doing something sufficiently weird for the simpler solution to, well, not be simpler.

▲ Veen 2 days ago | parent | prev | next [-]

It solves the author's use case, which the article explains at some length.

▲ dlachausse 2 days ago | parent | prev | next [-]

I think a lot of it is just for the author's own fun, enjoyment, and amusement. Also, golang is probably their favorite hammer. It's not efficient for me to smoke a brisket myself or make furniture by woodworking, but I enjoy it. Not everything has to have any more purpose than that.

	▲	j3s 2 days ago \| parent [-]
		bingo. i'm not trying to claim that everyone should do this in go -- it's just a language that i like to use. by all means, use ruby, or PHP, or Elixir, or whatever else you like!

▲ hkon 2 days ago | parent | prev [-]

sigh