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.
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
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.
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.
Luckily, for the project of this type, you can use SkiaSharp (which is awesome) or simply implement a rendering back-end that targets OpenGL/Vulkan/DX/Metal. There are rich binding libraries with low/zero overhead to do so like TerraFX or Silk.NET or you can just do it directly.
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).
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?
> you choose a language for its ecosystem, not for the language itself.
Given that this is Ladybird, which came out of the Serenity OS project (which didn't allow any external code at all), it's not surprising that they didn't prioritize ecosystem when picking a language. I believe they're planning on being less strict about that with Ladybird, but the culture of independence is likely still there.
I have about 30k lines of Swift in my app + Matrix sdk, all heavily using async/await. Plus another couple kloc in a Vapor API backend.
Swift async/await is quite nice.
The Actor stuff is IMO way oversold - reentrancy issues make it not actually useful for the things that they claim, like querying a database. It’s still a useful construct to have, you just need to be aware of what it does or doesn’t provide.
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.
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.
> For those who are worried, Andreas is a thoughtful dude. This decision was not made on a whim.
Yes. But many terrible decisions are taken this same way.
> and I hope this decision pays off
It is terrible when we need to hope for something to succeed because we see that they are clearly doing something wrong but will do it that way anyway because they are strong-willed. Just take the obvious path everybody is pointing to.
Guy doesn't even know Swift yet, wants to rewrite a Chrome/Firefox alternative using it. That's a great recipe for failure. Alright, I need to find another browser project to be delusional about.
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.
Andreas has been talking about liking and exploring Swift since before he started working on Jakt [0] and if you look at Jakt you will clearly see it is heavily influenced by Swift.
I feel like the tweet explains their rationale pretty well... the main reason being memory safety. It's a constant overhead in both programming time and bug handling for them.
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.
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.
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
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.
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?
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.
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.
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.
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.
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.
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.
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?
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.
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.
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 :)
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.
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.
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).
I don't think this is a complete rewrite, though. Swift is specifically being picked for C++ interop so they can use their existing code. Andreas has stated from the start that any new language chosen has to consider an incremental approach of adoption into their codebase.
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.
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.
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.
I'd drop the "long-lived" and "short-lived" from the first two points. Rust is great for long lived programs, and is extremely clunky for managing any kind of object graph in general. The lifetime of the program has little to do with it, so I'm confused by those qualifiers. I've written plenty of Rust software that has run uninterrupted for years.
I've seen way more people complaining about Rust evangelism and toxicity than I've seen of Rust evangelism or toxicity itself, especially here on HN. Even "Rewrite it in Rust" is something I've mostly only ever seen as a denigrating joke (and usually in response to a project choosing to be rewritten in Rust, not even to calls to rewrite something in Rust). I'm starting to wonder if the Rust toxicity and evangelism are more meme than reality.
> I'm starting to wonder if the Rust toxicity and evangelism are more meme than reality.
Doubtful. If you're running a somewhat known FOSS C or C++ project, chances are you've had to close issues from Rust fanatics aggressively urging you for a rewrite, and shaming you if you object. Nothing has changed in that regard.
"Managing any kind of object graph in general" is just a hard problem. It's what tracing GC was actually invented for! (And indeed, that is still the only one-size-fits-all solution.) It's not fair to blame Rust for surfacing the issues instead of just sweeping them under the rug and letting them blow up in production.
IME in the last while on HN the Rust Evangelism(TM) debate has been brought up either unprompted or because someone argued that Rust was objectively better on some metric (like memory safety compared to another language). In the latter case someone says something that can be argued on its merits but then someone else decides to tone police about “evangelism”.
In this thread there are two Rust subthreads: someone brought up (and was downvoted) “why not Rust” out of nowhere (evangelism) and this one where we are discussing Rust Evangelism because GP quoted Kling on some separate tweet.
So yes. We mostly seem to discuss Rust Evangelism as a meta thing. Something that has supposedly definitely happened, or is happening somewhere else, just rarely right in front of us in the discussions at hand.[1] I think that qualifies as a meme.
As someone that likes Rust, but is decades away from the days I identified myself with any specific language, the Rust Evangelism Strike Force are the ones that spoil the party.
That is exactly the way to put off people, that initially could even be welcoming to hear about what the language is all about.
I realize this is not what people generally are referring to when they complain about the Rust community, but this is the part that annoys me.
Feels like every damn day I see people preaching the Good News of Rust, pointing to things as being the unique and sole property of their preferred language. Except those things have been around for ages, in other languages.
Memory safety? Invented by Rust!
Algebraic Data Types? Invented by Rust!
Funadamental FP constructs? Invented by Rust!
High performance? Invented by Rust!
If instead they just said that they enjoy having all of these things in a single language, well great. But instead it has to turn into a preach fest.
> - Clunky for long-lived programs that maintain large complex object graphs
Interesting observation...I have the exact opposite experience. Rust is especially amazing for long last program because you spend twice as much time developing it and then forget about it for the rest of your lives until you have to change something. And just by browsing the code, a flood of contexts come in because its expressed in the language fairly well (This function returns Option because ...., this function is generic over Read because ...)
I love Rust but have to agree that there is a lot of truth in all of those. The Rust community really should take a look at more welcoming and diverse communities like the Ruby and PostgreSQL communities. Not sure though what can be done to make handling long-lived state less clunky.
I think a lot of this is just rumors and maybe one or two high profile people. When I go to discord servers for rust and rust libraries, the help I get is as good as, if not better than support from companies I literally pay.
For years, whenever there was drama and shit-flinging in the OSS world, i looked up the people causing that on github and blocked them. Github has this feature that it warns you when you look at a repository where people you blocked contributed.
If you keep such a list, you'll easily recognize projects you better stay away from. For me, this was one of the reasons to keep away from Rust.
Interesting re complex projects. Compared to other langs I've used, rust gives me more confidence in maintaining and refactoring complex projects, maintaining state etc. I think this is due to the strict type checks, the helpful compile errors, and the ownership system. Maybe also due to the robustness of what I call struct-and-enum-oriented programming.
I have plenty of my own beefs with rust that I won't go into here, but... it comes out on top for complex projects.
> Compared to other langs I've used, rust gives me more confidence in maintaining and refactoring complex projects
In my humble experience, Rust gives me great confidence that my refactoring will likely be correct, but the type system makes refactoring anything moderately complex very difficult. I tend to paint myself into corners, and the compiler, in it's religious oath of correctness, won't allow a mortal like me to get away with it.
I guess you can dismiss that as a skill issue, but Rust feels like a language that is very tough to iterate with. It's probably something I will reach for when I'm sure of what exactly my program will do, and how it will do it.
It's definitely more clunky for complex object graphs. Making a useful directed graph with cycles is pretty annoying. Not impossible my any means (I'm currently working on a Rust project for audio graphs that allows cycles), but not nearly as easy as a GC language would make it.
- Excellent for short-lived programs that transform input A to output B
- Clunky for long-lived programs that maintain large complex object graphs
To rust purists the latter should be solved through composition of many of the former. This is what happens when constantly going on about the evils of state becomes one of your cultural norms.
That said I recently poked swift for non mac use and was not impressed by the status quo, and am not sure Apple are committed to the exercise. The core language is very nice though.
I wouldn't say all the Rust community is toxic. Then again, I'm not sure which Rust community he's referring to, I'm sure there are some toxic ones out there.
Ladybird and Serenity have a policy of not allowing any sort of expression of or reference to someone's sexuality or gender identity, as this is deemed "divisive" or "politicising". Rust does... not have that.
Choosing between Rust or Swift is a false dichotomy.
Switching programming language (or game engine) mid-course is a well known suicidal move.
Who is asking them to use a different programming language? I am not a C++ fan, but it is a lot less risky to stick to it than switching, and this is true for any large projects ran by experts.
C++ is a loaded gun, strapped to your body and aimed at your foot, with infinite bullets automatically firing every second, that requires you to constantly exert 25 lbs of force to tilt the gun and avoid hitting your foot.
Most of the time, you’ll be successful. However, nobody seeing your plight would be shocked if your foot eventually gets blown up. To claim this state of affairs is just fine because you’ve done it for years, pitiable.
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!
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.
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.
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.
The C++ interop thing I think is massive. But isn’t there also the problem that with Rust you can’t have the equivalent of shared pointers, so you can only have a single reference to one object (sorry I don’t really know Rust, just going from how this has been described to me) which apparently makes representing things like DOMs and abstract syntax trees an absolute nightmare?
RefCell is a shared pointer. Arc is a shared pointer with atomic reference counting (so it can be used between threads safely).
Both these constructs use the "clone" trait to iterate the reference count.
I make primarily concurrent and async applications these days so I use Arc a lot for accessing memory that is very large and shared many places, such as context.
I think the real problem is Rust has a lot of rules (that make sense for safety) that take time to understand and most people aren't patient enough to make good software because of corporate conditioning.
And cannot have linked lists either. When you make a compiler in rust, basically you give everything the same lifetime and drop the memory at the very end. That allows cicular references.
Or you use Rc, but that is against what purists want you to do.
For longer lifetime programs with complex models the borrow checker becomes harder
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.
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.
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
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.
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.
11 replies →
Luckily, for the project of this type, you can use SkiaSharp (which is awesome) or simply implement a rendering back-end that targets OpenGL/Vulkan/DX/Metal. There are rich binding libraries with low/zero overhead to do so like TerraFX or Silk.NET or you can just do it directly.
For example, Avalonia implemented Vulkan back-end some time ago, no C or C++ required: https://github.com/AvaloniaUI/Avalonia/pull/12737
Even then, you are absolutely not married to any of these GUI frameworks, but if are targeting desktop, then Avalonia offers great user experience.
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).
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
> you choose a language for its ecosystem, not for the language itself.
Given that this is Ladybird, which came out of the Serenity OS project (which didn't allow any external code at all), it's not surprising that they didn't prioritize ecosystem when picking a language. I believe they're planning on being less strict about that with Ladybird, but the culture of independence is likely still there.
1 reply →
I have about 30k lines of Swift in my app + Matrix sdk, all heavily using async/await. Plus another couple kloc in a Vapor API backend.
Swift async/await is quite nice.
The Actor stuff is IMO way oversold - reentrancy issues make it not actually useful for the things that they claim, like querying a database. It’s still a useful construct to have, you just need to be aware of what it does or doesn’t provide.
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-s...
[1]: https://docs.swift.org/swift-book/documentation/the-swift-pr...
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.
> For those who are worried, Andreas is a thoughtful dude. This decision was not made on a whim.
Yes. But many terrible decisions are taken this same way.
> and I hope this decision pays off
It is terrible when we need to hope for something to succeed because we see that they are clearly doing something wrong but will do it that way anyway because they are strong-willed. Just take the obvious path everybody is pointing to.
Guy doesn't even know Swift yet, wants to rewrite a Chrome/Firefox alternative using it. That's a great recipe for failure. Alright, I need to find another browser project to be delusional about.
it's not a rewrite
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.
Andreas has been talking about liking and exploring Swift since before he started working on Jakt [0] and if you look at Jakt you will clearly see it is heavily influenced by Swift.
[0] https://github.com/SerenityOS/jakt
Can you back up this claim? Knowing what I know of both Andreas and the Swift team I find this comment incredibly bizarre.
You either know something the rest of us don’t or you have made an emotional outburst in the form of an insult.
2 replies →
I feel like the tweet explains their rationale pretty well... the main reason being memory safety. It's a constant overhead in both programming time and bug handling for them.
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.
10 replies →
How do you know?
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.
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.
> 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?
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
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.
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?
The language is controlled by the Swift evolution process but Apple engineers are basically the only ones contributing and submitting proposals.
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?
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.
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
3 replies →
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.
> 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
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.
Doesn't Xcode ship with a closed-source build of LLVM (with patches) that you're referring to.
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?
peppermint_gum didn't mention a closed-source version of LLVM either. "Private" just means "their own" here.
1 reply →
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.
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.
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.
Are there any relatively well known non-Windows apps written in .NET? I guess Discord? Any others?
6 replies →
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?
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.
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.
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.
What happened to jakt?
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
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 :)
Very good question. Who knows.
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.
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.
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.
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/
I don't think this is a complete rewrite, though. Swift is specifically being picked for C++ interop so they can use their existing code. Andreas has stated from the start that any new language chosen has to consider an incremental approach of adoption into their codebase.
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.
Does anybody know if the upcoming version resolves the compilation time issues?
https://danielchasehooper.com/posts/why-swift-is-slow
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.
> 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.
Well, you don't need incremental compilation if you have a fast compiler. I can't speak for the other points, though.
Using Swift outside of Apple ecosystem seems like a bad idea, other platform are subparts.
Compiled Swift code cannot run on other platform? Curious, I never used it and I'm not aware of those limitations.
It can, the poster you're replying to is ill informed.
==============================
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
==============================
I'd drop the "long-lived" and "short-lived" from the first two points. Rust is great for long lived programs, and is extremely clunky for managing any kind of object graph in general. The lifetime of the program has little to do with it, so I'm confused by those qualifiers. I've written plenty of Rust software that has run uninterrupted for years.
I've seen way more people complaining about Rust evangelism and toxicity than I've seen of Rust evangelism or toxicity itself, especially here on HN. Even "Rewrite it in Rust" is something I've mostly only ever seen as a denigrating joke (and usually in response to a project choosing to be rewritten in Rust, not even to calls to rewrite something in Rust). I'm starting to wonder if the Rust toxicity and evangelism are more meme than reality.
> I'm starting to wonder if the Rust toxicity and evangelism are more meme than reality.
Doubtful. If you're running a somewhat known FOSS C or C++ project, chances are you've had to close issues from Rust fanatics aggressively urging you for a rewrite, and shaming you if you object. Nothing has changed in that regard.
3 replies →
"Managing any kind of object graph in general" is just a hard problem. It's what tracing GC was actually invented for! (And indeed, that is still the only one-size-fits-all solution.) It's not fair to blame Rust for surfacing the issues instead of just sweeping them under the rug and letting them blow up in production.
IME in the last while on HN the Rust Evangelism(TM) debate has been brought up either unprompted or because someone argued that Rust was objectively better on some metric (like memory safety compared to another language). In the latter case someone says something that can be argued on its merits but then someone else decides to tone police about “evangelism”.
In this thread there are two Rust subthreads: someone brought up (and was downvoted) “why not Rust” out of nowhere (evangelism) and this one where we are discussing Rust Evangelism because GP quoted Kling on some separate tweet.
So yes. We mostly seem to discuss Rust Evangelism as a meta thing. Something that has supposedly definitely happened, or is happening somewhere else, just rarely right in front of us in the discussions at hand.[1] I think that qualifies as a meme.
[1] https://news.ycombinator.com/item?id=41119392
As someone that likes Rust, but is decades away from the days I identified myself with any specific language, the Rust Evangelism Strike Force are the ones that spoil the party.
That is exactly the way to put off people, that initially could even be welcoming to hear about what the language is all about.
> Rust Evangelism Strike Force
I realize this is not what people generally are referring to when they complain about the Rust community, but this is the part that annoys me.
Feels like every damn day I see people preaching the Good News of Rust, pointing to things as being the unique and sole property of their preferred language. Except those things have been around for ages, in other languages.
Memory safety? Invented by Rust! Algebraic Data Types? Invented by Rust! Funadamental FP constructs? Invented by Rust! High performance? Invented by Rust!
If instead they just said that they enjoy having all of these things in a single language, well great. But instead it has to turn into a preach fest.
3 replies →
> - Clunky for long-lived programs that maintain large complex object graphs
Interesting observation...I have the exact opposite experience. Rust is especially amazing for long last program because you spend twice as much time developing it and then forget about it for the rest of your lives until you have to change something. And just by browsing the code, a flood of contexts come in because its expressed in the language fairly well (This function returns Option because ...., this function is generic over Read because ...)
That quote is describing the program's lifetime (how long a process runs), not the project's.
I love Rust but have to agree that there is a lot of truth in all of those. The Rust community really should take a look at more welcoming and diverse communities like the Ruby and PostgreSQL communities. Not sure though what can be done to make handling long-lived state less clunky.
What about the Rust community is not welcoming? Ruby has had its fair share of community controversies, so that's an odd choice for comparison.
1 reply →
> - Toxic community
I think a lot of this is just rumors and maybe one or two high profile people. When I go to discord servers for rust and rust libraries, the help I get is as good as, if not better than support from companies I literally pay.
For years, whenever there was drama and shit-flinging in the OSS world, i looked up the people causing that on github and blocked them. Github has this feature that it warns you when you look at a repository where people you blocked contributed.
If you keep such a list, you'll easily recognize projects you better stay away from. For me, this was one of the reasons to keep away from Rust.
3 replies →
Interesting re complex projects. Compared to other langs I've used, rust gives me more confidence in maintaining and refactoring complex projects, maintaining state etc. I think this is due to the strict type checks, the helpful compile errors, and the ownership system. Maybe also due to the robustness of what I call struct-and-enum-oriented programming.
I have plenty of my own beefs with rust that I won't go into here, but... it comes out on top for complex projects.
> Compared to other langs I've used, rust gives me more confidence in maintaining and refactoring complex projects
In my humble experience, Rust gives me great confidence that my refactoring will likely be correct, but the type system makes refactoring anything moderately complex very difficult. I tend to paint myself into corners, and the compiler, in it's religious oath of correctness, won't allow a mortal like me to get away with it.
I guess you can dismiss that as a skill issue, but Rust feels like a language that is very tough to iterate with. It's probably something I will reach for when I'm sure of what exactly my program will do, and how it will do it.
It's definitely more clunky for complex object graphs. Making a useful directed graph with cycles is pretty annoying. Not impossible my any means (I'm currently working on a Rust project for audio graphs that allows cycles), but not nearly as easy as a GC language would make it.
I'm really glad someone prominent has stated that.
The key rust problem relates to:
- Excellent for short-lived programs that transform input A to output B
- Clunky for long-lived programs that maintain large complex object graphs
To rust purists the latter should be solved through composition of many of the former. This is what happens when constantly going on about the evils of state becomes one of your cultural norms.
That said I recently poked swift for non mac use and was not impressed by the status quo, and am not sure Apple are committed to the exercise. The core language is very nice though.
Agree absolutely with every single point. Especially the last one.
I wouldn't say all the Rust community is toxic. Then again, I'm not sure which Rust community he's referring to, I'm sure there are some toxic ones out there.
There was a big fight on Twitter last month because of a comment he made 3 years ago (https://github.com/SerenityOS/serenity/pull/6814). I think that's closely related.
25 replies →
Ladybird and Serenity have a policy of not allowing any sort of expression of or reference to someone's sexuality or gender identity, as this is deemed "divisive" or "politicising". Rust does... not have that.
12 replies →
Basically the one that gave origin to Rust Evangelism Strike Force meme.
It doesn't matter if only a portion is toxic, because that portion can easily poison the well all on their own for everybody.
6 replies →
Choosing between Rust or Swift is a false dichotomy.
Switching programming language (or game engine) mid-course is a well known suicidal move.
Who is asking them to use a different programming language? I am not a C++ fan, but it is a lot less risky to stick to it than switching, and this is true for any large projects ran by experts.
It was probably a condition of getting funding.
In the NGO world using or funding greenfield C/C++ is a great way to make yourself a social pariah I bet.
A corporation wouldn't care, because they're driven by what makes dollars and cents.
But in non-profits (which Ladybird chose to be part of) it's all about ideology.
The only way to get an exemption is if you're doing AI which he isn't.
C++ is a loaded gun, strapped to your body and aimed at your foot, with infinite bullets automatically firing every second, that requires you to constantly exert 25 lbs of force to tilt the gun and avoid hitting your foot.
Most of the time, you’ll be successful. However, nobody seeing your plight would be shocked if your foot eventually gets blown up. To claim this state of affairs is just fine because you’ve done it for years, pitiable.
2 replies →
The last one is so very true
He's not wrong.
I wouldn't be surprised if it is true that the community is toxic, but I myself haven't really seen it
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!
6 replies →
[flagged]
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.
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.
> 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.
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.
1 reply →
Swift is memory safe.
The C++ interop thing I think is massive. But isn’t there also the problem that with Rust you can’t have the equivalent of shared pointers, so you can only have a single reference to one object (sorry I don’t really know Rust, just going from how this has been described to me) which apparently makes representing things like DOMs and abstract syntax trees an absolute nightmare?
RefCell is a shared pointer. Arc is a shared pointer with atomic reference counting (so it can be used between threads safely).
Both these constructs use the "clone" trait to iterate the reference count.
I make primarily concurrent and async applications these days so I use Arc a lot for accessing memory that is very large and shared many places, such as context.
I think the real problem is Rust has a lot of rules (that make sense for safety) that take time to understand and most people aren't patient enough to make good software because of corporate conditioning.
And cannot have linked lists either. When you make a compiler in rust, basically you give everything the same lifetime and drop the memory at the very end. That allows cicular references. Or you use Rc, but that is against what purists want you to do. For longer lifetime programs with complex models the borrow checker becomes harder
1 reply →
there are also classical shared pointers in rust: https://doc.rust-lang.org/std/cell/struct.RefCell.html
> specifically guarantees memory safety which is Rust
I think you mean "one of which is Rust".
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.