15 ms·

Ladybird browser to start using Swift language this fall

200 points by nopakos 2y ago

peppermint_gum 2y ago
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?
- pjmlp 2y ago
  Because the same also applies to clang, and contrary to what people think, Apple like every other big tech, is only as nice to FOSS as they need to be for their own purposes. Same applies to all C and C++ compiler vendors, that have replaced their proprietary compilers (there are plenty more than just clang/gcc/msvc), with LLVM. Such is the freedom of Apache/MIT/BSD style licenses.
  - peppermint_gum 2y ago
    Swift's LLVM fork is open-source, just not upstreamed. No Free Software license requires forks to upstream their changes. https://github.com/swiftlang/llvm-project https://github.com/swiftlang/llvm-project
    - pjmlp 2y ago
      Yet you're complaining that they are using the licence exactly as they feel like.
      - nequo 2y ago
        Parent was not complaining. Parent was asking what the rationale is behind maintaining a separate LLVM fork instead of upstreaming and reducing the maintenance burden on Apple engineers.
    - Zambyte 2y ago
      Referring to their fork as "private" seems quite misleading then.
  - okr 2y ago
    I would not say its about niceness, its more about necessities. If ya don't own something, the walls are high to have anything changed, naturally. Because it might not be aligned with what the owner has had in it's mind. And you want to move quickly. So you fork and apply your changes. But i also think, in the long run, it hurts, bcs at some point, you forks are too diverged. But so is life.
- ezfe 2y ago
  I’ve just read the swift build guide and there’s no sign of a closed-source version of LLVM. What are you talking about?
  - mkl 2y ago
    peppermint_gum didn't mention a closed-source version of LLVM either. "Private" just means "their own" here.
    - Zambyte 2y ago
      > "Private" just means "their own" here. "Fork" is actually the word that means "their own". The "private" does indeed mean "proprietary" in this context.
- ChocolateGod 2y ago
  Doesn't Xcode ship with a closed-source build of LLVM (with patches) that you're referring to.
- masklinn 2y ago
  Because Apple does not direct the LLVM project, and they have their own corporate designs and plans. I'm sure they upstream what changes they think will be accepted, but there's no guarantee upstream would accept what they want or need let alone on the timeline they need it.
- GeekyBear 2y ago
  > Today there are a few non-trivial differences from LLVM, but we are actively working on either upstreaming or reverting those differences https://github.com/swiftlang/llvm-project https://github.com/swiftlang/llvm-project
rvz 2y ago
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.
- jghn 2y ago
  > specifically guarantees memory safety which is Rust I think you mean "one of which is Rust".
- jsheard 2y ago
  I'm not sure if the comparison to Servo holds up since that's a browser engine, and Arcs engine (Chromium) is 100% C++. Swift is only used for the frontend.
- GeekyBear 2y ago
  > I would have thought that Ladybird would be using a language that specifically guarantees memory safety which is Rust. Rust isnt the only compiled language that provides memory safety by default. Swift does as well.
  - zozbot234 2y ago
    Does Swift enforce memory safety in concurrent code also, i.e. preventing thread-unsafe data access in safe code? That's a really hard problem that Rust tries to address mostly successfully, and many other languages don't.
    - GeekyBear 2y ago
      Yes. That is a new feature as of version 6 of Swift. https://www.swift.org/migration/documentation/swift-6-concurrency-migration-guide/dataracesafety/ https://www.swift.org/migration/documentation/swift-6-concur...
Affric 2y ago
============================== 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 ==============================
- BoredPositron 2y ago
  He's not wrong.
  - pas 2y ago
    can you please substantiate in which points and how right he is? do you have experience with complex object graphs in Rust, direct or indirect experience about the community? thanks!
    - Decabytes 2y ago
      This huge blog post goes over some of the challenges of using Rust. https://loglog.games/blog/leaving-rust-gamedev/ https://loglog.games/blog/leaving-rust-gamedev/ For the community I'll pluck out this paragraph > That being said, there is an overwhelming force in the Rust community that when anyone mentions they're having problems with Rust the language on a fundamental level, the answer is "you just don't get it yet, I promise once you get good enough things will make sense". This is not just with Rust, if you try using ECS you're told the same thing. If you try to use Bevy you'll be told the same thing. If you try to make GUIs with whichever framework you choose (be it one of the reactive solutions or immediate mode), you'll be told the same thing. The problem you're having is only a problem because you haven't tried hard enough. I've experienced this same feedback when I was struggling with Rust. One time when I posted in the Rust subreddit about it seeking help and talking about my struggles, I got the unhelpful response of "I believe in people" as a dismissive response to my struggles. Admittedly this was years ago and I've since moved on from Rust, but the blog post is dated from 2024-04-26, so it appears the issues with the language still remain
