The Grug Brained Developer

I was part of a team maintaining 150k lines of ancient JavaScript. Doing this requires careful engineering, but is otherwise possible, though not recommended. A good friend of mine is still there.

I find conversations with him enlightening because there does not exist a mainstream type system which can clearly an concisely express what he's doing there - even though these are fairly mundane things in dynamically typed languages, like arguments with correlated types.

I'm a firm believer in exercise as a means of maintaining skill, so I've been doing a hobby project in vanilla JavaScript. Of course I make type errors, but they're usually the sort that makes me go "aw shit, this field is wrong" and move on. Meanwhile I relearned some characteristics of this environment, which are:

-Tests are mandatory.

-You have to be radically explicit, otherwise you lose track of what you've been doing.

-Documentation is the cornerstone of remaining on track in the long run.

-The biggest mistakes are not in the types, but, unsurprisingly, the logic behind the code.

-General advice, like short-circuiting edge cases, using pure functions and immutable data structures still applies.

-As per Grug (https://grugbrain.dev/) - "grug very like type systems make programming easier. for grug, type systems most value when grug hit dot on keyboard and list of things grug can do pop up magic. this 90% of value of type system or more to grug" - wise tell this, me concur

Some interesting features of…

The drama around this community is silly. I use these tools because I absolutely love their philosophy on software, and software alone. I couldn't care less what the authors personal beliefs and political leanings are, or who they offended on IRC or social media.

I recently spent a few hours evaluating different terminals. I went back to urxvt, tried Alacritty again, gave Ghostty a try, and spent quite some time configuring Kitty. After all this I found that they all suck in different ways. Most annoying of all is that I can't do anything about it. I'm not going to spend days of my life digging into their source code to make the changes I want, nor spend time pestering the maintainers to make the changes for me.

So I ended back at my st fork I've been using for years, which sucks... less. :) It consists of... 4,765 SLOC, of which I only understand a few hundred, but that's enough for my needs. I haven't touched the code in nearly 5 years, and the binary is that old too. I hope it compiles today, but I'm not too worried if it doesn't. This program has been stable and bug-free AFAICT for that long. I can't say that about any other program I use on a daily basis. Hhmm I suppose the GNU coreutils can be included there as well. But they also share a similar Unixy philosophy.

So, is this philosophy perfect? Far from it. But it certainly comes closer than any other approach at building reliable software. I've found that keeping complexity at bay is the most difficult, yet most…

> towards something that is generally appreciated.

I think it's simpler than that.

It's convergence to the lowest common denominator. The simplest implementation of the simplest thing that does the job, in the simplest easiest language that is capable of it.

But because "simple" can be taken to extremes of very clever but abstruse tools that only near-genius level minds can use effectively, and those folks do not work well together, what ends up cheap at first is the simple easy thing that is simple and easy to get working.

Lisp might be arguably simpler in a theoretical sense but for a lot of ordinary folks it's just too weird and too hard.

APL is "simple" inasmuch as a hundred lines of nested loops can be written as one line of a dozen hieroglyphics that does the same task in one operation... but there are only a few hundred people on the planet that can read it.

C is a simple tool for simple computers but you can pick it up and learn how to use it with just a book and some time.

It's fiddly and hard to do anything clever which means programmer must do grug brain stuff.

https://grugbrain.dev/

And that means others can follow it, and work with it, and that means teams scale. Not very well but a bit. So companies can hire rooms full of grugs and make it work.

Result, fairly simple dumb tool beats clever fancy more capable tool.

Result, people who like the dumb tool have strength of numbers and they mock the speccy nerdy weirdos who like the weird tool.

Which is…

I'm not aware of exactly what you're looking for, but I think such a resource would be very valuable. Unfortunately, modern web development has almost completely eschewed simplicity. I can offer some leads, though.

This is more of a manifesto but there is a small movement around simplicity at https://grugbrain.dev/ which is written by the guy behind https://htmx.org/ -- a nice little way to add the bare minimum JS needed for a 'modern' app. You can find a community of likeminded people at HTMX-adjacent places like their Discord and Twitter. I've also been an advocate of this kind of 'primitive' dev style and it's great to see it gain some popularity.

This recent talk from Djangocon "React to htmx on a real-world SaaS product" might be of interest: https://www.youtube.com/watch?v=3GObi93tjZI

Ironically, the ultra-modern serverless platforms such as Cloudflare Workers have strict size constraints which is leading to a kind of back-to-basics approach that minimizes dependencies and bundle size. You can find a lot of small libraries for this at https://workers.tools/. The latest JS framework to buzz here, Deno's Fresh, even touts "no JS is shipped to the client by default". We can see there is a resurgence of interest in server-side rendering.

The classics such as Rails are still alive and kicking. Phoenix seems to be a promising candidate for "the modern Rails".

As someone who experienced the Good Old Days of web development, I would recommend at least trying out the…

> If the FaaS can catch the OOM, restart the instance and re-run the request, the visible effect would be somewhat greater latency for that request.

I’m not aware of an FaaS that would hide the OOM… that falls under the “not a real thing” category. It would be a failed request, which is a very visible effect.

Would you like to link me to the Lamda docs that say it will automatically retry the request in case of an OOM?

Also consider that code which OOMs will do so unpredictably. It may have completed half of a task, leaving that task in a corrupt state that requires manual intervention from a human to recover from. If everyone wrote fully idempotent code that can somehow skip the already-completed updates and continue where the OOM occurred, this wouldn’t be a problem, but that isn’t what everyone does. This is certainly a large reason why FaaS do not retry requests automatically.

> If the service is configured to automatically kill and restart instances after some time or some number of requests, it seems like a reasonable tradeoff.

I don’t believe Lambda has any configuration parameters for those things. That’s not how this is meant to work. Lambda will kill the instance when it has been idle for too long, and that’s the primary factor.

You could manually exit the process when your conditions are met, but why? The benefits of turning off the GC are likely to be negligible. This is a lot of complexity for no real gain. It would take some seriously huge gains…

As another reader who has no idea what any of this is about, I've coerced my favorite LLM to digest it into ooga-booga format in the style of this essay[1]:

# grug see big sky boom

- sky make ooga FLASH but not light, just invisible whoosh (radio).

- whoosh so strong, like sun work many day, but all squish into blink of eye.

- smart sky-people have big ear rock (CHIME). ear rock say: "boom come from there, galaxy far, but not too far (only 130 million fire-circles (light years) away)."

- ear rock also have many little ear-brother rock across land, help point finger very good.

- finger point so good, sky-people know spot of boom smaller than tree forest (13 parsec).

- then, magic glass eye (James Webb) look at spot. see old fat star (red giant) glowing soft.

- but fat star not make ooga boom. hmm. maybe fat star have sneaky tiny angry friend (neutron star).

- tiny angry friend go "KRAK!" → make fast radio boom.

# lesson for tree-brain

- boom in sky still big mystery.

- now smart sky-people can say where boom come from.

- if know where, can watch with other eyes, maybe find secret of why.

- grug think: many sky boom = maybe angry tiny stars yelling far away.

# Ooga booga translation:

"Tree no know why sky yell. But now tree know where sky yell. Soon, tree maybe know why sky yell."

[1]: https://grugbrain.dev/