> What exactly does it mean to have "good dynamic typing facilities"?
To quote Peter Norvig on the difference between Python and Lisp, but you could apply it to most other mainstream dynamic languages vs Lisp :
> Python is more dynamic, does less error-checking. In Python you won't get any warnings for undefined functions or fields, or wrong number of arguments passed to a function, or most anything else at load time; you have to wait until run time. The commercial Lisp implementations will flag many of these as warnings; simpler implementations like clisp do not. The one place where Python is demonstrably more dangerous is when you do self.feild = 0 when you meant to type self.field = 0; the former will dynamically create a new field. The equivalent in Lisp, (setf (feild self) 0) will give you an error. On the other hand, accessing an undefined field will give you an error in both languages.
Common Lisp has a (somewhat) sound, standardized language definition, and competing compiler/JIT implementations that are much faster than anything that could ever possibly come from the Python camp because the latter is actually too dynamic and ill-defined ("Python is what CPython does") and making Python run fast while ensuring 100% compatibility with its existing ecosystem, without putting further restraints into the language, is akin to a mirage.
An industry standard nobody wants to use in the industry is not a standard, it's a 'tentative' one at best.
Simply put, the patent groups behind HEVC got so greedy, far more than they had been with h264, that this thing is pretty much dead on arrival. The only consumer facing company that's still pushing for it is Apple. Everyone else has joined an alliance to come up with a replacement open codec, AV-1, which includes companies such as : Google, Microsoft, Mozilla, NVIDIA, AMD, Intel, Cisco, Amazon, Netflix, ARM, Adobe, the BBC, Broadcom, Realtek.
There is no backing your term of HEVC being an 'industry standard' other than it being supported by the MPEG group. But MPEG group standards were industry standards because people adopted them, not because the MPEG group in itself has some divine providence given power to call everything they make a 'standard'.
When the fight for which video codec should be 'the standard' was about WebM vs h264, h264 won and became a true standard not just in name but in practice because it was welcomed by every major company, while WebM was mostly pushed and cared for by one (Google), so Apple could get away with not supporting WebM in Safari and showing hostility to more open formats. This time it's not going to happen. HEVC on the web is not going to happen, at all. AV-1 is the only thing that could succeed H264.
I've personally never had any problem stemming from the lower levels of the system ever since Windows 7. Whenever I've seen major bugs on Windows, it was on user space stuff like the profile corruption that breaks the start menu and metro/UAP apps in Windows 10 after the major updates which can be fixed by deleting the user and creating a new one.
Windows also has a more robust architecture where it matters, like the fact that a GPU driver crash doesn't kill the user session (windows can reload that subsystem while keeping the user session running since Vista), whereas it can either kill Xorg or just outright freeze the system on linux. A very useful way to architect the OS, although I've only experienced it on Vista and had more stable GPU drivers from 7 onward.
Not having to deal with Linux's refusal of maintaining a stable driver API and ABI for a start. The number one reason that stops Android from getting updates on smartphones is that hardware manufacturers don't want the burden of constantly making small changes to their proprietary drivers to follow new linux kernel changes, something that they don't have to worry about when they make drivers for, say, Windows PCs.
Even Google's own phones, like the Nexus and Pixel, are stuck because of this. They receive updates faster than non-Google phones, but they do not receive more than 2 years of feature updates (with an additional year of security updates courtesy of Google backporting fixes from newer android builds to the older kernel).
Fuchsia is not going to be burdened by Linux kernel dev policies of constantly breaking APIs and their requirement for driver developers to open source their stuff, obey the kernel coding preferences (like when they rejected AMD's driver because of the HAL) to get them mainlined so that they can finally be kept in a maintained state.
To quote Peter Norvig on the difference between Python and Lisp, but you could apply it to most other mainstream dynamic languages vs Lisp :
> Python is more dynamic, does less error-checking. In Python you won't get any warnings for undefined functions or fields, or wrong number of arguments passed to a function, or most anything else at load time; you have to wait until run time. The commercial Lisp implementations will flag many of these as warnings; simpler implementations like clisp do not. The one place where Python is demonstrably more dangerous is when you do self.feild = 0 when you meant to type self.field = 0; the former will dynamically create a new field. The equivalent in Lisp, (setf (feild self) 0) will give you an error. On the other hand, accessing an undefined field will give you an error in both languages.
Common Lisp has a (somewhat) sound, standardized language definition, and competing compiler/JIT implementations that are much faster than anything that could ever possibly come from the Python camp because the latter is actually too dynamic and ill-defined ("Python is what CPython does") and making Python run fast while ensuring 100% compatibility with its existing ecosystem, without putting further restraints into the language, is akin to a mirage.