from Hacker News

Ladybird browser to start using Swift language this fall

by nopakos on 8/10/24, 11:52 AM with 192 comments

• by enragedcacti on 8/10/24, 2:03 PM

  I'm seeing a lot of doom and gloom about this mostly stemming from the state of open source swift, but I think the choice has a lot of upside for two main reasons:

  1) Choosing Swift implicitly adds improving the status quo of open source swift to the tasks of ladybird. This obviously expands the already huge scope of the project but also derisks it in some ways because it means the project can have a lasting impact regardless of its goals as a competitive browser. Remember that Rust was tempered as a language through the development of Servo and Ladybird could do the same for the non-Apple Swift ecosystem.

  2) It unlocks access to a huge number of Swift developers and offers them a unique open source project to work on rather than just building apps for Apple products. As far as I am aware there is no other major language with such a massive (size of developer base):(open source opportunities) ratio. Ladybird acting as the cornerstone of that community could have mutually beneficial results that improve the development of ladybird while also fostering excitement for open source, non-Apple Swift projects.

  Ladybird is a wildly ambitious project. We have N=3(ish) for how long it takes to develop a competitive browser from scratch in C++ even with the support of massive companies behind you and it isn't very fast. Obviously we know it works but Ladybird is on mile 100 of a bicycle race around the globe that started 30 years ago. Staying the course on C++ to me looks like saying "We're already so far behind, we can't afford to stop and add an electric motor!" meanwhile everyone else is still pedaling and you aren't getting any closer.

• by Decabytes on 8/10/24, 1:28 PM

  I totally get using Swift in this context considering their heavy emphasis on C++. From my personal experience, Swift still feels like the early days of Open source .NET/Mono. You will definitely experience the growing pains of being an early adopter of the language. The fact that JetBrains killed AppCode in Dec of 2022 7 years after Swift went Open Source is telling to me that getting the traction outside of the Apple ecosystem is not there. The vast majority of the people I see developing open source Swift apps still use Xcode and a Mac. For example Miguel De Icaza is a huge proponent of open source Swift, and is doing a lot of cool things with Swift Godot. But he develops on a Mac just like everyone else. The experience with VScode is just okay.

  I think that the cross platform story both in terms of developer libraries, experience, and tooling is still much better on .NET, and provides a happy middle ground between something like Swift and Java. With that beings said I hate the options for Mobile/GUI with .NET (MAUI, or AvaloniaUI), and would recommend Java/Kotlin if you want to do that. I want to give a special shout out to F# as I feel like it is the most sensible functional programming language I've ever used, and is a lot less verbose then C#. The only knock against it I have is that it's a smaller community than C# and most of the libraries you use will be written in C# so you need to know a little C# as well to be effective

• by stephen_g on 8/10/24, 12:54 PM

  I had suspected this would happen, I haven’t got into Swift yet (I’m mostly doing embedded C still) but Swift finally seems to have just ticked off some niggles that makes it a much stronger contender. Things like not having official Debian builds (there were Ubuntu etc.), not being able to run under other C libraries like musl (like if you want to run in Alpine Linux containers), not really being able to run embedded etc. basically all being fixed in the last release (or starting the process, like with the embedded subset). Add in the newish C++ interop and it does seem much more attractive now as a pin ergonomic, memory safe, cross-platform language at all levels of the stack!

  (This is of course by design, Apple intend to use Swift from everything from firmware of things like the Secure Enclave chip, through to the kernel, through to all the apps, but to be able to bring it in gradually with the interop, so not having to rewrite everything from scratch).

• by christophilus on 8/10/24, 1:49 PM

  For those who are worried, Andreas is a thoughtful dude. This decision was not made on a whim.

  Also, they’re not doing a massive rewrite:

  > The Swift team is also investing heavily in C++ interop, which means there's a real path to incremental adoption, not just gigantic rewrites.

  To me, the Tweet does a good job justifying the decision. I’m rooting for Ladybird, and I hope this decision pays off. A modern browser in a modern language sounds like a dream come true.

• by blinkingled on 8/10/24, 1:19 PM

  Seems premature. You don't write successful browser engines using relatively new language that is optimized for one platform.

  But it was predictable - Andreas comes from Apple background so.. The other thing is no one can build a browser alone - the ability to attract the right people is what differentiates a mainstream usable browser and a toy one. IOW focusing on adding another language that is not as popular amongst the right developer demographic seems like the wrong thing to focus on at this stage.

• by losvedir on 8/10/24, 4:02 PM

  Wow! This is awesome news. Swift is like the perfect language to me - kind of a Rust (whose type system I adore) but with garbage collection. I'd always thought it was a little too tied to the Apple ecosystem, and specifically iOS, but if they can make this work for a cross-platform browser, then I'll have to give it another look. Maybe things have changed recently.

  Oooh, or maybe I can even contribute now! I've supported Kling via GitHub for a while now and have been stoked about his pivot to building a browser. I never really dreamed of contributing, given C++, but now it feels more achievable.

• by lawn on 8/10/24, 12:50 PM

  > Support for non-Apple platforms is also improving, as is the support for other, LSP-based development environments.

  Improving, as in ready now or still far in the future?

  What does the current state of Swift look like for Linux and Windows? And how well does the LSP server function today?

