In the data center, where power (and cooling) are the only significant OpEx, GaN point-of-load conversion is everywhere. Common as a rack distributed 48V to 12V bus or direct to processor Vdd (2% duty cycle is feasible with GaN thanks to fast on/off times). There was a while where GaN was used as part of the power factor correction for AC to DC in the server power supply, back when passing 400VAC or 800VAC bus around made sense. I think these days it's mostly back to DC buses, and AC-to-DC is all happening farther back, in part because of widespread solar deployments and trying to avoid DC->AC->DC double conversion losses when possible. So maybe GaN gets use on active secondary rectifier in the bus -> 48V now too.

The problem with Chinese semiconductors isn't performance or meeting specs, at least not these days. It's counterfeits, life expectancy of the source companies, and the obvious risk of basing your supply chain on a foreign political actor that can leverage this dependency against you.

Setting aside that approximately no one is shooting down quadcopters with missiles, that quadcopters and missiles are entirely different categories of weapon with substantially different range/payload/response time targets, and that the availability logistics and acceptable failure rates of paramilitary gangs and impoverished former Soviet belligerents from whom we are likely drawing conclusions about drone warfare economics are maybe just a step or two below the average US military procurement contract requirements; and charitably interpreting your argument as a generalization that repurposed consumer-grade electronics offers a cost reduction over military-grade selections for equivalent performance: true in most modern cases. The US has plenty of cheap domestic options for seemingly pricy problem domains, just ask SpaceX. SOTA in aerospace and defense routinely uses commercial products to great effect. To the extent that shelling out for a $60 military-grade 1960s transistor instead of a $0.06 commercial equivalent is a problem for the US military, it is downstream of enormous legacy cold war capital investment in technology that was novel for its time but is comparatively brittle by modern standards. This is still a problem, to be clear, but a small one in the grand scheme of US military spending.

Modern IC ESD protection is very effective against a few moderate energy events distributed on different pins, and there's a few industry standards that help determine the required amount of caution for dealing with a particular IC (HBM or human-body model, and CDM or charged-device model, are common - targeted toward human assembly procedures and things like triboelectric or inductive charge buildup). In the right climate, a single high energy event is sometimes enough to degrade functionality or (rarely) completely destroy the device, so board assembly and semiconductor manufacturing facilities still require workers to use wrist straps, shoe grounders, mats, treated floors, climate control, etc. Some high voltage GaN work I did years ago required ionizing blowers (basically a spark gap with a fan) because GaN gates are easy to destroy with gate overstress, and there are risks involved with unintended high voltage contact with typical ESD protective solutions. In another embedded-focused lab, the only time I've ever seen someone put on a wrist strap was for handling customer hardware returns. It really depends what you're working with, and in what environment.

I've more frequently (once or twice a year) had devices which exhibit symptoms of something being wrong at the inputs or the outputs, but only on a specific pin or port. For outputs, some symptoms include the output slew rate is inadequate, or the output appears stuck sometimes, or the output has higher than expected voltage noise (though this is a non-exhaustive list). For inputs, the symptoms are more complex - sometimes there's a manifestation at the outputs for amplifiers or other linear circuits, but for feedback systems or digital systems they might behave as though an input is stuck, toggling slowly, etc. which is difficult to distinguish from other, more common errors. I've also directly been the cause of several ESD failures, but in these cases the test objective was to determine the failure thresholds for the system, so I'm not sure that counts.

I've had a customer hardware failure that was eventually traced back to electrical overstress damage on a single pin of an IC near the corner of a board, right where someone might put their thumb if they were holding the board in one hand. In the absence of a better explanation, I suggested this was an ESD failure due to handling error. I never heard about it again, which is weak evidence in favor of a one-off ESD event.

F-strings are great, but trying to remember the minute differences between string interpolation, old-style formatting with %, and new-style formatting with .format(), is sort of a headache, and there's cases where it's unavoidable to switch between them with some regularity (custom __format__ methods, templating strings, logging, etc). It's great that there's ergonomic new ways of doing things, which makes it all the more frustrating to regularly have to revert to older, less polished solutions.

I've also always had an admiration for the Falstad circuit simulation tool[0], as the only SPICE-like simulator that visually depicts magnitude of voltages and currents during simulation (and not just on graphs). I reach for it once in a while when I need to do something a bit bigger than I can trivially fit in my head, but not so complex that I feel compelled to fight a more powerful but significantly shittier to work with IDE to extract an answer.

Schematics work really well for capturing information that's independent of time, like physical connections or common simple functions (summers, comparators, etc). Diagrams with time included sacrifice a dimension to show sequential progress, which is fine for things that have very little changing state attached or where query/response is highly predictable. Sometimes, animation helps restore the lost dimension for systems with time-evolution. But beyond trivial things that fit on an A4 sheet, I'd rather represent time-evolution of system state with timing diagrams. I don't think there's many analogous situations in typical programming applications that call for timing diagrams, but they are absolutely foundational for digital logic applications and low-level hardware drivers.

[0]: https://www.falstad.com/circuit/

