It comes down to package distribution.

Chrome had already solved the hard problem of "how do we support webcams on linux, windows, and mac" and you as the dev just needed to use the Javascript webcam api. ( https://developer.mozilla.org/en-US/docs/Web/API/MediaDevice... )

In C++ land, you are ultimately going to either need to cook up your own webcam library or look for a 3rd party (which, in 2010, likely didn't exist) to provide it.

Today, there are a few easy to discover rust crates which provide cross platform webcam apis. But further, rust does cross platform better than C/C++ IMO. It's really easy to change how code is compiled based on the target. That was all well thought out because rust was supposed to be a language for browsers.

Dynamic vs static linking is mostly a red herring for desktop GUI application development unless you want to integrate into something like Linux distro package managers, as dynamic libraries on Mac and Windows can be self-contained within the application bundle/directory with no disadvantage beyond marginally longer startup time, and you can do similar things with Flatpak and friends on Linux.

The real difference is that Rust provides a package repository with a unified build system that's as simple to use as NPM or NuGet.

vcpkg which is similar exists today, but it didn't in 2015 when Discord started, still isn't anywhere near as comprehensive as package repositories for languages where package management is part of the standard toolchain, and the underlying build systems are far messier under the hood.

It can also be helpful in development to use libraries built from source as part of the application's build process, at least as an easily-accessible option, which wasn't common practice in most C/C++ ecosystems historically where different libraries used different build systems and if you wanted to integrate them into something like a Visual Studio solution for easy reference to source code during development and debugging you were often on your own.

IIRC Qt is LQPL, so if you linked it statically you'd have to license your code as LGPL too. Shipping Qt as a separate dll didn't trigger that issue.

JetBrains IDEs arguably look/behave better than VSCode as far as a native app goes. I wouldn't say either look great on MacOS but a truly "native feeling" Mac app is usually quite different than a Linux/Windows equivalent.

Why is it no one ever seems to do it then? I have never seen a Java app look or act native on Windows.

They had native looking skins for Swing that still felt slightly off and behaved differently. Netbeans IDE looked nice, but it was weird in subtle ways.

I never really understand this attitude. It isn't really hard it took one or two evenings to understand how native libraries work and you close this problem forever.

> Strangely enough we managed to write portable code across platforms during the last century,

Yep, that argument always seems strange too me. Do people fear that much to design their own interface and hook to each platform ecosystem? You look at something like the BSD which runs brought one single kernel concept and various subsystems across a variety of hardware. And somethine like libao[0], which provides a common interface to various sound system.

Whatever the app, if you care enough, you can abstract the core features away from the GUI and other various dependencies.

[0]: https://xiph.org/ao/

Probably an economical thing. If you have a much higher effort with packaging and testing vs coding the app logic.

If developers don't want to be replaced by AI they need to bring something to the table because employment is not a charity.