• by zelphirkalt on 8/10/24, 2:04 PM

  Hm. Not sure, if this is really a wise choice. After all they are choosing to use an Apple controlled programming language. Whatever direction Apple wants to go in, they will face themselves with following or working around. As an example we can look at Go and the whole GOPROXY debacle. And they will also have to deal with Apple not going into a direction, if they need that direction. Might have to build more stuff themselves, than with a language that is basically community owned. What if the Swift compiler starts doing things they don't like? They just going to be stuck at an obsolete version then? Or fork the language?

• by peppermint_gum on 8/10/24, 12:19 PM

  One thing I don't understand about Swift is why it uses a private fork of LLVM. Why can't they upstream whatever changes they need?

• by ksec on 8/10/24, 4:30 PM

  I am just worried.

  I just wish they could at least delay it until Swift 6.1, giving time for it to mature. And let the idea to jump right into Swift after 6.0 to age a little more.

  Developers have a tendency to jump to new language, new tools, new problems because it is exciting and fun.

• by neonsunset on 8/10/24, 1:09 PM

  It is unfortunate that Ladybird did not choose C#, being another high-level-adjacent C family language with strong systems programming capabilities crucial in browser development.

  It has smaller AOT binary size, faster application code performance and much bigger ecosystem of GUI libraries and native GUI library bindings (everything you have in C and C++ you pretty much have in C#) which can be used with very low overhead. Not to mention better cross-platform tools and build system.

  With that said, I do like and respect Swift, and am curious to see what Ladybird team will do with it.

• by pelagicAustral on 8/10/24, 1:56 PM

  I did wondered how long would it take for a Rust zealot to take over this thread, it is already ongoing...

  That being said, this is a rather odd decision. Why would you go so much out of your way to add yet another compiling stage, yet another language that, far as I can tell, is not getting much traction in this space?

• by nu11ptr on 8/10/24, 12:57 PM

  This is interesting. I evaluated Swift, but it didn't feel like platforms outside of Apple were first class. If this is changing, it would be a good thing.

• by dvektor on 8/10/24, 1:47 PM

  I am a bit surprised at this, considering the lack of non-apple ecosystem but I guess when you build everything yourself completely from scratch, you may not care as much about libraries and ecosystem.

• by throwaway1194 on 8/11/24, 8:23 PM

  I don't know how and why people still take this guy seriously, let alone throw money at his projects.

  Andreas has demonstrated time and time again that he can't keep his word. He says one thing and does things differently.

  That wouldn't be too much of a problem if he didn't accuse others of what he is guilty of, toxicity.

  He is also known for bashing other projects to promote his own. I would go help Servo instead. Ladybird isn't going anywhere, same as SerenityOS.

• by BaculumMeumEst on 8/10/24, 1:32 PM

  What happened to jakt?

• by tasty_freeze on 8/10/24, 1:26 PM

  I know Andreas is a prolific coder, but this seems weird to have a pretty functional (but far from complete) browser written in C++ and then casually say, eh, "We are going to rewrite it in another language" in the same way one might say "We've decided to change the branding logo"?

  I know that is a run-on sentence, but I need to get my exercise.

• by frankjr on 8/10/24, 6:27 PM

  Does anybody know if the upcoming version resolves the compilation time issues?

  https://danielchasehooper.com/posts/why-swift-is-slow

• by diimdeep on 8/10/24, 4:56 PM

  There you go, we have immature industry if Rust or Swift is only logical choice to substitute C++, maybe working on a better language would be such a bad idea after all, meanwhile still long on Jai.

• by Thaxll on 8/10/24, 1:04 PM

  Using Swift outside of Apple ecosystem seems like a bad idea, other platform are subparts.

• by Affric on 8/10/24, 12:46 PM

  ==============================

  Andreas Kling @awesomekling · 44m

  My general thoughts on Rust:

  - Excellent for short-lived programs that transform input A to output B

  - Clunky for long-lived programs that maintain large complex object graphs

  - Really impressive ecosystem

  - Toxic community

  ==============================

• by stephc_int13 on 8/10/24, 1:34 PM

  I think this kind of reckless move is likely to be very costly and could even jeopardize the success of this project.

  I would say the same thing with any languages switch, except C and C++ as they tend to mix well and coders are usually familiar with both.

  But Swift is, in my opinion, the worst possible choice. It is known to be a mess, even criticized by its original maker.

  The compilation times are horrendous and nobody in the team is a Swift expert.

  When making large architecture decisions on such a complex and difficult project, the people in charge should use all their mental energy on that task, not exploring new idioms or styles.

  The only valid explanation that I can think of is that they are being funded to promote Swift.

• by rvz on 8/10/24, 12:36 PM

  I would have thought that Ladybird would be using a language that specifically guarantees memory safety which is Rust. But Swift is a very surprising choice but actually makes sense for a browser.

  The browser story is not great for Rust as we can only point to Servo which isn't ready to be used as a daily driver for millions of users. But Arc Browser is written with a combination of Swift and C++ to run on macOS and Windows.

  Other than iOS apps, perhaps Swift found another use-case in large C++ code bases thanks to the C++ interop story.