Coming from writing a ton of Swift (and previously Obj-C), Kotlin’s ergonomics feel kinda off. It also feels like it’s different for the sake of being different more often than I’d like.
Can you give concrete examples? I played with Swift in school after already making the dive into Kotlin. It just felt like Kotlin but trapped on Apple. Part of the program even included a course in using a different language every couple weeks where we went through Scala, Lisp, and some others just to see what they could do.
Currently Kotlin is far and away my favorite language but I also haven't looked into the newer languages recently and am interested in hearing pain points people have. Especially if it isn't annoyances with Gradle
Broadly speaking, Kotlin deviates from popular conventions more than Swift does. For example, Kotlin expects you to use inline if statements where in Swift, ternary operators work like they do in C, JavaScript, and many other languages.
There's also things like Swift's guard statements that can help make intent clearer and read a bit more nicely.
Same opinion. It just feels off. Why use `fun` for function declarations instead of func or function? Dropping () before { makes it hard to tell what runs first. It feels like it's trying to be different for the sake of being different. I'm not able to quickly skim kotlin code like other 'C-like' languages and tell what is going on because it's trying to be too clever.
I think IDE preference leans further towards subjective than many believe.
I find that IntelliJ IDEs are fine, but not nearly as amazing as they're often hyped up to be, and similarly while Xcode has problems it's not nearly as bad as is often claimed.
My experience is somewhat colored by Android Studio and JVM ecosystem stuff like gradle and proguard though, which have been more cumulative pain for me than anything Apple-side in a long time (Cocoapods was pretty gnarly but SwiftPM has fixed that).
Xcode 26.2 is a 2.1GB download, which expands to 8.63GB on disk, which includes the macOS SDK. The iOS SDK and simulators are another 8.38GB. Luckily Xcode versions can share iOS SDKs now, so you only need to install them once. Really the biggest disk eater is Xcode's default behavior of creating a huge set of simulators for every platform.
At 8.6gb of disk usage, they could include the entire macOS Mojave ISO disk image[0] and still have ~930 MB to include fit the IDE. It's just unprecedented.
You’re counting the development SDK against the IDE. Xcode itself doesn’t require that space, and you’d need that space regardless of IDE choice if you were targeting the platform.
Indeed, and unless that changed since, the Mac downloader isn't even capable of resuming downloads properly so if anything happens while you download these 13GB, it's back to square one.
I have a stack of old burned CD-Rs and DVD-Rs with old files, some of which are family photos. Success with pulling files off of them has been mixed. Some of the discs have visible pinholes in the reflective layer and others visually look fine but have scratched up surfaces.
Tooling and documentation for recovering damaged discs is sparse, which doesn't help matters. I've been meaning to try going to a local retro game shop to get some of the discs resurfaced but I'm skeptical that it'll make much difference.
As far as I'm aware those discs contain (or did contain) the only copies of a bunch of those files. There might be some old hard drives or CF cards kicking around the family house but I doubt it and even if there are, they've either since been wiped or have succumb to bitrot.
I don’t agree with this at all. I’ll take AppKit (preferably with Swift, but Obj-C is fine too) over anything web. There’s a number of reasons, but the biggest is that AppKit has an expansive set of well implemented, accessible, flexible, efficient, and ready to use widgets that are all designed to work together, and the truth is that this isn’t something you can get on the web.
Even the most complete “UI frameworks” on the web are full of holes, leaving you to build a patchwork monster out of a laundry list of third party widgets (all of which themselves are full of shortcomings and concessions) or build your own.
As an aside, this gripe isn’t exclusive to the web. It’s a problem with many others such as Windows App SDK (aka WinUI) and Flutter, among others. At least for the things I build, they’re unsuitable at best.
There's one problem: If you're competent with non-web UI technologies, it's probably time to schedule your colonoscopy.
Late millennials and gen Z have been spoiled by declarative, reactive frameworks that work identically whether you're doing a local UI or the Web, and the tools (for example Figma) that have grown up around these frameworks. Using C++, Objective-C, or even Swift will be just fine for a personal project, but if you're talking something that needs to be maintained and refined over the long term by a team, you will have a much worse time finding people competent in those languages than in JavaScript+React+Electron.
This is also one of the reasons behind rewriting everything in Rust: C is so dangerous, people who don't already know it inside and out are unwilling to touch it. Virtually all of the younger system developers are already working in Rust, and would vastly prefer it over working in C given the choice, so keeping a C project maintained has gotten a whole lot harder.
> Virtually all of the younger system developers are already working in Rust
I'd love to know where you get your statistics from.
FYI, as an anecdote, I am 'younger', in the sense of 'only recently joined the workforce', and I write 100+ lines of C and C++ a day, both at work and in side projects. Haven't touched Rust once, although I would like to get into it.
And funnily, the one UI framework I did use at work is Avalonia, which is strongly inspired by Windows Presentation Foundation.
I write plenty of declarative UI too in the form of SwiftUI (where it makes sense; often on Apple platforms the imperative frameworks are better suited) and Jetpack Compose.
Declarative UI has its upsides, but it’s hardly a panacea. There are places where it’s a straightforward dramatic improvement and then others where it’s an awkward contortion at best. Reactivity can be great but works in imperative setups too.
The explosion of popularity of front end web frameworks comes down almost entirely to two things: accessibility and commodity talent. It has a low bar to entry and JS+React is the closest the industry has come yet to achieving its undying dream of cheap, easily replaceable, interchangeable developers. In most other aspects it’s objectively worse than alternatives.
Based on my own personal usage, it makes total sense that RSS feeds still get a surprising number of hits. I have a small collection of blogs that I follow and it's much easier to have them all loaded up in my RSS reader of choice than it is to regularly stop by each blog in my browser, especially for blogs that seldomly post (and are easy to forget about).
Readers come with some nice bonus features, too. All of them have style normalization for example and native reader apps support offline reading.
If only there were purpose-built open standards and client apps for other types of web content…
This is what I use. It’s on macOS too and amazing on both. Super fast, focused, and efficient.
It’s by far the best I’ve tried. Most other macOS readers aren’t memory managing their webviews properly which leads to really bad memory leaks when they’re open for long periods.
iCloud sync is a nice feature too. I use the Mac app mostly for adding feeds and the iOS app for reading. Anytime I read an interesting web post, I pop its url into the app to see if it has a RSS feed.
Same question, but for Android and desktop / laptop too. Never used RSS much before, hardly, in fact, I don't know why, even though I first knew about it many years ago, but after reading this thread, I want to.
Yep. I've even been seeing Chrome TV ads lately (on Amazon Prime Video). They're marketing it pretty hard despite being dominant.
Also, it's wise to not underestimate the power of developers ceasing to test against non-Blink browsers and taking a page from their IE-era past selves with "Best Viewed in Chrome" and "Browser outdated! Download Chrome" badges. There are few user motivators stronger than things not working.
Yep. Chrome's mindshare and momentum is incredibly difficult to overcome, and outside of technology-oriented circles users generally don't develop associations between specific programs and poor battery life unless it gets the fans blaring like you're running Cyberpunk 2077 with setting cranked to max or something.
It's similar to how the overwhelming majority of people driving cars aren't going to make note of the difference in driving dynamics between CVT and automatic transmissions unless one severely underperforms compared to the other. It either runs or it doesn't and that's where the distinction ends for people who treat their car/computer/phone as an appliance.
WebKit's progress has been significant in recent years, it's just been more focused on things like improving CSS instead of things like an API that tells the developer how many beers the user has in their fridge.
You are unwittingly confirming his point. Apple isn't randomly working on random stuff, they know exactly where their bread is buttered - features that have potential of diminishing that butter get skipped, neglected or implemented half-baked.
From my perspective, Google tends to focus on somewhat niche features that will benefit a small slice of web apps. In contrast, the things Apple works on are those that benefit everything from static blog sites to huge commercial web apps.
I wish Google were more like Apple in this regard, because the primitives from which everything web is built are still overwhelmingly crude, which results in the half-ton-truck-built-on-a-golf-cart frameworks and apps the web has become famous for. Making the web reasonable to develop for without a dependency tree that looks like a spiral fractal would do way more to make it flourish as a platform than things like access to the GPU and USB devices.
It’s still got popularity within tech-inclined Mac/iOS circles too because it’s easier on the battery than Chrome (+derivatives) and Firefox. Some would like to switch but because neither Google nor Mozilla has much to lose for their browsers being battery hogs, relatively little engineering effort gets dedicated to improving efficiency compared to WebKit (which is similarly efficient under Linux in e.g. GNOME Web, proving it’s not purely first-party advantage).
Most cross device stuff in the Apple world actually works via P2P Bluetooth and WiFi and functions without an internet connection or even a shared WiFi network. Mac and iDevice WiFi hardware is even designed with this in mind and is capable of maintaining P2P connections to other devices and a WiFi network simultaneously without rapidly switching between the two like many commodity WiFi cards have to.
reply