43
votes
Ladybird un-chooses Swift as its successor language to C++
Link information
This data is scraped automatically and may be incorrect.
- Title
- faq: Update note about C++ successor language · LadybirdBrowser/ladybird.org@ed7d50d
- Authors
- LadybirdBrowser
I posted about Ladybird choosing Swift to succeed C++ in October 2024, but nothing became of that announcement.
Then I saw this commit show up in my RSS feed today and thought it was funny.
Dearest hungariantoast,
You do not know me personally, but for a variety of reasons unworthy of elaborating hereupon, I did find myself uncontrollably laughing out loud at your missive. Bellowing, cackling. Choking, a little, but jovially. Not in a manner at all worrisome. Truly, this has made my month.
Thank you,
/u/kacey
Well that's a bummer. Swift is one of the nicest of the modern safe languages to write and it would benefit greatly from increased cross-platform adoption.
Funnily enough I've worked with a lot of iOS developers that say the exact opposite.
As with anything else, opinions run the gamut, but based on personal experience and community observation, Swift itself isn't the primary driver of frustration in the Apple dev sphere. That would be SwiftUI, bad documentation, and Apple dragging their feet on adoption of things like modern Swift concurrency in its SDKs and in turn making adoption more difficult for third parties.
I won't pretend that it doesn't have warts. Whenever I open an old Obj-C project for example I'm always a little flabbergasted by how much faster it compiles and how much more responsive the IDE is editing it, but then I remember having to maintain header files, import a laundry list of libraries to make up for the language's shortcomings, and wrestle with the poor type hygiene that it enables and suddenly my nostalgia vanishes.
Perhaps the real issue is how few candidates there are for a modern systems and native app language. Rust is probably the frontrunner but it's… an acquired taste and not really built to be accessible for people coming from languages with syntax more in line with that of C/JS/Swift/etc.
Apple's developer documentation is shockingly bad, I gotta give credit to indie developers for putting out apps as good as they do because they certainly are not getting any help from Apple's documentation. You get minimal information about what you want, sometimes so minimal that it is missing, few code examples that rarely help in a production context, and sometimes things are buried in WWDC videos instead of being written up.
The saving grace is the scope and depth of Apple platform APIs, as well as their opinionated “happy path” nature. That’s what makes it possible to build impressive things despite poor documentation.
Many, maybe even most other platforms suffer from a trifecta of poor documentation, little or no opinionation, and spotty API coverage or poor APIs which makes it a struggle to build anything of decent quality.
And then they wonder why some programmers don't feel threatened by LLM's scraping the net.
There's so much tribal knowledge of these APIs you can only really know from working on these closed off, proprietary codebases. And in some cases by directly working on the API at that company. Which I hate, but I find some schadenfreude knowing that it unintentially hoisted many of these companies by their own pitard when they suddenly wanted all the code in the world.
That it's not a nice language? Or that cross-platform adoption would harm it?
The former!
Thoughts on Kotlin? I'm an android dev, so work in Kotlin all day every day, but have never touched Swift. I've never had a single complaint about Kotlin, I love working with it! I like Compose as well, though I don't get to work with much at work, because the project is older than Compose and we're not about to rewrite the whole thing anytime soon.
I write it regularly and while it’s not bad, I prefer Swift. I’m probably biased though, because by the time I picked up Kotlin I’d already been writing Swift for 3-4 years.
The two share a lot syntactically, but Swift leans more in an ergonomics/dev happiness/choice direction while Kotlin feels more concerned with theoretical correctness. Given my self-taught background and experience with Ruby (which leans heavily in the dev happiness direction), I’m naturally more inclined towards Swift.
There are also some things about Kotlin which annoy me, at least in the context of Android development. Smart casting of optionals doesn’t work half the time without breaking out a local variable for example, which makes me wish Kotlin had Swift’s
if letandguard letunwrapping syntax.Perhaps controversial, but I also think that Kotlin is somewhat held back by its Java heritage. Its Java interop isn’t quite as clean as Swift’s corresponding Obj-C/C interop, and I find JVM tooling frequently arcane and frustrating.
Compose is decent and a far sight better than Android Framework (which is a bloody mess), but it still suffers from things like widgets described in the Material spec being absent or only partially functional, leaving me to roll my own. It’s also still awkward in some ways, and I’m not sure I’m sold on declarative UI frameworks as an end-all-be-all solution.
Just piping in to high five a fellow Kotlin enjoyer! It's fantastic all across the stack, and it truly delivered on its goals ("better Java, without becoming Scala"). The type system is just expressive enough to handle anything one would reasonably throw at it, without being too much of a senior architect attractant to become an overcomplicated mess. The smart casting works flawlessly -- for me, at least -- allowing for lovely usage patterns (such as early
returns on nullity checks) to be implemented with ease. Everything about it is just so very well thought through and designed, plus, it gets to lean on several decades of extremely solid Java libraries and tooling!I admit that I haven't used it recently -- preferring Rust for my personal work -- but if I were ever to start working on a larger team again, I'd use Kotlin in a heartbeat. Assuming we're still writing code in the future, and not directing LLMs through markdown design files 😅
I wonder how much of my smart casting issues boil down to Android APIs being wrapped Java rather than being "pure" Kotlin. I've never worked with Kotlin in backend projects.
That could very well be the case, if you're referencing Java property accessors instead of fields -- e.g. this fails to compile, since it has a custom accessor (like Java would have) that could return a different value on a subsequent call. Most of the time, yeah, you'd just want to assign that to a value instead of referring to the field repeatedly, but I can understand why that'd be annoying.
That said, it seems odd, since most Java values are platform typed by default? So the compiler shouldn't even force a null check to begin with.
(edit) Although I'm distantly remembering that one can write contracts to make kotlin-wrapped Java APIs reflect field immutability ...
have they posted anywhere about the rationale for moving away from C++? I take it memory safety is a thing they rate highly. But at this point (early alpha) in their development, it seems like a strange choice to switch horses.
In the original announcement they cited the C++ interoperability and memory safety as their key reasons for selecting it. However looking at their (Swift's) dev docs (funny to do so after complaining about how bad it is), it looks like the docs haven't been updated since last April so I can't imagine much (public-facing) technical progress being made on the interoperability either.