lawn 2y ago
> 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?
- alargemoose 2y ago
  I can’t speak to the current state of swift on other platforms directly/in detail. But I would point to the Arc browser being built using swift for both the windows and MacOS versions. They’ve also open-sourced a number of tools they built to make that work https://github.com/thebrowsercompany https://github.com/thebrowsercompany
- rescripting 2y ago
  Usable now for sure. I’ve been doing Swift development in VS Code which uses the LSP under the hood and it pretty much does what I expect an editor to do. Both the VS Code extension and the LSP are open source and seem pretty active, so hopefully they’ll get even better over time. The package ecosystem does feel sparse, especially coming from doing Node development.
stephen_g 2y ago
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).
- cube2222 2y ago
  Honestly, Swift seems like such a nice language. Most of the performance and power, great interop, but more directed at application development than Rust (with e.g. refcounting being the default). But as they say, you choose a language for its ecosystem, not for the language itself. It would be great if Swift’s open source ecosystem for stuff other than app development grew. It does indeed seem like Apple is pushing for it with stuff like Swift for embedded. The fairly recent presentation about starting to move FoundationDB to Swift[0] was also very interesting. A follow-up on that at some point would be quite interesting to see too, and would inspire confidence if the process is going well. Arc is also a nice example of a cross-platform app written in Swift, with their fairly recent addition of Windows support. Either way, fingers crossed, and very happy with TFA. PS: does anybody have experience with async/await in Swift? Is it pleasant to use? [0]: https://www.youtube.com/watch?v=ZQc9-seU-5k https://www.youtube.com/watch?v=ZQc9-seU-5k
  - cube2222 2y ago
    Found an interesting article about the internals of async specifically[0], also the docs[1]. TLDR: Seems like it uses a global thread pool, where each async method call yields to the runtime. Additionally, you get actors which are special classes with serialized method calls, and everybody other than itself has to call those methods as async. Additionally, you can have custom executors, who, if I understand correctly, still only pass tasks to the global thread pool, but can influence the scheduling order. Finally, you can force functions/actors to run on the main thread (outside of the thread-pool) as iOS requires the UI to run on the main thread. Interestingly (from an API evolution perspective), async protocol functions can be implemented in classes by synchronous functions, as async in swift means "this could be async". Which plays well with the fact that async functions can call sync ones, but not vice-versa. Additionally, it has cooperative cancellation (you can basically check if you've been cancelled and react accordingly). Concurrency is by default structured, and cancelling a parent task will cancel its children. [0]: https://swiftrocks.com/how-async-await-works-internally-in-swift https://swiftrocks.com/how-async-await-works-internally-in-s... [1]: https://docs.swift.org/swift-book/documentation/the-swift-programming-language/concurrency/ https://docs.swift.org/swift-book/documentation/the-swift-pr...
nu11ptr 2y ago
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.
Thaxll 2y ago
Using Swift outside of Apple ecosystem seems like a bad idea, other platform are subparts.
- yohannparis 2y ago
  Compiled Swift code cannot run on other platform? Curious, I never used it and I'm not aware of those limitations.
  - breakfastduck 2y ago
    It can, the poster you're replying to is ill informed.
neonsunset 2y ago
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.
- hypeatei 2y ago
  I think most are just ignorant of what .NET is today vs 10-15 years ago. From my own personal findings, most on HN and general online dev space think it's Windows only and that hasn't been true for ~8 years or so. Microsoft has shifted to an open source approach for almost everything and Linux & Mac are first class citizens.
  - eterps 2y ago
    Are there any relatively well known non-Windows apps written in .NET? I guess Discord? Any others?
    - neonsunset 2y ago
      Pretty much every non-GUI (and GUI if it's Avalonia/Uno/etc.) .NET application, unless it uses niche things like windows registery or management API, is by definition platform agnostic and runs wherever .NET runs (macOS, Linux, FreeBSD(with caveats), Android, iOS, Windows, sometimes in browser with WASM). Most businesses which have moved away from old versions run their server workloads on Linux hosts within K8S or otherwise. Popular applications that run on Linux are Jellyfin: https://github.com/jellyfin/jellyfin https://github.com/jellyfin/jellyfin Sonarr (and other High Seas apps): https://github.com/Sonarr/Sonarr https://github.com/Sonarr/Sonarr Ryujinx: https://github.com/Ryujinx/Ryujinx https://github.com/Ryujinx/Ryujinx (the kind of project that could likely compete with writing a browser in complexity) Bitwarden (server): https://github.com/bitwarden https://github.com/bitwarden Garnet: https://github.com/microsoft/garnet https://github.com/microsoft/garnet (likely the fastest Redis implementation) Stride3D: https://github.com/stride3d/stride https://github.com/stride3d/stride Godot (offers C# as script language, using regular .NET) Various MonoGame and FNA games (which use vanilla .NET unlike Unity, there was even a game on Nintendo Switch with private FNA fork). From the top of my head, I'm sure there are many others.
deleted 2y ago
[deleted]
blinkingled 2y ago
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.
Hizonner 2y ago
[flagged]
tasty_freeze 2y ago
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.
- lawn 2y ago
  Actually, moving to a memory-safe language should be a very high priority for developing a browser and the sooner they do that the better.
  - TinkersW 2y ago
    Swift/C++/Zig all have the exact same level of memory safety, but anyone they said they aren't porting, sounds more like writing new stuff in Swift and hoping the interop story is good enough.
- stephc_int13 2y ago
  It is just like when a video game team decide to switch or rewrite the game-engine mid-course. A huge red flag. Almost always kills the project or make it so late that it becomes irrelevant. C++ is not a perfect language, but it works, and they have experts on the team, what they are trying to achieve is difficult enough. Well, RIP Ladybird, I was hopeful about this project, this seriously makes me sad.
- noirscape 2y ago
  Depends on the approach. There's an odd benefit to C++ being the starting language; C++ is ancient and because of that you can make it interop with most other languages; in this case, the switch to Swift will probably simply mean replacing C++ modules (likely starting with the ones that cause the most memory bugs) with Swift modules and gradually switching things out since Swift has C++ interop[0]. It's less a "rewrite from the ground up" and more a "this is the main language we'll be using from now on". As for the reason to stop using C++; honestly what reason isn't there by now. The only reason to still use C++ in this day and age is if you're targeting very non-standard hardware or are developing videogames. The language is memory unsafe in a way that almost every other language isn't (like, even if you don't pick a language with an overly worrywart borrow checker, C++ is remarkably worse at memory management), the standard library is awful and it's stuck with the chain and ball of being a superset of C on it's leg, meaning that every reason why you wouldn't use C also applies to C++ (minus the "C isn't OOP" one). [0]: https://www.swift.org/documentation/cxx-interop/ https://www.swift.org/documentation/cxx-interop/
Decabytes 2y ago
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
- pjmlp 2y ago
  C# has a uphill battle against those that don't believe in systems programming languages with GC, despite several graphical workstations have been done in the past in such languages. Unfortunately freebie UNIX, and security was yet decades away to be relevant to governmental regulators, thus they never managed to gain enough mindshare to keep going. Additionally even with all the .NET team efforts, the technology remains mostly relevant to Microsoft shops. I seldom see RFPs from UNIX first culture companies, that quote .NET as possible delivery technology.
  - layer8 2y ago
    GC still has the downside of higher memory overhead. While I’m not particularly a fan of Swift, this is a relevant argument for a general-purpose browser implementation.
BaculumMeumEst 2y ago
What happened to jakt?
- rvz 2y ago
  Very good question. Who knows.
- hypeatei 2y ago
  Contributions are still being made to it[0], but definitely nothing compared to when it was first announced. Seems essentially dead to me at least. [0]: https://github.com/SerenityOS/jakt https://github.com/SerenityOS/jakt
- CxByte 2y ago
  Regardless of where jakt goes, it would never be qualified for this; Ladybird is doing its best to get rid of everything home-built that is not the web-platform. (Also it's a really young language with <5 recurring contributors, of course it's not even on the radar :)
stephc_int13 2y ago
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.
dvektor 2y ago
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.
christophilus 2y ago
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.
- stephc_int13 2y ago
  I strongly disagree. This is not a justified decision, they just feel like it based either on vague and speculative reasons, or because they are funded to do so, I would not be surprised if they had discussions with the Swift marketing team.
  - keybored 2y ago
    How do you know?
  - gjsman-1000 2y ago
    Then build your own browser in Rust, start contributing to Servo, and who cares when a volunteer writes a browser in any language? Write a browser in COBOL for all I care. If it’s open source, it’s still a gift.
    - stephc_int13 2y ago
      Absolutely not. I don't know Rust and I think it is worse than C++ in many ways. This is a false dichotomy, they don't have to switch language mid-course.
      - JTyQZSnP3cQGa8B 2y ago
        I am very confused by your message. I know both Rust and C++ and think it’s an improvement in many ways. Why do you you think it’s worse without using the language?
pelagicAustral 2y ago
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?
deleted 2y ago
[deleted]
enragedcacti 2y ago
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.
zelphirkalt 2y ago
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?
- bhokbah 2y ago
  The language is controlled by the Swift evolution process but Apple engineers are basically the only ones contributing and submitting proposals.
losvedir 2y ago
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.
ksec 2y ago
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.
diimdeep 2y ago
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.
- frankjr 2y ago
  > meanwhile still long on Jai On a language which doesn't have any safety, doesn't plan on implementing basic features such as incremental compilation, tagged unions, async, or package management and others, and nobody is currently working on? Good luck.
  - davikr 2y ago
    Well, you don't need incremental compilation if you have a fast compiler. I can't speak for the other points, though.
frankjr 2y ago
Does anybody know if the upcoming version resolves the compilation time issues? https://danielchasehooper.com/posts/why-swift-is-slow https://danielchasehooper.com/posts/why-swift-is-slow
throwaway1194 2y ago
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.

200 points by nopakos 2y ago

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?

pjmlp 2y ago
Because the same also applies to clang, and contrary to what people think, Apple like every other big tech, is only as nice to FOSS as they need to be for their own purposes. Same applies to all C and C++ compiler vendors, that have replaced their proprietary compilers (there are plenty more than just clang/gcc/msvc), with LLVM. Such is the freedom of Apache/MIT/BSD style licenses.
- peppermint_gum 2y ago
  Swift's LLVM fork is open-source, just not upstreamed. No Free Software license requires forks to upstream their changes. https://github.com/swiftlang/llvm-project https://github.com/swiftlang/llvm-project
  - pjmlp 2y ago
    Yet you're complaining that they are using the licence exactly as they feel like.
    - nequo 2y ago
      Parent was not complaining. Parent was asking what the rationale is behind maintaining a separate LLVM fork instead of upstreaming and reducing the maintenance burden on Apple engineers.
  - Zambyte 2y ago
    Referring to their fork as "private" seems quite misleading then.
- okr 2y ago
  I would not say its about niceness, its more about necessities. If ya don't own something, the walls are high to have anything changed, naturally. Because it might not be aligned with what the owner has had in it's mind. And you want to move quickly. So you fork and apply your changes. But i also think, in the long run, it hurts, bcs at some point, you forks are too diverged. But so is life.
ezfe 2y ago
I’ve just read the swift build guide and there’s no sign of a closed-source version of LLVM. What are you talking about?
- mkl 2y ago
  peppermint_gum didn't mention a closed-source version of LLVM either. "Private" just means "their own" here.
  - Zambyte 2y ago
    > "Private" just means "their own" here. "Fork" is actually the word that means "their own". The "private" does indeed mean "proprietary" in this context.
ChocolateGod 2y ago
Doesn't Xcode ship with a closed-source build of LLVM (with patches) that you're referring to.
masklinn 2y ago
Because Apple does not direct the LLVM project, and they have their own corporate designs and plans. I'm sure they upstream what changes they think will be accepted, but there's no guarantee upstream would accept what they want or need let alone on the timeline they need it.
GeekyBear 2y ago
> Today there are a few non-trivial differences from LLVM, but we are actively working on either upstreaming or reverting those differences https://github.com/swiftlang/llvm-project https://github.com/swiftlang/llvm-project

rvz 2y ago

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.

jghn 2y ago
> specifically guarantees memory safety which is Rust I think you mean "one of which is Rust".
jsheard 2y ago
I'm not sure if the comparison to Servo holds up since that's a browser engine, and Arcs engine (Chromium) is 100% C++. Swift is only used for the frontend.
GeekyBear 2y ago
> I would have thought that Ladybird would be using a language that specifically guarantees memory safety which is Rust. Rust isnt the only compiled language that provides memory safety by default. Swift does as well.
- zozbot234 2y ago
  Does Swift enforce memory safety in concurrent code also, i.e. preventing thread-unsafe data access in safe code? That's a really hard problem that Rust tries to address mostly successfully, and many other languages don't.
  - GeekyBear 2y ago
    Yes. That is a new feature as of version 6 of Swift. https://www.swift.org/migration/documentation/swift-6-concurrency-migration-guide/dataracesafety/ https://www.swift.org/migration/documentation/swift-6-concur...

Affric 2y ago

============================== 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 ==============================

BoredPositron 2y ago
He's not wrong.
- pas 2y ago
  can you please substantiate in which points and how right he is? do you have experience with complex object graphs in Rust, direct or indirect experience about the community? thanks!
  - Decabytes 2y ago
    This huge blog post goes over some of the challenges of using Rust. https://loglog.games/blog/leaving-rust-gamedev/ https://loglog.games/blog/leaving-rust-gamedev/ For the community I'll pluck out this paragraph > That being said, there is an overwhelming force in the Rust community that when anyone mentions they're having problems with Rust the language on a fundamental level, the answer is "you just don't get it yet, I promise once you get good enough things will make sense". This is not just with Rust, if you try using ECS you're told the same thing. If you try to use Bevy you'll be told the same thing. If you try to make GUIs with whichever framework you choose (be it one of the reactive solutions or immediate mode), you'll be told the same thing. The problem you're having is only a problem because you haven't tried hard enough. I've experienced this same feedback when I was struggling with Rust. One time when I posted in the Rust subreddit about it seeking help and talking about my struggles, I got the unhelpful response of "I believe in people" as a dismissive response to my struggles. Admittedly this was years ago and I've since moved on from Rust, but the blog post is dated from 2024-04-26, so it appears the issues with the language still remain

lawn 2y ago

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

alargemoose 2y ago
I can’t speak to the current state of swift on other platforms directly/in detail. But I would point to the Arc browser being built using swift for both the windows and MacOS versions. They’ve also open-sourced a number of tools they built to make that work https://github.com/thebrowsercompany https://github.com/thebrowsercompany
rescripting 2y ago
Usable now for sure. I’ve been doing Swift development in VS Code which uses the LSP under the hood and it pretty much does what I expect an editor to do. Both the VS Code extension and the LSP are open source and seem pretty active, so hopefully they’ll get even better over time. The package ecosystem does feel sparse, especially coming from doing Node development.

stephen_g 2y ago

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

cube2222 2y ago
Honestly, Swift seems like such a nice language. Most of the performance and power, great interop, but more directed at application development than Rust (with e.g. refcounting being the default). But as they say, you choose a language for its ecosystem, not for the language itself. It would be great if Swift’s open source ecosystem for stuff other than app development grew. It does indeed seem like Apple is pushing for it with stuff like Swift for embedded. The fairly recent presentation about starting to move FoundationDB to Swift[0] was also very interesting. A follow-up on that at some point would be quite interesting to see too, and would inspire confidence if the process is going well. Arc is also a nice example of a cross-platform app written in Swift, with their fairly recent addition of Windows support. Either way, fingers crossed, and very happy with TFA. PS: does anybody have experience with async/await in Swift? Is it pleasant to use? [0]: https://www.youtube.com/watch?v=ZQc9-seU-5k https://www.youtube.com/watch?v=ZQc9-seU-5k
- cube2222 2y ago
  Found an interesting article about the internals of async specifically[0], also the docs[1]. TLDR: Seems like it uses a global thread pool, where each async method call yields to the runtime. Additionally, you get actors which are special classes with serialized method calls, and everybody other than itself has to call those methods as async. Additionally, you can have custom executors, who, if I understand correctly, still only pass tasks to the global thread pool, but can influence the scheduling order. Finally, you can force functions/actors to run on the main thread (outside of the thread-pool) as iOS requires the UI to run on the main thread. Interestingly (from an API evolution perspective), async protocol functions can be implemented in classes by synchronous functions, as async in swift means "this could be async". Which plays well with the fact that async functions can call sync ones, but not vice-versa. Additionally, it has cooperative cancellation (you can basically check if you've been cancelled and react accordingly). Concurrency is by default structured, and cancelling a parent task will cancel its children. [0]: https://swiftrocks.com/how-async-await-works-internally-in-swift https://swiftrocks.com/how-async-await-works-internally-in-s... [1]: https://docs.swift.org/swift-book/documentation/the-swift-programming-language/concurrency/ https://docs.swift.org/swift-book/documentation/the-swift-pr...

nu11ptr 2y ago

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.

Thaxll 2y ago

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

yohannparis 2y ago
Compiled Swift code cannot run on other platform? Curious, I never used it and I'm not aware of those limitations.
- breakfastduck 2y ago
  It can, the poster you're replying to is ill informed.

neonsunset 2y ago

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.

hypeatei 2y ago
I think most are just ignorant of what .NET is today vs 10-15 years ago. From my own personal findings, most on HN and general online dev space think it's Windows only and that hasn't been true for ~8 years or so. Microsoft has shifted to an open source approach for almost everything and Linux & Mac are first class citizens.
- eterps 2y ago
  Are there any relatively well known non-Windows apps written in .NET? I guess Discord? Any others?
  - neonsunset 2y ago
    Pretty much every non-GUI (and GUI if it's Avalonia/Uno/etc.) .NET application, unless it uses niche things like windows registery or management API, is by definition platform agnostic and runs wherever .NET runs (macOS, Linux, FreeBSD(with caveats), Android, iOS, Windows, sometimes in browser with WASM). Most businesses which have moved away from old versions run their server workloads on Linux hosts within K8S or otherwise. Popular applications that run on Linux are Jellyfin: https://github.com/jellyfin/jellyfin https://github.com/jellyfin/jellyfin Sonarr (and other High Seas apps): https://github.com/Sonarr/Sonarr https://github.com/Sonarr/Sonarr Ryujinx: https://github.com/Ryujinx/Ryujinx https://github.com/Ryujinx/Ryujinx (the kind of project that could likely compete with writing a browser in complexity) Bitwarden (server): https://github.com/bitwarden https://github.com/bitwarden Garnet: https://github.com/microsoft/garnet https://github.com/microsoft/garnet (likely the fastest Redis implementation) Stride3D: https://github.com/stride3d/stride https://github.com/stride3d/stride Godot (offers C# as script language, using regular .NET) Various MonoGame and FNA games (which use vanilla .NET unlike Unity, there was even a game on Nintendo Switch with private FNA fork). From the top of my head, I'm sure there are many others.

deleted 2y ago

[deleted]

blinkingled 2y ago

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.

Hizonner 2y ago

[flagged]

tasty_freeze 2y ago

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.

lawn 2y ago
Actually, moving to a memory-safe language should be a very high priority for developing a browser and the sooner they do that the better.
- TinkersW 2y ago
  Swift/C++/Zig all have the exact same level of memory safety, but anyone they said they aren't porting, sounds more like writing new stuff in Swift and hoping the interop story is good enough.
stephc_int13 2y ago
It is just like when a video game team decide to switch or rewrite the game-engine mid-course. A huge red flag. Almost always kills the project or make it so late that it becomes irrelevant. C++ is not a perfect language, but it works, and they have experts on the team, what they are trying to achieve is difficult enough. Well, RIP Ladybird, I was hopeful about this project, this seriously makes me sad.
noirscape 2y ago
Depends on the approach. There's an odd benefit to C++ being the starting language; C++ is ancient and because of that you can make it interop with most other languages; in this case, the switch to Swift will probably simply mean replacing C++ modules (likely starting with the ones that cause the most memory bugs) with Swift modules and gradually switching things out since Swift has C++ interop[0]. It's less a "rewrite from the ground up" and more a "this is the main language we'll be using from now on". As for the reason to stop using C++; honestly what reason isn't there by now. The only reason to still use C++ in this day and age is if you're targeting very non-standard hardware or are developing videogames. The language is memory unsafe in a way that almost every other language isn't (like, even if you don't pick a language with an overly worrywart borrow checker, C++ is remarkably worse at memory management), the standard library is awful and it's stuck with the chain and ball of being a superset of C on it's leg, meaning that every reason why you wouldn't use C also applies to C++ (minus the "C isn't OOP" one). [0]: https://www.swift.org/documentation/cxx-interop/ https://www.swift.org/documentation/cxx-interop/

Decabytes 2y ago

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

pjmlp 2y ago
C# has a uphill battle against those that don't believe in systems programming languages with GC, despite several graphical workstations have been done in the past in such languages. Unfortunately freebie UNIX, and security was yet decades away to be relevant to governmental regulators, thus they never managed to gain enough mindshare to keep going. Additionally even with all the .NET team efforts, the technology remains mostly relevant to Microsoft shops. I seldom see RFPs from UNIX first culture companies, that quote .NET as possible delivery technology.
- layer8 2y ago
  GC still has the downside of higher memory overhead. While I’m not particularly a fan of Swift, this is a relevant argument for a general-purpose browser implementation.

BaculumMeumEst 2y ago

What happened to jakt?

rvz 2y ago
Very good question. Who knows.
hypeatei 2y ago
Contributions are still being made to it[0], but definitely nothing compared to when it was first announced. Seems essentially dead to me at least. [0]: https://github.com/SerenityOS/jakt https://github.com/SerenityOS/jakt
CxByte 2y ago
Regardless of where jakt goes, it would never be qualified for this; Ladybird is doing its best to get rid of everything home-built that is not the web-platform. (Also it's a really young language with <5 recurring contributors, of course it's not even on the radar :)

stephc_int13 2y ago

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.

dvektor 2y ago

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.

christophilus 2y ago

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.

stephc_int13 2y ago
I strongly disagree. This is not a justified decision, they just feel like it based either on vague and speculative reasons, or because they are funded to do so, I would not be surprised if they had discussions with the Swift marketing team.
- keybored 2y ago
  How do you know?
- gjsman-1000 2y ago
  Then build your own browser in Rust, start contributing to Servo, and who cares when a volunteer writes a browser in any language? Write a browser in COBOL for all I care. If it’s open source, it’s still a gift.
  - stephc_int13 2y ago
    Absolutely not. I don't know Rust and I think it is worse than C++ in many ways. This is a false dichotomy, they don't have to switch language mid-course.
    - JTyQZSnP3cQGa8B 2y ago
      I am very confused by your message. I know both Rust and C++ and think it’s an improvement in many ways. Why do you you think it’s worse without using the language?

pelagicAustral 2y ago

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?

deleted 2y ago

[deleted]

enragedcacti 2y ago

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.

zelphirkalt 2y ago

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?

bhokbah 2y ago
The language is controlled by the Swift evolution process but Apple engineers are basically the only ones contributing and submitting proposals.

losvedir 2y ago

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.

ksec 2y ago

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.

diimdeep 2y ago

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.

frankjr 2y ago
> meanwhile still long on Jai On a language which doesn't have any safety, doesn't plan on implementing basic features such as incremental compilation, tagged unions, async, or package management and others, and nobody is currently working on? Good luck.
- davikr 2y ago
  Well, you don't need incremental compilation if you have a fast compiler. I can't speak for the other points, though.

frankjr 2y ago

Does anybody know if the upcoming version resolves the compilation time issues? https://danielchasehooper.com/posts/why-swift-is-slow https://danielchasehooper.com/posts/why-swift-is-slow

throwaway1194 2y ago

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.