Maybe ridiculous, but not totally unprecedented. Aga Khan IV is generally considered to be royalty despite the fact that his family hasn't held secular power (outside of the occasional governorship) since [1095](https://en.wikipedia.org/wiki/Nizar_ibn_al-Mustansir). Of course, they held religious leadership as Imams of the Nizari branch of Islam.
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.
> If you try to simply cook wheat grains, you will end up with a rather nasty porridge
Maybe nasty to modern eaters, but wheat porridge was a staple in Europe, N. Africa, and the Middle East for thousands of years, especially outside of towns where gristmills were far away and often exorbitantly expensive
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.
bindgen[1] already exists to autogenerate a rust API from c headers. It's inherently unsafe because C code is inherently unsafe. In particular, there is no language constructs like destructors or constructors, so you can't naively create a C-based API that can prevent memory/resource leaks and use after free errors. While C++ does have the same issues as C with unsafe pointer semantics, it does have constructors, destructors, and other features that map almost perfectly with Rust's RAII-based resource management, making it pretty easy to generate a safe(ish) rust interface. In practice, it's pretty easy to create a safe rust API from a C library: use bindgen to create the low-level unsafe API, then create rust wrappers using the ad-hoc creation and descruction library functions to implement RAII.
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.
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).
I'd argue that Python type hints are actually a step back. Sure, they may work 80% of the time, but there are times where you need the extra flexibility offered by DRF serializers. Those can go way farther than the basic "map these JSON data types to this Python representation" which would then be difficult to represent using basic Pydantic-style hints (you'd have to the rest in procedural Python within your endpoint, which can't easily be reused when it comes to function-based views, where as DRF abstracts that away within the serializer which not only can be reused, but itself can be composed of multiple classes/mixins).
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.
IMO Guix is better but still has some work. My major pet-peeve of Guix is it's anti-proprietary software, which is a necessary compromise. The world is composed of many different people and beliefs; software should be belief-agnostic.
I think it's worth pointing out that guix will not package proprietary or binary software in the main channels but nonguix exists for those needs if one absolutely needs to have those packages in guix. At the same time guix packages flatpak which allows one to install most, if not all, of the proprietary packages they may want to use. I think the compromise from the guix maintainers is to develop and distribute free software but at the same time being silent on how a user goes about adding proprietary packages to their system. Which is fair IMO.
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.
Whether or not the laser is in the visible spectrum matters quite a bit for it’s classifications/safety. According to IEC 60825–1 a laser from roughly over 1/2 a mW up to 5mW goes from class 2 to class 4 if it’s outside visible. A nearly 5mW laser could scorch many materials, given enough time.