Key things that need to improve: - Documentation appears to have gotten better in the last few years, but still many sparse or underdocumented corners. This is my biggest reservation today. - When I last used it (a few years ago), a lot of things weren't fully implemented - maybe this has changed? But it added a lot of friction.

Instead, I've been told a half-dozen times that there's a new cross-platfotm GUI option, and had I bought into any such endeavor, I would have been rugpulled by sudden deprecation or loss of focus. I think people who did buy into any cross-platfotm GUI frameworks from Microsoft in the last ten years are justifiably feeling like they've been hung out to dry, sometimes multiple times.

I don't complain about Elixir, Ruby, Go, or Rust GUI development because I don't try to use these languages for GUI development, because their core leadership and marketing doesn't promote this as one of the primary use cases. C#, and the .NET ecosystem at large, are THE premier Windows GUI development tools. When their marketing pivots to cross-platform GUI development, and they rugpull you a half-dozen times in a decade with half-finished and baffling experiments, it kinda smarts.

Most people developing desktop apps are probably okay with switching to web-based options, including potentially running their own standalone rendering executable on top of a web view or chromium instance. But there's a significant minority that are building desktop apps because they want better performance and native visual integration/theming, who don't benefit from browser process isolation and the hairy JS event loop situation, who don't want to serialize every user action in the GUI, who saw what XAML set out to accomplish (GUI style templates that convert to framework code that could equally be hand-written, modified, or extended) and ran marathons with it. Maybe this will get better with WASM improvements in the next few years, but it doesn't change that the approach to GUI design is fundamentally different, and in a lot of ways needlessly harder, when you have to pretend your GUI isn't all running on the same machine.

UWP left behind a shockingly large number of perfectly serviceable pieces of WPF, at a time when the emergent UI experience on Windows 8 was being written off by almost everyone, Windows Phone was DoA, and people were starting to realize they could just write web pages and run GUIs in the browser instead. It's been a long, bumpy, downhill ride ever since. The fact that Electron.NET and Blazor is a serious UI suggestion from Microsoft these days should tell you everything you need to know.

I'm sure with enough effort it's usable and maybe even nice in some ways. I did some proof-of-concept work with it two years ago and got maybe 50% of the way to where I wanted to be in 8 hours, but got stuck at styling issues for which there was limited documentation. In the end, I'm more confident these days in WPF + Avalonia if I really need cross-platform - even if there's comparable bugs and limited documentation, there's at least some momentum still behind the project. UWP, all three busted half-finished versions of WinUI, MAUI, Blazor + Webview2, Blazor + Electron.NET... even Avalonia, thanks to the weird decision to change styles to behave more like CSS... it all still struggles to be as usable as WPF.

If Google has a compelling-enough business case, existing fabs will happily allocate space for their hardware. TPU is not remotely compelling enough.

[0] https://www.untrammeledmind.com/2018/02/so-his-brains-just-s...

Integrated circuit manufacturing scales well because the cost per transistor is lower with every process improvement, so as process improvements accumulate, more value (or perhaps more productivity) per wafer is created. This strictly applies to digital circuitry - most analog circuitry requires a certain geometry or process technology not available on a massively optimized modern digital process. While some analog technology improvements are made, it's at a much slower pace. Moreover, a lot of analog redesigns come about as a means to abandon older, less cost-effective semiconductor technology - so the argument that cheap older tech is a boon to any industry outside of limited volume and high cost R&D is suspicious.

Solar cost improvements are in large part a function of massive economies of scale coupled with cheap manufacturing costs and government subsidies from the primary country of origin (which country? Take a guess). I'm sure there's been improvements in a handful of solar material designs, but if you make a large enough volume of panels in a country with cheap labor and massive government subsidies, costs go down. It's not rocket science. To the extent that modern semiconductor technology has improved solar, maybe an argument can be made for improved digital inverter controllers and for silicon carbide FETs maturing enough to make high-voltage panels efficient and ubiquitous at grid-scale deployments. But it's mostly volume, cheap labor costs, and government subsidies.

I don't know about biotech. The following is speculation. I think a lot of biotech was feasible 25 years ago in terms of manufacturability of microfluidics or molecular identification circuitry; but the cost of mass manufacture, and particularly the compute requirements to quickly recover signal from a highly noisy process, wasn't economical or simple to build until digital signal processing and general purpose compute became cheap and fast enough to integrate alongside the biosensors, often as copackaged modules, or generic coprocessors (ARM, RISC-V, etc) that can be built on a ton of different processes and which export raw sensor data quickly enough to allow much heavier duty professors to do the bulk of the work.

I think actual fabrication tech improves slowly, because at its core it's chemistry and material science which also improves slowly (see: batteries). Digital circuitry is a mind-blowing exception, thanks to the incredible amount of usable abstractions that can be built from the manufacture of two specific transistor recipes. But digital circuitry is so powerful, it becomes possible to abstract away massive chunks of otherwise difficult problems in software, firmware, or dedicated transistor-level algorithm implementations, which reduces the amount of physical-world improvements needed to make useful innovations.