Hacker News

points by accurrent 16 hours ago | 0 comments

A huge pain of desktop development is managing dependencies particularly if you are coming from C++/Native code. Imagine you wanted to make a simple app in the 2010s that accesses the webcam for instance: If you use chrome you got the full html5 runtime, whereas with other tools you'd need bespoke libraries which your end user may not have.

The only way to ship the same code between linux, macOS, and Windows would have been to either use something like Qt or the JVM back in the 2010s. The JVM desktop stuff was super ugly and Java itself had become notorious (also if you wanted anything remotely interesting like webcam/microphone or multimedia access you'd still have to ship dynamic libraries). Qt required special packaging skills to ship to the end user especially if third party libraries were involved. Electron killed that by bundling chrome (and chrome has a huge api surface).

Today, I would argue the package management situation for a language like rust is a lot different. You dont have to cobble different DLLs together, you can just statically compile dependencies and cargo/rust do a pretty good job of making sure it's bundled with your app. Other languages also now have similarly useful tools.

[–] saagarjha 1 hour ago

Discord ships plenty of native code, though. Actually most popular Electron apps do

[–] 72deluxe 15 hours ago

But then the C++ libraries you mentioned also had the ability to statically link into a binary, which means you could statically link the webcam access in, in your example. So I don't see the advantage you're arguing for?

[–] cogman10 15 hours ago

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.

[–] bluGill 5 hours ago

A cross platform webcam library isn't that hard to build at C++. I mean, it's tedious, and having to support multiple different operating systems makes it harder, so it certainly is going to cost a small pile of money, but this is not hard. The pile of money needed won't be all that large. Mind you, I prefer to use something that's off the shelf rather than writing my own, but it would not be hard to write my own.

The hard part of all webcam libraries is all the different webcams running all their different proprietary protocols.

[–] MindSpunk 10 minutes ago

Write the code or build the code? That's always the problem with C++ libraries.

It's not that difficult to write cross platform C++ code. Consuming the dependency is always painful. What build system does it use? What compilers does it support? How do you get the code? There is 0 standardization for these things.

C++ code isn't always that portable either. Old code in a new compiler is very likely to break on warnings, especially if the old code made the high quality decision to hard code -Werror in their build system.

From personal experience Rust as a package and ecosystem is far more portable than C++.

[–] pjmlp 9 hours ago

Qt is easily obtainable via vcpkg or conan.

[–] edoceo 9 hours ago

Was that true in 2012?

[–] pjmlp 9 hours ago

Depends, it was easily obtainable via OS package managers, and installers in 2016.

However that has been true since 2016, and here we are, 10 years later.

[–] justincormack 8 hours ago

For Linux, but not for Windows and Mac

[–] Krutonium 9 hours ago

Very yes.

[–] bluGill 5 hours ago

Neither existed in 2012, so of course not. On the other hand, QT has always been really easy to download from QT. I don't remember who owned QT in 2012. They've changed hands a couple times over the years, but in 2012 I was downloading QT from whoever on them. QT was large, so you needed a decent sized computer to build it, but in 2012 this was not a big deal.

People get too hung up on package managers. When you're building your own proprietary you don't really need a package manager, you just need a central place to download the tarballs from. Or you could do a monorepo and just build everything locally - in 2012, that means you start your build before you leave Friday afternoon, and when you come back Monday, everything's built.

[–] jasomill 12 hours ago

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.

[–] vrighter 3 hours ago

you can do that easily on linux too

[–] cosmotic 13 hours ago

Java desktop was only ugly if you chose for it to be. It was pretty minimal effort to get native look and feel. Nothing built in electron looks native. If we're accepting custom interface using electron, that was doable with Java too.

[–] NetMageSCW 6 hours ago

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

[–] dingaling911 3 hours ago

Eclipse

[–] cyberax 20 minutes ago

It used SWT, which was a thin wrapper over native controls.

[–] sdthjbvuiiijbb 3 hours ago

I haven't used Eclipse in a decade, so maybe it's changed, but back then it was very much a Java UI, not a native feeling one.

[–] dingaling911 2 hours ago

I remember the Java UI, but at some point they switched to a version of Swing that made it look more native, at least on Linux.

[–] threetonesun 9 hours ago

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.

[–] johnny22 3 hours ago

I much prefer vscode to intellij

[–] pjmlp 9 hours ago

Long time ago, Apple had a proper OS X Swing L&F, when you could do Cocoa in Java, and there was still some uncertainty if Objective-C would be embraced by Mac OS development community.

[–] pjmlp 10 hours ago

Usually it is hard for those coming from scripting languages.

Strangely enough we managed to write portable code across platforms during the last century, and there were more than only three major desktop OSes.

[–] vivaldi_bt 6 hours ago

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.

[–] skydhash 7 hours ago

> 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/

[–] Barrin92 3 hours ago

>Qt required special packaging skills to ship to the end user especially if third party libraries were involved

How outrageous to demand that a software developer possesses the 'special skills' to ship a Qt application. It's not surprising that people think AI is killing programmers when this is the level the average 'programmer' has been operating at for 15+ years.

Imagine going to a chef and he tells you he can only warm up microwave lasagna because cooking the steak correctly requires special skills. The special skills are your job