One neat trick for TypeScript branded types is to use { "~brand": "SOME BRAND" } instead of { __brand: "SOME BRAND" }. __brand shows up at the top of the autocomplete keys where "~brand" shows at the bottom.
I'm not sure fetch is a good server-side API. The typical fetch-based code snippet `fetch(API_URL).then(r => r.json())` has no response body size limit and can potentially bring down a server due to memory exhaustion if the endpoint at API_URL malfunctions for some reason. Fine in the browser but to me it should be a no-no on the server.
> I'm not sure fetch is a good server-side API. The typical fetch-based code snippet `fetch(API_URL).then(r => r.json())` has no response body size limit and can potentially bring down a server due to memory exhaustion if the endpoint at API_URL malfunctions for some reason. Fine in the browser but to me it should be a no-no on the server.
Nor is fetch a good client-side API either; you want progress indicators, on both upload and download. Fetch is a poor API all-round.
You can pass to `fetch` an `AbortSignal` like `AbortSignal.timeout(5000)` as a simple and easy guard.
If you also want to guard on size, iterating the `response.body` stream with for/await/of and adding a counter that can `abort()` a manual `AbortSignal` is relatively straightforward, though sounds complicated. You can even do that as a custom `ReadableStream` implementation so that you can wrap it back into `Response` and still use the `response.json()` shortcut. I'm surprised I'm not seeing a standard implementation of that, but it also looks straightforward from MDN documentation [1].
Browser fetch can lean on the fact that the runtime environment has hard limits per tab and the user will just close the tab if things get weird. on the server you're right
I'm not saying that axios is unmaintained, I'm saying that if you want something like axios from the standard lib, fetch is the closest thing you get to official
> Current literature does not distinguish between head voice and falsetto.
Hmm, are you sure about this? I thought chest voice and head voice were understood to be a single register called the modal register. And falsetto was fundamentally different.
Yes, though again, the language around registration gets really messy. Here's a great article (with a great title!) from the Journal of Singing by Christian T. Herbst "Registers—The Snake Pit of Voice Pedagogy": https://www.nats.org/_Library/JOS_On_Point/JOS-077-02-2020-1...
One relevant excerpt before the article goes into several pages discussing M11 vs M2:
> These four laryngeal mechanisms are typically termed as: vocal fry (M0, pulse
register); chest voice (M1, modal register); falsetto (M2, head voice?); and whistle register (M3).
Another article by Dr. Ingo Titze (an icon in the field of voice science and basically the father of SOVTs) about the debated "mix" register, starts this way:
> One is called chest voice, full voice, or modal voice, which is described by
a vibratory mechanism that some have labeled M1. Acoustically, harmonic energy above the fundamental dominates the sound spectrum in this register. The other anchor is called falsetto or light head voice, which is described by a
vibratory mechanism labeled M2.
It is indeed part of the standard. It says "Within a structure object, the non-bit-field members and the units in which bit-fields reside have
addresses that increase in the order in which they are declared"[1] which doesn't allow implementations to reorder fields, at least according to my understanding.
Complex for humans: I can learn a new programming language in an afternoon and be reasonably productive in it within a week or two. I wish I could say the same for natural languages.
Complex for computers: We’ve had good compilers since the 50s. Satisfactory language models are less than five years old.
Sure. I cannot imagine anyone living without the most common aliases anymore, but in a script you either need to alias again, or expand. Happens so often to me also.
reply