5 ms·

Recently worked at a company doing similar to this to support Windows and macOS. To add to the difficulty, they used Chromium as a UI front end much like Elect

Recently worked at a company doing similar to this to support Windows and macOS. To add to the difficulty, they used Chromium as a UI front end much like Electron. All built in house though. They hired me as a JS/HTML/CSS dev, but same as the article states, the C++ work was the true bottleneck. They knew I had some C++ chops and set me to work doing C++ with a sprinkle of JS here and there. Due to incompatibilities in the compilers, there was a rats nest of dependencies, thousands of #ifdef’s to cover differing OS implementations, and we had to use some of the oldest versions of C++ to be compatible with both XCode and Visual Studio. As the article states, we had custom background job libraries and debugging them was a nightmare. Also similar to the article, we spent more time than one ever should setting up builds to handle our ludicrously complicated build configurations. And lastly, as the article stated, we had a hard time finding new talent to cover the growing amount of work required to deliver our product. There just aren’t many C++/JS devs out there.

shaggyfrog 7y ago
> And lastly, as the article stated, we had a hard time finding new talent to cover the growing amount of work required to deliver our product. There just aren’t many C++/JS devs out there. Reading the article and now this, I really can't grok this perception. There are plenty of us out here, I think, it's just we're buried in the heap caused by mass resume farming, aka modern recruiting. Recruiters and hiring managers don't think of me as a senior dev with 15 years writing software and delivering value to end-users... I'm just YA candidate who doesn't have any experience in the latest JS framework du jour, so I might as well not exist.
- softfalcon 7y ago
  Addressing JS, they were using aging jQuery with other vanilla JS. Nothing fancy. As for finding people like yourself, all I kept hearing was that they had trouble finding new people to fit their specific needs. I agree with you though, there is likely a lot of missed opportunities due to the resume farming going on and bad filters.
ben-schaaf 7y ago
> Due to incompatibilities in the compilers, there was a rats nest of dependencies, thousands of #ifdef’s to cover differing OS implementations, and we had to use some of the oldest versions of C++ to be compatible with both XCode and Visual Studio. My current work has me on a single C++ code-base for Linux, Windows and MacOS (not electron though, just native). You can avoid a lot of headaches by avoiding the platform specific tools and instead cross compile using clang with a build system that works on all platforms (eg. ninja + meson).
- lstamour 7y ago
  +1 for Clang. It integrates with everything. But like most open source options, it plays second fiddle to each company’s primary languages, and so thee’s no one IDE so perfectly integrated into these mobile dev C++ use cases as to make it easy to work with, the way, say, you can be productive on .NET framework with either C# or C++. Google and Apple are both C++ compatible, or have native bindings, but... they target their examples and ease of use at the languages that best integrate with the respective IDEs. (Swift for Xcode, Kotlin for Android Studio) The end result is possible, but it’s like picking Cordova/PhoneGap/Electron for your native app. You’re going to struggle to use native technologies at some point, and there are few examples to follow. Allowing for the realization that 80% of your app code is likely platform-specific even if the UI doesn’t vary much means you can adopt new approaches and native UI conventions faster. It’s like the difference in programming speed when you simply target Chrome for your web development vs when you’re trying to write code that runs on Internet Explorer also. It’s getting to the point where platform functionality diverges so much that writing it but from the same design/spec/data model is faster than trying to maintain compatibility. Especially if you need to support multiple versions of iOS and Android in a backwards compatible way and with different UI conventions in different OS releases. Native is native, nothing else looks or feels like native, when that’s what you need, and there’s more hand-holding for apps when they follow the latest spec from the platform, rather than try to chase it with their custom bindings/implementation... Note re. targeting a platform — often learning and reading some C++ is inescapable. For me, reading Chrome source code makes it easier to work with Puppeteer in JS, or deliver a better web app because I know how things work under the hood and it’s easier to read the C++ than the read the web standards themselves. Similarly, C++ really is portable and fast, so it shows up in many places. But on mobile, the mix of C++ to Swift/Kotlin should be 90%-platform native if your app is a traditional CRUD app that deeply integrates with the platform. If it’s simpler than that, build a website, or if it’s a game engine or some custom UI, use that, sure, but if you want to benefit the most from Apple and Google implementations, native (with shared spec/data models) is the way to go...
