This is pretty close to type branding (newtype wrapping for the Haskell-inclined), though using template literal types is pretty novel. Normal brands look something like this:
type Brand<BaseType, Brand> = BaseType & { readonly __brand__: Brand };
type FooId = Brand<string, 'FooId'>;
function fooBar(asdf: FooId | 'foobar'): void { }
fooBar will only accept the literal string 'foobar' or a true FooId, but not any arbitrary string. FooId would then come from a function that validates strings as FooIds, or some other part of the app that is an authoritative source for them. Brands extend their BaseType so they can be used anywhere their BaseType is used, but not the inverse
It opens up a huge toolbox of tools that work with Functors and Applicative to make parsing easier, and proves that using those tools will work predictably.
I think you were originally correct and that `Record<string, number>` was not a good example. I would guess that union literals and primitives are handled differently by the compiler in this case, perhaps because a record with keys of every possible string is impossible it may have a special condition to skip some typing rules. In fact, `Record<number, number>` is assignable to `Record<string, number>`.
I believe that would be covariant: `'home' | 'work'` is a subtype of `string`, and `Record<'home' | 'work', number>` is assignable to `Record<string, number>` so the subtype relationship is preserved.
I had read this article more as a "from-first-principles" example, but it's a good note for people who might be unfamiliar with practical Haskell. Using an effects system also promotes the domain DSL from an initial-tagless language (only the interpreter is extensible) to a tagless-final language (both the language and the interpreter are extensible).
It may be worth noting that effectful, polysemy, and the other "new kids" of effects systems are not the only option: record-of-functions, mtl, and type-class effects aren't cutting edge, but they're a little more approachable from an OOP dependency injection pattern.
I don't host it, per-se: I use VimWiki, and occasionally Obsidian for the pretty graph. VimWiki even has a static site generator, but I use Pandoc for that. For search I use FZF and ripgrep.
I can attest to this and took all of my notes on paper in college. However, once I started a real job I realized that this strategy doesn't scale to all situations. In college, I needed to be able to recall all of the information I had ingested: it was low-write, high-read. In the workplace, there's much more information, but I'm unlikely to need most of it: it's high-write, low-read. I need to be able to reference the information, but not necessarily recall it. Taking paper notes became too much of a burden and I moved to a wiki of markdown notes.
After the Federal Reserve adds money to the economy, they usually want to take some of it back out. They take money out either by selling bonds or through taxes. The goal of removing money from the economy is sometimes to control inflation, but it's debated whether "printing money" actually affects inflation.
I see this argument made assuming that REST service creators are not aware of L3 REST but the fact that it never caught on is at least some proof of its ill-fitness to the general problem. Nowadays we have many more options that do what L3 REST tries to do (OData, GraphQL, etc) and most APIs at least conform to L2 REST. This is a classic case of friction between design intention and actual user experience: there was a push-door with a handle, and users aren't using the handle, they're just pushing it.
It's good for IoT and automation because it's fundamentally a framework for discrete functional reactive programming. It could be good for any context where you need to tie together a bunch of events from different contexts that all depend on each other to drive some other behavior. You can design design nodes and flows that minimize state and keep it local.
I've used Lenses as a beginner/intermediate haskeller and they're very easy to use. It's easy to get bogged down in the theory and specifics but Lenses are perfectly usable on the practical level without ever diving in too deep. That said, now that RecordDotSyntax is a thing, there's less of a use case for surface level lenses.
That's how I got to this question. I went through the usual guantlet of finding a self-hosted RSS app I liked as well as exploring freemium options and eventually settled on Inoreader. The "plus" tier is ~2USD/mo and is cheaper than what it would cost to host my own, and is overall one of the better readers.
This hasn't been my experience. FP is a fantastic complement to OOP for "practical" programming. It adds an entirely new dimension and avenue for expressability which is why we're seeing more and more OOP languages borrow heavily from FP. For all its abstractions, OOP tends to encourage stateful design and accumulate complexity which is where FP shines.
This is the point that I have the most trouble understanding in critiques of Fowler, Bob, and all writers who write about coding: in my reading, I had always assumed that they were writing about the perfect-world ideal that needs to be balanced with real-world situations. There's a certain level of bluster and over-confidence required in that type of technical writing that I understood to be a necessary evil in order to get points across. After all, a book full of qualifications will fail to inspire confidence in its own advice.
Essentially, it's only useful for pasture raised cows (soy and corn fed feedlot cows already produce a fraction of the methane) and there's no practical way to add algae to pasture raised cows' diets. They also speculate that cows' microbiomes will adapt to the algae.
Code purity isn't just for you, it's also for the compiler to be able to make assumptions about the code in order to apply optimizations that would not otherwise be possible. For example, if the compiler "knows" that a certain branch won't be used, it doesn't have to evaluate it. This is part of the reason why Haskell can reach near-C performance and why its recursion is particularly performative.