chiefsucker

Disclaimer: I am an application developer, and one of the maintainers of the Drogon C++ web framework.

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

The less updates a software gets, the higher is the probability that you’re dealing with abandonware.

Just to give you an example: Some Samsung SSDs have slightly strange TRIM behavior that basically seems to get unnoticed during normal workloads.

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.

Isn’t this already one recursion level too deep? ;)

If it’s about side money, it usually also implies a smaller, side project, not necessarily, but eventually for smaller businesses to whom technological choices don’t matter.

You just define the outcome together with your client, and use C++ if it’s a technological fit.

From my limited understanding not the distance is the problem, but the constant focus at a point in the same distance. That’s the reason why they recommend to look at distant objects every 15 minutes or so. Starring at a tree for ten hours straight would have a similar effect, but woods are so complex that your eyes are constantly refocusing.

Tab cycling can be a productivity killer, especially when you need to cycle between more than 4–5 applications (which can happen quite often, but OP wrote “alt-tab (or otherwise)”.

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.

I also don’t mean to pick on you personally, but do you think that 8x as stupid is better than 4x as stupid?

Not everything is a numbers game.

It’s really fascinating how humanity can twist almost everything around and start seeing it from a bad perspective.

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.

This is patently false. I talk to non-tech "regular" users all the time that don’t know what I’m talking about when I mention AMP and its issues.

A common convention with system administrators is to have the canonical name at www.* and redirect www-less requests to the former. If you argue that a browser implementation should fix uncommon configurations, I would argue that administrators should fix their configurations in the first place.

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.

What the heck? A regular user doesn’t understand or care what the technical difference between a “regular” page and AMP is. I wouldn’t call this ignorance per se.

To have a monopoly doesn’t mean to have a specific market share, it means to show monopolistic behavior.

Apple wouldn’t be Apple if they wouldn’t abandon old technologies in favor of newer ones.

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).

+1

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.

[1] https://github.com/dexterleng/vimac/

AWS doesn’t necessary sound like OSS, but to each his own ;)

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.

"whatever is the latest framework can take advantage of all the latest methods and libraries to become the fastest"

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”?

One of Drogon’s project goals is great performance. That’s also one of the reasons why it’s written in C++.

For example, https://github.com/an-tao/drogon (benchmark winner) or https://oci-pronghorn.gitbook.io/greenlightning/ just aren't pleasant to work with.

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?

Yes, exactly. When I need HN in dark mode, I open a pre-configured Terminal profile with w3m launched by default, and have a nice greenish font on a dark background.

It looks like this: https://imgur.com/a/FqLB0g8

Huh? Apple provides an example implementation at https://github.com/apple/swift-nio and I would say it’s straightforward to “get up and running”.

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.

It may be tempting to go the middleware route, but whenever I worked with middleware I had completely unrelated issues to the underlying framework which either complicated matters, or made it impossible to fix specific bugs. Then there’s the issue that Apple has a pretty aggressive release schedule. For a middleware maintainer it takes pretty long (compared to Apple’s native solutions) to adapt to these changes (I’m thinking about things like the notch on the iPhone X and safe areas). Apple’s secrecy about their upcoming release schedules doesn’t help, but it’s just how things are.

And just a minor nitpick, Apple’s development environment is called Xcode, where just the X is written uppercase.

I understand the author’s perspective on the topic, especially from where he’s coming from, but I’m less excited for Swift on the server.

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 use the “Emacs Mac Port” which is available via Homebrew.

https://github.com/railwaycat/homebrew-emacsmacport

Didn't really occur to me that the installation experience is completely different these days, but that makes sense.

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 this bug, and a couple more. When you use the smaller floating keyboard at some point the keyboard starts to jump to the lower left corner. Swipe to type doesn’t work anymore.

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.

If you want something minimalist I can recommend the HÅG Capisco. It looks a little bit weird, but is really comfy once you get used to it. The chair supports active sitting which means you won’t sit in one position for eight hours straight, instead the chair will invite you to move around and try out other seating positions which will inevitably lead to more movement and stronger muscles.

https://store.flokk.com/us/en-gb/products/hag-capisco?store=...

It’s only supported on Ubuntu, not Linux in general, and it still lacks. The corporate backing is missing, and IBM going away from the Server-side Swift deal doesn’t spread confidence. The whole ecosystem just isn’t there (yet?).

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.

It is obvious the author has little to no experience in developing production software in Rust.

Statements like these don’t necessarily speak for the user-friendliness of Rust or Rust itself. Safety? OK, cool. But for what cost?

Using a frozen language isn’t the real problem here, though.

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.