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.
This is an old argument, and it’s well understood that “GC” by default refers to tracing GC and delayed collection. (Without delayed collection, there arguably isn’t any “garbage” in the first place.)
“Can do C++ style memory management” is very different from what happens when coding in the default idiomatic style of the language and when using existing libraries written in the language. What happens by default is a relevant consideration.
A definition can’t be right or wrong, it can only be popular or unpopular.
The definition of GC encompassing RC has fallen out of favour because it doesn’t capture the essential distinctions that people want to make: firstly, are cycles broken automatically? secondly, is there any tracing process happening behind the scenes?
Most people are happy to accept that CPython is GC because it does RC and cycle collection so you are managing memory thinking about paths from a root, but not Swift because you are managing memory thinking about an ownership graph.
In the past, people wanted to make a different distinction: is the CPU having to do extra work to keep track of a reference count. When CPUs were slow, this was an important distinction to make. Nowadays it’s a less important distinction so the definition has evolved.
> The definition of GC encompassing RC has fallen out of favour because it doesn’t capture the essential distinctions that people want to make: firstly, are cycles broken automatically? secondly, is there any tracing process happening behind the scenes?
"Yes" and secondly "no". Here's two different RC algorithms with cycle collection without tracing:
1. Concurrent Cycle Collection in Reference Counted Systems (Bacon & Rajan. 2001) [1]. Note it has no "global tracing" - which is what's meant by "tracing" in popular usage (right?).
2. Trial deletion, like as actually usable in Nim with "--gc:orc" [2].
If the definition of GC encompassing RC has fallen out of favour in popular usage, it's not because of RC having or not having these two particular properties.
The degree to which GC issues in the context of deterministic memory management apply to C# is incomparably lower to pretty much every other language that offers GC (especially JVM family) or a similar automatic memory management capability (except Swift or D).
However, D's GC is very rudimentary, and Swift pays very hefty performance price imposed by ARC for lower memory footprint and somewhat more predictable memory behavior.
In the context of writing something like a browser engine, both Swift and C# offer strong if different capabilities to control or avoid allocations, with Swift introducing Rust-like lifetime annotations for affine-like memory management, while C# relying on improving escape analysis in compiler and much better integration of plain structs and byreflike structs (they can hold GC-aware pointers called byrefs (`ref` keyword) to arbitrary memory) with generics for zero-cost abstractions.
Note that today, if I ever dared to even think about writing a browser engine, then the choice would have been Rust. But if not Rust, then C# would have been the next on the list. Some may suggest Zig but I have only brief knowledge of it so cannot comment further.
Until Zig has a good story for use after free, I wouldn't be considering it.
Regarding C#, there was some research work at MSR for improving escape analysis and IDispose usage via lifetime analysis, but seems to never have moved beyond proof of concept.
By the way, Midori internal presentation from 2013 is doing the rounds on twittersphere.
I don't think there was any work on escape analysis in current .NET related to Midori, at the very least not in public. However, there has been separate research and support for object escape analysis unrelated to this.
At the time, the results were very unpromising given compiler throughput impact: there were very few objects that were not escaping due to inlining limitations and (relatively) rudimentary approach to EA. In addition, there obviously was no impact on performance sensitive code that just used structs instead that are not reliant on fragile optimizations like this one.
Here, I would like to add a personal note that .NET teams are exposed to a much more well-behaved code and there existed (and still exists to an extent) bias that overlooks the nastiest and worst codebases that, no matter their issues and unnecessary allocation on every step, are an important optimization target. I think today there is a good degree of awareness and understanding of this bias, which drives further compiler improvements.
Back to EA. After initial research was done, the relevant code was merged into JIT - the feature was added around .NET 5 but remained disabled by default. Later on, it was occasionally in a broken state and generally not well validated against, given nothing used it besides compiler tests.
This, however, has changed in .NET 9. In order to understand why we first have to consider what were the changes in .NET's compiler in the previous versions.
Before .NET 7 and 8, JIT had nice but limited capability to perform something Java calls "scalar replacement" except for structs, the .NET name for this is "struct promotion". This feature "promotes" constituent struct fields to individual local values which are then stored in CPU registers or individual stack locations instead of "together" and being copied every time. This also included other common cases like treating single-field structs as an underlying field (making such wrappers effectively free). At the time, this optimization was great but nevertheless limited - there were restrictions on the amount of fields which could have been "promoted" and "enregistered" (up to 4 I believe?) as well as the depth - the quality of compiled code could easily regress if the target of promotion was nested within another struct, etc etc.
In order to address this, a new handling of struct promotion was introduced - "physical promotion": https://github.com/dotnet/runtime/issues/76928. This did away with the limitations of the past and enabled significantly better[1] handling of structs, allowing them to be optimized away, promoted without depth and count restrictions, propagate constants and assertions through struct fields, CSE more expressions on struct and more. This was a significant overhaul which pushed .NET's compiler output quality concerning structs way closer to the kind of behavior you would usually expect from GCC and LLVM.
At this point, I think you have an idea where this is leading to. Come in https://github.com/dotnet/runtime/pull/102808, an unrelated change which enabled the compiler to reason about propagation of addresses (object references, byref and unmanaged pointers) through struct fields. However, the importance of this change is that Steve (hez2010) noticed[0] that it may have closed the critical gap that previously prevented generalized optimizations enabling optimal struct handling from being applied to objects allocated on the stack. Once it was merged, it made the simpler scenarios EA was working for to produce the same optimal codegen you would see from structs as of .NET 8.
This and related discussions prompted further work on analyzing the most common unescaped allocation patterns and resulted in https://github.com/dotnet/runtime/pull/103361 by Andy Ayers. Once it was merged, it extended supported cases by previously limited EA capability, tuned inlining heuristics to make it light up more often and proved that the way it was handled as of the change was noticeably more profitable. It was subsequently enabled for NativeAOT and R2R as well: https://github.com/dotnet/runtime/pull/104411
As a result, .NET 9 will come with improved escape analysis capability, now enabled by default. It is still fairly limited but nonetheless an another change that incrementally adds to the nice "free" performance improvements everyone has grown to expect from bumping up a TFM version with each release for the last 7 years or so.
I don't claim this timeline/sequence of events is perfectly accurate but I hope it sheds light on how and why this optimization has been evolving in .NET so far.
Uff what a great reply, many thanks for the overview of ongoing EA efforts.
I was talking about this kind of research papers, there was one also about linear/affine types in a C# extension, similar to Spec#, System C# and others, but I can't get the title right to find it.
"Uniqueness and Reference Immutability for Safe Parallelism"
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.
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?
The original tweet was essentially complaining about boilerplate, which is all that's involved in managing most "complex object graphs" in Rust. If you think some minor boilerplate makes languages "extremely anti-ergonomic" I sure hope you're not writing Java.
> Work is still ongoing to make Servo consumable as a webview library, so for now, the only supported way to use Servo is via servoshell, our winit- and egui-based example browser.
A shame, really, since the Servo project was the source of some of the best macOS Cocoa/AppKit bindings for Rust.
Servo was never usable as a "real browser", and it's been revived since last year by Igalia. Looks like you should refresh your view on the project overall.
I had a 2018 (or 2017?) build on my Mac that was a native app using Cocoa/AppKit, which had a URL bar and could do most things in a functional capacity (like using Google services). AFAIK I tried a newer build back in 2020 or 2021 which had stripped out all of the browser chrome (like URL bar). Maybe they had intended to add it back in the future, but didn't get to do that before, you know, the layoff.
Servo the project was never revived as it was originally; the Servo name is being reused for what is actually a continuation of just the webrender project, which was part of the original Servo project, but is nonetheless much more limited in scope. I know it's confusing. Servo was once going to be a browser plus engine, and now it's just the engine.
Of course, officially, Servo has always only been a "research project" to "rethink the browser at every level of the technology stack", which primarily meant "layout engine", but then again, they did do such things as creating their own bindings to macOS Cocoa and AppKit which has no place in a layout engine, just to create, you know, a browser that demonstrates the engine. The browser that used the engine was part of the project.
Nowadays, the new Servo does have a demo/example project, but it's not meant for end use like the original Servo browser would have been. It just uses egui and all the other parts of the original Servo project have been essentially deprecated in favor of the new one, which is just webrender.
You are absolutely wrong about Servo being revived just a continuation of the webrender project. Igalia has been leading the effort for about 18 months now, focusing mostly on the layout engine (which is not webrender).
> who cares when a volunteer writes a browser in any language?
All the people that replied with something akin to "Why is this written in C++" when Ladybird was initially announced, which probably influenced the decistion to switch to Swift.
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.
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.
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.
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.
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.
I'm glad you've been spared. That doesn't really negate all the negativity and outright harassment that lots of people have experienced with the Rust community.
I think the best example is the continuous vandalization of cppreference [0][1]. I've never seen such behavior from another language community. There's also continuous mocking/brigading campaigns organized on reddit and mastodon.
"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.
Concurrency? Invented by Go! (quickly corrected by Elixir/Erlang strike force, but these, just like Golang, have worse throughput than a particular C family language I have a soft spot for).
Apologies, could not help myself as this response is amusing if sadly accurate (I do like Rust, but blind hostile evangelism tends to create the opposite to the desired outcome).
Elixir strike Force member here. Minor correction, concurrency wasn't invented by elixir, it was just perfected by it ;-D
(That's a joke for the record. Elixir mainly uses erlang's stuff, and it's based on the actor model, which was not invented by elixir or erlang. I do personally love it though, I believe it to be a great implementation.)
> - 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.
That sounds flawed to me. A large block list will disproportionately warn you about projects that are more open to any external contribution in general. Guilt by association is a weird standard for FOSS contributions. I certainly don't review the external lives of contributors on my repositories.
My point was just about my actual experience with the community versus what everyone says about it. There is a lot of excitement I've noticed which seems to bother some people but I've never had anyone outright call me an idiot or anything and I always get help when I ask for it.
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.
How is that related? What does it have to do with Rust? If anything, I'd say it shows that social media (and microblogging platforms like Twitter and Mastodon in particular) tend to be politically charged, toxic, and dogmatic.
I think it has nothing to do with Rust; probably someone first found it who just so happened to be part of the Rust community, and since the Rust community is full of 'the type of person who would be offended by such an interaction' (basically any queer person) there was naturally an explosion about it.
This is such a weird thread, sure it's a nit but grammatically a person of unknown sex should be either "he or she" or "they." And the latter is by far the preferred form by English writers regardless of political affiliation. It didn't become a political thing until Andreas made it political.
It would have taken two seconds to be like "+1 Good catch man, merged."
It could be an age thing. When I was taught grammar 40 plus years ago, for someone of indeterminate sex, “he” was taught as always appropriate, “he or she” was a somewhat clunky alternative that was situationally appropriate where you were stressing the gender neutrality, and “they” was just simply bad grammar which would get you bad marks. I’m honestly not sure when that changed.
Indeed. I was taught very directly that the singular pronouns were he, she, and it. The plurals were we, you, they. So grammatically if you were referring to a singular person of unknown sex, then you should use "it" .
Obviously using the pronoun "it" at some point became offensive, so is highly not recommended. But, (probably after having drilled into my head repeatedly that "they" is a plural) it seems very incorrect to my ears when "they" is used to describe a singular person. It also unfortunately comes with ambiguity sometimes. I've had misunderstandings where I used they as a singular pronoun to describe someone of unknown gender, and the person I was talking to took it as a reference to a plural, which at best creates confusion, at worst misleads.
Language is an incredibly hard problem, and it certainly doesn't help that as youth, we are drilled with supposedly objective truth regarding language, when in reality it is far less defined and more nebulous than than the teachers would have us believe. The generational gaps can already be tricky to navigate. Having different ideas of objective truth, especially regarding language, certainly does not help.
Because this often ends up with people talking past each other, never until a few years ago did anyone use singular they for a known, specific person. Shakespeare used it for unknown or nonspecific people.
In casual use, yes. In formal writing, the broad switch to acceptance of singular "they" is only about 15 years old. Up until that point it's the sort of thing that would be flagged by an editor, or lose you marks in an English paper.
I'd be shocked if that were universal over that time, given that even formal language has undergone many changes in attitude. Over hundreds of years, I bet that in many times and places it has not considered it a problem, particularly given its use in the King James Bible.
“They” is particularly convenient when discussing about people over the internet, because not only we don't have to assume the person's gender, but we don't have to assume if it's an individual or a group either.
And tbh using gender in pronouns is artificially annoying, and it's good to see English has a way out of it, like it got rid of giving genders to common objects like most European languages (“Non, it's La chaise, chair is feminine in French” -_-').
Languages hold complexity in different areas, but that doesn't make it artificial. Grammatical gender (and noun classes more generally) may seem redundant, but redundancy in language is quite common. It helps disambiguate, as it turns out speech (especially, but writing too) is a very lossy method of communicating.
(You seem perfectly happy distinguishing between animate/inanimate nouns and choosing "it" or "he/she/they" -- that's a difference not all languages make, but should we get rid of it in English too?)
1. "it" does not distinguish between animate and inanimate nouns:
The baby grunted again, and Alice looked very anxiously into its face to see what was the matter with it. — Lewis Carroll, Alice's Adventures in Wonderland
But he [Jesus] said to them, "It is I; do not be afraid." — John 6:20
2. gender distinction is artificial because it's not based on anything real, rather it's based on whether the "vibes" that a person (or an inanimate object in European languages) that you're referring to gives off are more feminine or more masculine. this "redundancy" creates all sorts of trouble for folks who are not comfortable with the "vibes" society assignes them with a particular gender at a given moment. the problem here is not that the speech is lossy, but that this particular "feature" of language demands that you convey the person's identity when it's almost always irrelevant in a way that's exclusive to gender (thank God nationalism wasn't invented when the language was forming)
1. Yes, as with many "rules" in language there are exceptions. I would find it a bit odd to refer to a baby as "it" in (current) English, though I do admit there are some situations where it wouldn't feel as out of place.
In my read of the Bible quote, it's not really referring to a person as "it" in the same way.
2. Grammatical gender has nothing to do with the "vibes" of an inanimate object - it's quite arbitrary, really. The problem you're associating here is much more with gender in humans, but we were talking about the grammatical construct applied to objects (like a chair as the grandparent mentioned).
So, as far as I understand it, gender pronouns are typically for referring to individuals. This means that whether to call a baby, or animal, by gender pronouns or object pronouns varies depending on the expectation.
('gender pronouns' includes singular they/them, which is a 'gender pronoun' in the way that it perhaps, if you will, implies the 'gender' of 'neuter'...)
I guess a generally understood term for this would be "humanization", although as someone who identifies non-human that still sounds somewhat exclusive, but regardless, that is what I generally observe to be the difference.
So, it's possible to refer to a baby or an animal as an object, if, in doing so, you intend not to assign that object any individuality; in other words, if you're referring to it in a non-individualistic way.
e.g. "I needed to change its diaper again today" ("dehumanizing"; I guess shows a lack of empathy, but not everyone necessarily feels empathy for the baby before it is more markedly an individual)
It's also possible to refer to a non-individual (such as an inanimate object) as an individual, which, in doing so, typically implies that the non-individual nonetheless has some sort of individuality or that you're specifically assigning it such.
e.g. referring to ships / other vehicles using 'she'; also, giving everyday objects individuality is a relatively common part of Japanese culture (which is part of why Apple's recent "Crush!" ad upset so many)
Typically, it's respectful to refer to people as individuals because they are. It is "dehumanizing" to suggest otherwise. (seriously, is there a better word for this?)
Some prefer to be referred to as objects instead, though; I know at least one like this. But those will typically specify it in some way, and it's rude not to refer to any one as an individual unless otherwise specified.
> not only we don't have to assume the person's gender, but we don't have to assume if it's an individual or a group either.
as someone with DID (formerly called Multiple Personality Disorder) this is actually kind of a nice bonus. (though people still often use he/him pronouns to refer to specifically me, which is fine)
Seeing this right now single-handedly turned me off from the project. Of all the possible (and more plausible) conclusions that the maintainer could have had, they deduced it to be political (which is arguable) and immediately became extremely defensive. Apparently women don't exist. It's an absolute failure of one's responsibilities as a maintainer -- arguably as a person -- to treat someone's goodwill with such disregard.
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.
You are right. I don't in fact know if that's what he means by calling the Rust community "toxic".
I've never seen anything like a bigoted word attributed to Andreas, by all appearences he is one of the most caring people in open source, and his character is obviously a big part of Serenity's success in attracting followers and contributers. But he does seem to be very insistent on "having nothing to do with the issue" (of inclusivity). His stated goal is to make a welcoming and inclusive environment, and ultimately I just think letting Pixie Ada put pride flags in xer bio will be more succesful at that than a don't ask, don't tell policy that seems mostly geared to not bother people who happen to fit in by default.
Not like that. A pull request that replaced "he" in documentation with "they" was closed with the comment "This project is not the place to advocate your personal politics".
Yeah, that was a pointlessly rude way to close the PR since it assumed ill intent. But tiny pull requests like that are rarely helpful since the one reviewing it will need to check what pronouns are used in the rest of the documentation to make sure the style is consistent so they just create busywork for maintainers even though those PRs are almost always done in good faith.
I definitely do not think he was leading by example here. Making assumptions aabout why people do PRs and denying them based on those is a good way to create a toxic community.
> the one reviewing it will need to check what pronouns are used in the rest of the documentation to make sure the style is consistent
Huh? Nothing in a software project will ever be perfect – code or docs — so this doesn't seem like a reasonable expectation. It's always a process of gradual improvement, and that can be true for a change like this too.
It matters how vocal and widespread that toxic portion is. In Rust's case, it's significantly larger and more visible and more toxic than I've seen in, say, the Python or C camps.
> so following that logic all wells would be easily poisoned
All camps are easily poisoned. What's important is how each community deals with the toxicity and whether they consider it acceptable or not. Rust's community has generally accepted this rabid part of it and tacitly accepted their behavior.
Eh, I don't personally consider the Rust Foundation to have anything to do with Rust The Language. I consider "the community" to be everyone who doesn't have official ties to the language. Is this incorrect?
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.
Well, there are indeed many ways to shoot yourself with C++, this is why having C++ experts on the team is a good thing. They are supposed to know how to avoid the traps and avoid being lured into the worst parts of C++ and OOP design style.
I have seen very good C++ projects using only the minimal amount of bullshit features, Omar Cornut's Dear Imgui comes to mind as an example.
As Swift beginners, they are less likely to avoid the bad idioms, but this is the kind of thing you only discover late, when the codebase is large enough.
Can you really tell me, that any C++ codebase doesn’t have memory safety bugs?
The last decades have shown that almost every C++ codebase has a bug somewhere, as long as you look hard enough. That’s not a good state of affairs.
C++ is a reactionary language. The programmer assumes they are an expert who can use it safely, there’s just a few exceptions or mistakes here and there and that’s normal.
Using memory safe languages is a programmer knowing they will mistakes, that they aren’t that smart despite their best efforts, and mitigating the opportunity.
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!
> 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
It's not specific to Rust at all, I remember hearing the same kind of talks when learning Java because I found OOP confusing.
And in fact most people saying that are right: most of the time people complain about stuff because they haven't internalized how it's suppose to work (as I was).
Don't get me wrong, there are plenty of valid criticism of Rust or Java (and OOP in particular), but at the same time in practice most of the people who complain aren't at the level of understanding and their criticisms aren't good.
Both are true at the same time:
- every programming language has terrible flaws.
- 99.9% of the criticisms you'd see online about a programming language in particular are garbage.
> It's not specific to Rust at all, I remember hearing the same kind of talks when learning Java because I found OOP confusing.
You're right, but that doesn't excuse it. And most languages don't have this as their first bullet point in their code of conduct
>We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic.
What is the point of a code of conduct if you can't rally the community around the first part of the first bullet point. If people are still experiencing toxicity on the level of other communities that don't have a code of conduct, then it's not working and the leaders of the Rust community should do something about it.
> the leaders of the Rust community should do something about it.
You should read the reaction of the Rust community leaders to the quoted article, and you'll see that they share your opinion that something must be done.
At the same time when you have people in the community saying politely and cheeringly that “you'll get over it when you've internalized the rules” what are you supposed to do as a mod? It obviously doesn't infringe the code of conduct even though it seems to have offended the author of the article.
Also, when what the people get pissed of about a community is “they don't want to admit it doesn't work” it's had to say that the toxicity is “people are still experiencing toxicity on the level of other communities that don't have a code of conduct”, by any means…
The goal of a CoC is to make sure nobody gets bullied or harassed, not that nobody will ever get annoyed by other people. You can't make sure you don't have idiots in your community, all you can do is making everyone behaving in a civil manner, which is already hard enough.
I think the loglog post is great and the community (as I perceived it) basically unanimously agreed that there are sharp corners and lots of room for improvement, especially in ergonomics.
Yep, communication is hard, and it's ... not an easy problem to be a volunteer based project, with a disavowed subreddit where most people get their first contact with the community.
I personally have no experience with Bevy or anything Rust 3D (well or any 3D really except for some tinkering with GLEW 10y ago :D), but the GUI problems are real. Documentation is scarce (no, vomiting types into a HTML page is not documentation, thx).
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
You can express linked lists efficiently in Rust using the GhostCell/QCell pattern. Yes it's clunky, but this is after all an area of active research in PL theory. As it is, most ordinary "easy" implementations of linked lists do not actually prove memory safety - it's a genuinely non-trivial problem, not a case of mere incidental complexity.
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.
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.