I've had exactly the same situation, ~2M MAU service with REDIS as the only persistence system, all data being JSON serialized Pydantic models. The storage overhead was just terrible and cost real money.
This would have been a super nice to have back then.
I wonder though how much sense it would make to get something like this mainlined into upstream Pydantic? as having this downstream would give many continuity and dependency lock concerns. And having it as part of the main library would significantly drive adoption rate.
I had this literally happen to me a couple of months ago.
Slacking off while waiting for some performance tests to run (Shoutout to Locust.io!) with my big 27" screen full of terminals for each runner, server logs etc.
...And then on my laptop screen I honestly was just slacking off and reading Reddit.
'VP Of Technology' comes over "I dont know what you are doing, but it's the most impressive thing I've seen in a while".
Provision a VPS/VM/Cloud instance/etc, install your dev tools on it and use it over mush.
And remember for things like looking up git commands or even a lot of your dependency documentation, you do not need a web browser. Git comes with manpages, many libraries will have docs in .md or whatever in them.
The financing arm of a aristocratic line running a personality cult and who have a nepo baby on the cards contemplating a little bit of jyhad as his ticket out?
....I Do sometimes wonder who comes up with these names.
The thought someone went from no programming background, taking a company internal course and then writes a GPU emulation layer in the 90's is just absolutely mad.
M68k has the advantage that it has a fairly typical memory model.
Alpha's memory model has problems with providing atomic access to single bytes, which i'd imagine in a kernel is a bit annoying :-)
And then there's just the social aspect, m68k was used in the Amiga/Atari/Mac/QL/x68k, so there is a whole generation of us m68k fans who are willing to keep it alive.
Alpha has it's fans (me included!), but it's not exactly the same. So in a way it's no surprise it's slowly bitrotting away.
I've used Haskell several times for implementing isolated 'maths business logic units in commercial backend applications.
In one such system I built had the main (REST API exposing) backend implemented in Kotlin with a separate application in Haskell doing a complex set of maths driven business rules against GIS data to calculate area specific prices.
The amount of IO on the Haskell side was fairly minimum and abstracted away quite nicely.
Haskell allowed expressing all complexity in a way that was easy to audit and translate from business/data analyst requirements.
Would do again :-) But only with the correct amount isolation so you can lean into Haskell's strong sides.
I'm a heavy ReMarkable user, mostly as a note taking device when doing client meetings.
For personal use I use it a lot for annotating philosophy papers and source materials, and the lack of a split screen feature is extremely frustrating.
Writing annotations or commentaries on texts means writing in the margins or switching back and forth between books (often a paper book and the remarkable for writing, or 2 notebooks in the device which is a slow operation).
A split screen mode would have been extremely useful, or lacking that a method for having a page-matched 'fold-out' so I can just associate a full blank page to each source page for my commentary.
I know there's an unofficial hack that adds this, but why ReMarkable doesn't I can't fathom, especially as annotations and such are marketed as primary use cases for the device.
Especially liked packet radio stuff back then, but due to regulatory restrictions in practice the networks built are not really all that useful other then for contacts. So in a way, loved the tech but it's really a hobby just for the tech itself rarely applications there-of.