Derw, a human written Elm fork by me, is largely self-hosted. I took that decision with inspiration from Go: 1) it gave me a large codebase which could be used to assess language features on and 2) it gave me motivation to improve generalized performance rather than focusing on the niche use cases (web-rendering).
You're missing Derw from that list: https://www.derw-lang.com/. Predates all the others, and is from a former core team member (me). I'm also the author of server-side Elm experiment known as [take-home](https://github.com/eeue56/take-home) from 11 years ago. I can see a lot of patterns in Sky's codebase which seem trained on Derw's codebase.
Also authored the first Elm-in-Elm compiler for a limited subset for json-to-elm, then leading to a pure Elm virtual-dom implementation used for elm-html-test!
I KNEW I forgot one. I'm really sorry. This list was off the dome and I was hoping to hit a Cunningham's law situation (which I did) without making anyone feel left out (which I failed).
No worries at all! I didn't take offense, it's very easy to forget one or two projects when quite frankly, Elm has managed to spawn or inspire so many!
Egoless Engineering, a book about how to be an enabling staff engineer in the Nordic's largest mediahouse. I saved up vacation and took the whole of December off, mostly to relax. But I'm also working on more chapters for my book.
Tools to help my mental health tracking[0], and sharing with others how I manage my limited amount of energy[1]. They're kind of related, since mental health impacts my energy, so I've needed to prioritize and really make sure I'm spending my time and energy on things that matter. Usually, there's a good mix of things I enjoy doing with things I gain a lot out of. I've spent a lot of time thinking about this!
I've used my app in various forms for around 5 years, rewritten multiple times. But now I'm creating surrounding tooling to help others put my mental model for personal life prioritize to use. I'm writing in the "Saving Spoons" Substack as I go, trying to explain why and how I do things, with advice for others trying to do the same thing.
Native Welsh speaker here! It has always been a dream of mine to go to Y Wladfa, and share a bond through language with people there.
One fun fact - my dad took some higher-learning Welsh exam as an adult. They had to time the exam to match Patagonia, as they were given the exact same exam to avoid any cheating.
Oh, there were definitely multiple things wrong. Bear in mind that this was 12 years ago, so this is just what I took away with me as an on-going learning. Obviously showing errors to users is an obvious takeaway, but it's a side discussion from affordance.
Results were sent as a CSV file - basically a raw export of the data the server got, not something that was read from the DB. So the operation to save to DB and to send the email were intended to be (almost) parallel operations. The errors weren't shown to users, though there was error handling for other cases that did show the user.
We actually did test. We didn't test in the exact same conditions or environment (i.e with no internet access), as we didn't find out about the no-internet restriction until the last minute. That is covered in this paragraph:
> While this bug was a costly mistake, we learned from it. Whenever we would deploy code-last minute, we'd try to test it more rigorously. If we were running a study without internet access, we'd make sure to test in the same environment. We hadn't accounted for the environment change, partially due to the short notice for the locked-down machine, but also just because we didn't test with the exact same restrictions.
Indeed - I have an extended equivalent from CGI-bin that I'm including in the full story in the book, since running things as a script vs as a program has different implications for killing the running process. The patterns you mention here tend to be my preferred way of working - exhaustiveness checking of branches. In modern TypeScript, I enforce that via union-type error handling rather than using exceptions (which are a nightmare when it comes to affordance imo). I'm generally a functional programmer rather than an imperative programmer. But the case mentioned in the blog post was about 12 years ago now, so it didn't have the same options as we currently have.
The way I put this practice into place involves accepting that people will just do whatever they find easiest, regardless of whether it's technically the right thing to do. I account for that when I'm designing APIs, languages ([Derw](https://www.derw-lang.com/)), frameworks, or tooling. If I make the correct thing the obvious or easiest thing to do, less people will do the incorrect thing. They will still do incorrect things, it's human nature. But they'll do it less frequently.
In this case, I think the actual API we used would take a callback for success, and a callback for errors. I just used JS an example for how unnatural it would be to call something that exits the entire script early.
I have a big problem with promises + exceptions generally in JavaScript - much preferring union types to represent errors instead of allowing things to go unchecked. But I left that out as it was kind of a side-note from the point of affordance.
