I suspect that heavily optimised code either uses intrinsics or carefully written assembler code.

In order to dig deep into one area, you might need to take on a "hobby" project that forces you to deep dive in a chosen area. Looking at your current areas of experience, I would choose either GPU or DSP programming. By being CPU adjacent areas, specialist skills are more likely help your career.

Yank out the power cord. Go outside and experience the reality of nature. It is more humane paced.

Company A buys company B. A's management decrees the henceforth B's aqcuihired team must comply with company A's standards.

Second system effect kicks in. Bugs multiply.

Half of original company B devs leave.

I'm investigating whether future projects should revert to using Deno.

For example, consider an agricultural co-op, e.g. wheat growers. The members of the co-op have farms of differing sizes, use similar techniques, have more or less comparable conditions. They produce grain which has a commodity level set price. The main differentiator between members of the co-op is the volume of grain they produce. But on the basis of the commodity pricing it is a relatively level playing field.

Now consider any tech company. Products have vastly different pricing - ranging from free to millions of $ (or whatever your currency) for enterprise levels. The "producers" vary in capability from newbies to rock-star programmers. Plus you need management to facilitate communications, etc. Everywhere you look, you find disparity.

The closest you get to a tech co-op is a startup with a small group of people who respect one another's contribution and follow a shared vision. Unfortunately as soon as you introduce outside investors inequality seeps in.

A good income is a hedonistic trap if you spend it on booze, cars, babes and parties.

To build an all day running ultra-light would probably require a magnesium case, but magnesium and lithium are both flammable metals. Probably not ideal on an aeroplane. Using more plastic doesn't meet the premium requirement.

I'd guess, unlikely?

Car company execs need to take a chill pill followed by a reality serum. Monetizing subscription based basic features and delivering in-car advertising is the absolutely worst way to go.

As consumers we need to stop buying into the bells, whistles and trinkets and demand essential and safe transportation.

Didn't work too well last time. Will be amazingly effective this time

You just need to recognize that not everybody aspires to be competent with lower-levels of hardware and software that Apple makes that much more difficult. Most Apple users are content to use apps written by others and that is as far as their interest goes.

An analogy is the car market. Most people don't care how the car works, etc. They just want to get to places. If you only need to drive to the shops and do minimal errands, you don't even need a truck - a sedan will do just fine. Same with computers, lots of different market segments with distinct needs and expectations.

Microsoft, as its name implies, started out and cuturally was always a software company. By the time Microsoft started dabbling in hardware it was seen as a competitor by the many software licencees. Microsoft could never control the hardware side of their platform like Apple has.

The other factor is that Apple ditched the proprietary OS and went down the Unix/BSD and derivatives path. MacOS is effectively a FreeBSD derivative overlaid with a custom desktop.

Without a quasi-portable OS at the core, there is no way that Apple could have made the switches from Motorola 68000 to PowerPC to Intel to ARM.

Windows, on the other hand, is running NT which is basically a port of DEC VMS. Didn't work out well for DEC/Compaq/HP.

As I see it, WASM is used to augment the JS/WebAPI ecosystem. For example, when you need to do heavy bit manipulation, complex numerical processing. The round-trip JS->WASM->JS is an overhead. So the WASM modules should perform a substantial amount of processing to offset that inefficiency.

I frequently find that V8 optimisations yield sufficient performance without needing to delve into WASM.

IMHO if you want to write WebApps in Rust, you're holding it wrong.