chiefsucker
C++ & apps don’t fit well together technologically these days.
Android? Go Kotlin.
iPhone? Go Swift.
Cross platform? Meh, kind of dislike middleware as they always lag behind the vendor. This was the case three decades ago as it is today.
Usually you are far better off by defining a REST API as your border between platforms, then just use whatever easy (de)serialization techniques the language will give you.
Personally I have a cross-platform C++ stack built on top of Drogon that I can use on multiple platforms, then it’s usually a native UI layer (Kotlin + Compose on Android, Swift + SwiftUI on Apple platforms) on top of the cross-platform layer. This way business layer code can be shared across every platform while only the UI needs to be adapted to its host OS.
Drogon website: https://drogon.org
But when you build a Hackintosh with a recent version of macOS this exact TRIM behavior results in boot times of several minutes (compared to a dozen of seconds or so on a SSD with a better TRIM implementation).
I’m not saying Samsung will ever fix their TRIM implementation, but in theory this would be fixable by a firmware update.
And don’t get me even started on the crap that TRIM is, why we shouldn’t need it in the first place, and how convoluted its development was.
You just define the outcome together with your client, and use C++ if it’s a technological fit.
What works excellent (at least for me, not necessary for you) is to set shortcuts to your most used applications (be it the function key row, or some hjkl combinations). With such a setup you can just press a key / combination from muscle memory, instead of opening the tab switcher overlay, parsing it, deciding how often you need to press tab, and then actually switching to the other application window. Keeping shortcuts to applications feels like you would only have to do the last step.
Not everything is a numbers game.
Maybe the author is a very engaged developer who already knows a huge part of the “boring software that supports the world”? Maybe he is so engaged that he wants to follow new developments in his professional area to get even better? Maybe he hopes that he will discover new and interesting algorithms that can help him improve his skills?
I think there is a point that simple algorithms are a better user interface, because of their predictability (although they show their flaws, like he specifically mentions with JS). Just try to remember how much discussion there was about Twitter’s feed and their move away from a classic timeline. They still haven’t abandoned the latter one.
But who knows in the end? Maybe your comment was just an attempt of satire a la The Onion? Personally I try not to prematurely judge and stay positive. To each his own I guess.
You don’t have this issue at all for domains that don’t have a www subdomain.
Furthermore it would be extremely confusing to have different content for www.example.com & example.com.
This actually splits developer mindset into two camps: those who love the introduction of new stuff and deem it necessary to achieve progress, and those who accuse Apple of planning obsolescence into their products, and deprecating technologies too early (it’s a little bit hard too believe when you compare Android to iOS, but Linux or Windows vs. macOS tells a different story).
When you’re on it, also install Vimac [1]. I’ve mapped it to ⌃Space (similar to Spotlight’s ⌘Space). It’ll make you grab the mouse / trackpad less often.
It’s definitely great that such an architecture worked for you and also shows how hard it can be to run a full OSS stack these days.
I’m not sure I understand this, i. e. TRANTOR (which is the underlying network library for Drogon) recently merged in a patch that optimizes memory handling in a low level component of its event loop where object construction was minimized (first tests show another performance increase of about 5–10% on top of the current benchmark results).
I fail to understand how such improvements have something to do with “all the latest methods and libraries”?
What makes you say that Drogon isn’t pleasant to work with? Is it some specific framework APIs that can be improved (if yes, how?), or is it a general disdain against C++ and its syntax?
It looks like this: https://imgur.com/a/FqLB0g8
It’s pretty easy to take Apple’s HTTP implementation, add a router, integrate a template engine and have something working, but then the real issues start, because the ecosystem and community just aren’t there.
And just a minor nitpick, Apple’s development environment is called Xcode, where just the X is written uppercase.
As things currently are you are better off with C++ on the server than with Swift. This is how bad things in reality are.
I could imagine a micro-service here or there where Swift is involved in some kind of bigger enterprise architecture, or as a hobby project, but the ecosystem, the libraries, the documentation, and the community just aren’t there yet.
It’s pretty easy to take Apple’s HTTP implementation, add a router, integrate a template engine and have something running, but I don’t see a reason for this in a professional environment, and I still don’t see Apple as the company who will push a technology that isn’t directly bound to their hardware.
I used Gentoo as my main OS for multiple years over a decade ago, installed it a couple of times, and helped with the localization of several documents, but I still remember the installation being basically the same as it is now.
I’m honestly wondering what is meant by this statement?
I also have a bug with their hardware keyboard. After a couple days of usage the keyboard can get unresponsive and the § key starts to magically appear in the next text field that gets focus, at least 10–20 times, as it would be stuck. Reconnecting the hardware keyboard usually fixes this issue, but it’s still annoying. The restarts that are required for software keyboard bugs are worse, though.
https://store.flokk.com/us/en-gb/products/hag-capisco?store=...
This rewrite isn’t only related to the current situation on Linux, but also to Swift’s current performance characteristics. Lack of full Linux support is just another hindrance, before you can consider Swift for this type of work at all.
Statements like these don’t necessarily speak for the user-friendliness of Rust or Rust itself. Safety? OK, cool. But for what cost?
The Apple ecosystem slowly gains new frameworks like SwiftUI that simply don’t work with Objective C anymore. The platform is abandoning one language similar to Microsoft and their VB story. It will take a long time, but AppKit & UIKit will end similarly to how Carbon ended on macOS.