WoodenChair 7y ago
I'm currently working on some code that is for VS/Windows, Clang/macOS, and GCC/Linux. I'm just setting the std to C++17 on all of them with no extensions. I have had some warnings that have sprung up on some platforms, but not others. But I haven't run into any show-stopping incompatibilities for vanilla C++17. What should I be looking out for? Or was this a matter of using different standards on different compilers?
- softfalcon 7y ago
  First of all, agree with your decision to use C++17. Great idea! However, in our case (like with many C++ code bases) the code was almost 20 years old. Even with the Herculean efforts made by the teams to keep the code base up to date and refactored, you run into issues of backwards compatibility with older libraries. C++17 is definitely the go to for new projects! However, I've never personally worked on a pure green field project written in C++ that didn't have to latch onto some older libraries that require older C++ std versions.

shaggyfrog 7y ago

> And lastly, as the article stated, we had a hard time finding new talent to cover the growing amount of work required to deliver our product. There just aren’t many C++/JS devs out there. Reading the article and now this, I really can't grok this perception. There are plenty of us out here, I think, it's just we're buried in the heap caused by mass resume farming, aka modern recruiting. Recruiters and hiring managers don't think of me as a senior dev with 15 years writing software and delivering value to end-users... I'm just YA candidate who doesn't have any experience in the latest JS framework du jour, so I might as well not exist.

softfalcon 7y ago
Addressing JS, they were using aging jQuery with other vanilla JS. Nothing fancy. As for finding people like yourself, all I kept hearing was that they had trouble finding new people to fit their specific needs. I agree with you though, there is likely a lot of missed opportunities due to the resume farming going on and bad filters.

ben-schaaf 7y ago

> Due to incompatibilities in the compilers, there was a rats nest of dependencies, thousands of #ifdef’s to cover differing OS implementations, and we had to use some of the oldest versions of C++ to be compatible with both XCode and Visual Studio. My current work has me on a single C++ code-base for Linux, Windows and MacOS (not electron though, just native). You can avoid a lot of headaches by avoiding the platform specific tools and instead cross compile using clang with a build system that works on all platforms (eg. ninja + meson).

lstamour 7y ago
+1 for Clang. It integrates with everything. But like most open source options, it plays second fiddle to each company’s primary languages, and so thee’s no one IDE so perfectly integrated into these mobile dev C++ use cases as to make it easy to work with, the way, say, you can be productive on .NET framework with either C# or C++. Google and Apple are both C++ compatible, or have native bindings, but... they target their examples and ease of use at the languages that best integrate with the respective IDEs. (Swift for Xcode, Kotlin for Android Studio) The end result is possible, but it’s like picking Cordova/PhoneGap/Electron for your native app. You’re going to struggle to use native technologies at some point, and there are few examples to follow. Allowing for the realization that 80% of your app code is likely platform-specific even if the UI doesn’t vary much means you can adopt new approaches and native UI conventions faster. It’s like the difference in programming speed when you simply target Chrome for your web development vs when you’re trying to write code that runs on Internet Explorer also. It’s getting to the point where platform functionality diverges so much that writing it but from the same design/spec/data model is faster than trying to maintain compatibility. Especially if you need to support multiple versions of iOS and Android in a backwards compatible way and with different UI conventions in different OS releases. Native is native, nothing else looks or feels like native, when that’s what you need, and there’s more hand-holding for apps when they follow the latest spec from the platform, rather than try to chase it with their custom bindings/implementation... Note re. targeting a platform — often learning and reading some C++ is inescapable. For me, reading Chrome source code makes it easier to work with Puppeteer in JS, or deliver a better web app because I know how things work under the hood and it’s easier to read the C++ than the read the web standards themselves. Similarly, C++ really is portable and fast, so it shows up in many places. But on mobile, the mix of C++ to Swift/Kotlin should be 90%-platform native if your app is a traditional CRUD app that deeply integrates with the platform. If it’s simpler than that, build a website, or if it’s a game engine or some custom UI, use that, sure, but if you want to benefit the most from Apple and Google implementations, native (with shared spec/data models) is the way to go...

WoodenChair 7y ago

I'm currently working on some code that is for VS/Windows, Clang/macOS, and GCC/Linux. I'm just setting the std to C++17 on all of them with no extensions. I have had some warnings that have sprung up on some platforms, but not others. But I haven't run into any show-stopping incompatibilities for vanilla C++17. What should I be looking out for? Or was this a matter of using different standards on different compilers?

softfalcon 7y ago
First of all, agree with your decision to use C++17. Great idea! However, in our case (like with many C++ code bases) the code was almost 20 years old. Even with the Herculean efforts made by the teams to keep the code base up to date and refactored, you run into issues of backwards compatibility with older libraries. C++17 is definitely the go to for new projects! However, I've never personally worked on a pure green field project written in C++ that didn't have to latch onto some older libraries that require older C++ std versions.