dangerbird2

One possibility is that they have fewer regions than something like AWS, so they can put their data centers somewhere where they get favorable electricity/cooling costs.

Did you read the article? All the proposal does is allow the javascript engine to accept typescript-style syntax, while erasing all the annotations at runtime. From the browser's point of view, it would essentially treat the type annotations and type declarations as comments. This combined with native Ecmascript modules means you could theoretically develop a typescript application with no bundler or other build tools. You'd be able able to use typescript autocomplete and linting in your editor, and just serve the files to your browser with a static http server. Some newer bundlers like Vite and esbuild greatly reduce the amount of configuration required to set up a typescript project, but being about to develop a project with nothing but an editor and a browser would be a huge win for small projects.

Since the proposal doesn't care about the semantics of the type annotations, it doesn't even necessitate typescript. It would work just as well with Flow typing or even a completely new type checker.

This article is about Australian magpies, which aren't related to European Magpies and other corvids. They're known more for their extreme territoriality than for their intelligence, but OP's article clearly shows they're no dummies either.

But that means it's almost impossible to get heart cancer, so at least we've got that going for us

DRF was about as good as it got for automatic schema generation and data validation before python static type hints made things like pydantic possible. It also sets up good defaults for stuff like query parameter-based filtering, pagination, and resource relationships (it supports HATOAS by default).

How does Guix compare to Nix? It seems like by using a scheme-based DSL instead of an ad-hoc configuration language, it solves one of the main complaints the author has about Nix.

They'd fare poorly, but for different reasons. Digital cameras can be vulnerable to IR lasers because their sensors are sensitive to infrared light. Human retinas aren't sensitive to IR, which ironically makes IR lasers more dangerous than visible ones, since they don't trigger the blink reflex which would otherwise limit the damage to the eyes.

Python does have real threading. The `threading` module provides os-level threads and synchronization primitives. The only difference between this and multithreading in C or Java is that CPython's GIL prevents more than one thread executing bytecode at a time. This prevents parallelism, but not concurrency.

Note this does not mean that python code is thread-safe by default. At most, you can theoretically rely on bytecode operations to be atomic, which means you'll need to synchronize multi-threaded code with mutexes, semaphores and higher-level synchronization constructs.

Also office scanners. Basically, it's still a 2D image, but instead of two spatial dimensions, it has a spacial dimension and a time dimension.

> once you’ve taken your picture, you need to: 1) remove remaining silver halide that wasn’t exposed to light, 2) “fix” the remaining silver so it’s stable

Isn't that somewhat backwards? The developer converts exposed grains to metalic silver to create a visible image from the latent one, the stop bath neutralizes the developing solution, and finally the fixer dissolves unexposed silver halide.

It's not owned by the bank until you foreclose, after which it's most certainly owned by the bank.

As an aside, how often is it for the manufacturer/dealer to own the bank that issues auto loans. I got mine from Capital One, and I assumed most auto loans outside of the sketchy loanshark used car dealers were issued by the big national banks

Fluent-bit/fluentd are written in C and ruby :)