> Your approach results in, for example, a developer familiar with a single or very few languages being able to develop across multiple domains using the same l

> Your approach results in, for example, a developer familiar with a single or very few languages being able to develop across multiple domains using the same language regardless of whether it is appropriate for that domain. Basically, using only a hammer to build a house. Sadly this statement describes the current environment. It's hard to find a desktop application today that isn't written using Electron or a similar Web engine for the GUI layer. Not only is it more fiscally efficient for businesses to consolidate their engineering skill sets, but it reduces the technical liability that needs to be tested. That said, Electron sucks - so why don't companies use native GUI libraries? Because they are hard to use and unstable (Windows WinUI is a great example). An abstraction layer to offer a stable consistent GUI API ensures applications are stable while the burden of maintaining stability rests with the abstraction. > Or hire a mix of developers with different skillsets to achieve better quality? If we look at the mobile ecosystem as a case study, apps which are available on Android and iOS are most often build with a UI abstraction like React Native or Cordova (WebView/WebKit). Seldom are native apps for both platforms developed. This is for various reasons - anecdotally my previous employer had dedicated iOS and Android teams comprising of 1 person on each team. We had roles open for 12 months, then the Android developer left so the iOS developer had to learn Android development. They managed to hire a new Android engineer after 18 months. Overall - if making a UI for all operating systems was as easy as consuming a crate/package into your Rust or Go project and building a UI - we would see a lot more efficient native applications.