[refulgentis]

You're right but this touches the hot stove.

HN majority doesn't like hearing that ladybird et al might just be wandering around, even if the goal is catnip for the bleachers, and we should be skeptical this is the year of multiplatform Swift, because it wasn't last year if you actually tried it. Or the year before last. Or the year before that. Or the year before that year. Or the year before that one.

[afavour]

I’m slightly more ambivalent than you about it. Swift is a nice language and has better ergonomics than C++ and I imagine a Swift codebase might find more contributors than a C++ one (maybe I’m wrong about that!)

I also think it’s separate from the dream of “multiplatform Swift”. For that you need a healthy package ecosystem that all works cross platform, Swift doesn’t have that. But a lot of Ladybird is written at a low enough level that it won’t matter so much.

[refulgentis]

Problem is Swift engineer supply is low, there's not a viable business case to learn Swift because it's not actually viable cross-platform for development unless you have $X00 million to throw at your macOS/iOS team to build it from scratch, platform by platform (to wit, sibling comment re: Arc Browser)

So best case we're looking at: Swift isn't ready yet, the next major version will be, and we can't build UI with it, so we'll put in the effort in to bootstrap a cross-platform ecosystem and UI frameworks. Or maybe we'll just do our business logic in it? It's a confusing mess that is irrational. Even with great blessings of resources. ex. $X00M that Arc has obtained one incremental platform after a year. And "all" they had to do was Swift bindings for WinRT and connect it to the existing C++ engine.

All of this is easy to justify if we treat it as an opportunity to shoot for how we wish software could work in theory, instead of practice. I hope I'm wrong but after being right the last few years, I'm willing to say it's naive wishcasting out loud, even though its boorish. I see it as unfortunately necessary, a younger me would be greatly misled by the conversations about it on HN. "We've decided to write the browser in Swift!" approaches parody levels of irresponsible resource management and is a case study in several solo engineer delusions that I also fall victim to.

It's genuinely impossible for me to imagine anyone in my social circle of Apple devs, going back to 2007, who would think writing a browser engine in Swift is a good idea. I love Swift, used it since pre-1.0, immediately started shipping it after release, and that was the right decision. However, even given infinite resources and time, it is a poor fit for a browser engine, and an odd masochistic choice for cross-platform UI.

[lnrd]

> Problem is Swift engineer supply is low, there's not a viable business case to learn Swift because it's not actually viable cross-platform for development

The Swift business case is that in many situations native is strongly preferable than cross-platform. Excluding some startups that wants to go to market super fast and consulting companies that have to sell the cheapest software possible, usually the benefits of native outweighs the ones of cross platform.

For this reason now there are plenty of companies of all sizes (faangs included) that build and maintain native apps with separate iOS/Android teams. There are very good business reasons to learn Swift or Kotlin in my opinion.

[refulgentis]

Right -- no one read my comment and thought I meant Swift was unnecessary or businesses don't use it. Contextually, we're discussing Swift for cross-platform dev.

[lnrd]

I'm glad you know what everyone thinks while reading your comments.

[refulgentis]

Well I was trying to be kinder than just leaving you downvoted and confused why. I guess I shouldn't have bothered, my apologies. Hope your week gets better!

[jll29]

I wonder what convinced Andreas Kling to abandon his own language Jakt [1] in favour of Swift.

In the long run, it would be good to have high-level languages other than Java that have garbage collection (at least optionally) and classes, and that are still capable of doing cross-platform system development. I don't know if Swift fits that bill, besides cross-platform ecosystem (a la Java), submitting the language for ISO standardization (not just open sourcing one implementation) would be a good indication of being serious about language support.

[1] https://github.com/SerenityOS/jakt

[moogly]

> In the long run, it would be good to have high-level languages other than Java that have garbage collection (at least optionally) and classes, and that are still capable of doing cross-platform system development.

C#

[robryan]

One of the major differences between ladybird as part of serenity and ladybird the separate project is using 3rd party libraries. When what you are building are is for fun and you build everything yourself it makes sense to also build a language.

Ladybird as a separate project has the goal though of something usable in the shorter term. So similarly with switching to 3rd libraries for things I don't think it makes sense to spend potentially years first building the language before building the browser.

[refulgentis]

You might be powerfully dry here, imparting a Zen lesson. If not, or if you, dear reader, doesn't see it: it is worth meditating on that there was a language, an OS, and a web browser. Then, on common characteristics in decision-making that would lead to that. Then, consider the yaks that have to be shaved, the ISO standardization / more than one implementation hints at this.

[worik]

> and has better ergonomics than C++

It is unfair to compare a twenty first century language with one from the 1980s

Rust is the proper comparison

The only advantage Swift has is an easier learning curve , but the ergonomics of Rust are far superior than Sift's

[afavour]

It’s not really a question of fairness. The existing codebase is C++, the new stuff is Swift. Hence the comparison.

I’ve written both Rust and Swift while being an expert in neither. I wouldn’t say Swift has no pluses in comparison, reference counting is often a lot easier to reckon with than lifetimes, for one. I’m actually curious what a large multithreaded Swift codebase looks like with recent concurrency improvements. Rust’s async story isn’t actually that great.

[worik]

> Rust’s async story isn’t actually that great

I agree. People's perspectives differ. It abhor `async/await` in Rust. It has poisoned the well IMO for asynchronous Rust programming. (I adore asynchronous programming - I do not need to pretend my code is synchronous)

But that is taste, not a comment on poor engineering!

The lack of the borrow checker in Swift is what makes it approachable for newcomers, as opposed to Rust which is a harsh mistress.

But reference counting is such a silly idea. Swift really should have a garbage collector with a mechanism or subset to do that very small part of programming that cannot be done with a garbage collector. That would have been design!

I fear that Swift is going to get a borrow checker bolted on - and have the worst of both worlds....

[consteval]

Reference counted objects have deterministic lifetimes, like Rust or C++. Garbage collected languages don't have that. Essentially a reference counter automates some* of the ideas of the borrow checker, with a runtime cost as opposed to a compile time one.

The great thing about automatic reference counting is you can elide the incrementing and decrementing a lot of the time. Stronger guarantees, such as saying "this object is single-threaded" lead to even more optimizations.

[ec109685]

I don’t think Apple would want to sacrifice the determinism that refcounting provides for garbage collection. iOS apps are still more buttery smooth than Android in many cases.

[charrondev]

I mean this year we did have the porting of Arc browser to windows. I use it my gaming PC and it is starting to feel like it has a similar level of polish to the MacOS version.

https://speakinginswift.substack.com/p/swift-meet-winrt

https://speakinginswift.substack.com/p/swift-tooling-windows...

Now that’s not an engine but the UI.