Ladybird browser to start using Swift language this fall
twitter.com
twitter.com
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 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
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.
Plus all systems languages with GC, including C#, can do C and C++ style memory management.
“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.
What is relevant is if one is actually skilled in using their tools, or should be doing something else instead.
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.
"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.
[1]: https://pages.cs.wisc.edu/~cymen/misc/interests/Bacon01Concu...
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.
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.
Here's the rough timeline of the work:
Initial issue https://github.com/dotnet/runtime/issues/11192 was submitted in 2018 and concerns general research direction on feasibility and profitability of EA.
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.
Further EA work is planned https://github.com/dotnet/runtime/issues/104936 and there are already initial experiments for .NET 10 like this one https://github.com/dotnet/runtime/pull/104906
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.
[0]: https://github.com/dotnet/runtime/pull/102808#issuecomment-2...
[1]: https://devblogs.microsoft.com/dotnet/performance-improvemen...
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"
https://www.microsoft.com/en-us/research/publication/uniquen...
"Simple, Fast and Safe Manual Memory Management"
https://www.microsoft.com/en-us/research/publication/simple-...
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.
(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).
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?
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...
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.
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.
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.
Write a browser in COBOL for all I care. If it’s open source, it’s still a gift.
I don't know Rust and I think it is worse than C++ in many ways.
This is a false dichotomy, they don't have to switch language mid-course.
I know enough.
Rust is extremely anti-ergonomic for me, and too complex, just as bad or worse than C++ in that regard.
Servo as a browser is (sort of) dead, though webrender still lives.
I remember when (back when the icon was a doge) it had an actual UI and could be used as a real web browser... that's all been stripped out now.
> 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.
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.
I would be careful with this thought. Open source is being used a marketing in disguise more often than not, especially here
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.
You either know something the rest of us don’t or you have made an emotional outburst in the form of an insult.
But they recently announced funding as a non-profit, as a few days later, they switch to Swift.
Following the money is a good way to explain seemingly irrational decisions, at least as a first order approximation.
It's possible Apple could be paying them to develop a rival browser but... why?
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.
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.
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.
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?
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.
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.
"Fork" is actually the word that means "their own". The "private" does indeed mean "proprietary" in this context.
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 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.
Popular applications that run on Linux are
Jellyfin: https://github.com/jellyfin/jellyfin
Sonarr (and other High Seas apps): https://github.com/Sonarr/Sonarr
Ryujinx: https://github.com/Ryujinx/Ryujinx (the kind of project that could likely compete with writing a browser in complexity)
Bitwarden (server): https://github.com/bitwarden
Garnet: https://github.com/microsoft/garnet (likely the fastest Redis implementation)
Stride3D: https://github.com/stride3d/stride
Godot (offers C# as script language, using regular .NET)
Various MonoGame and FNA games (which use vanilla .NET unlike Unity, there was even a game on Nintendo Switch with private FNA fork).
From the top of my head, I'm sure there are many others.
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?
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.
(Also it's a really young language with <5 recurring contributors, of course it's not even on the radar :)
I know that is a run-on sentence, but I need to get my exercise.
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.
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).
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.
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
==============================
For the community I'll pluck out this paragraph
> That being said, there is an overwhelming force in the Rust community that when anyone mentions they're having problems with Rust the language on a fundamental level, the answer is "you just don't get it yet, I promise once you get good enough things will make sense". This is not just with Rust, if you try using ECS you're told the same thing. If you try to use Bevy you'll be told the same thing. If you try to make GUIs with whichever framework you choose (be it one of the reactive solutions or immediate mode), you'll be told the same thing. The problem you're having is only a problem because you haven't tried hard enough.
I've experienced this same feedback when I was struggling with Rust. One time when I posted in the Rust subreddit about it seeking help and talking about my struggles, I got the unhelpful response of "I believe in people" as a dismissive response to my struggles. Admittedly this was years ago and I've since moved on from Rust, but the blog post is dated from 2024-04-26, so it appears the issues with the language still remain
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.
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.
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).
> 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.
It would have taken two seconds to be like "+1 Good catch man, merged."
http://itre.cis.upenn.edu/~myl/languagelog/archives/002748.h...
(and even singular "themselves"!)
which puts to rest approximately every argument I've ever seen against it.
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” -_-').
(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?)
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)
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.
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)
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.
So the use of he/she is banned by those projects?
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.
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.
This is literally the kind of toxic divisiveness he’s talking about. Can’t you see how this makes people want to have nothing to do with this issue?
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.
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 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).
It's a good point. These things always annoy me. Rust just happens to have the most vocal one these days.
(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.)
- 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 have plenty of my own beefs with rust that I won't go into here, but... it comes out on top for 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.
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.
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.
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.
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.
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.
Avoid near occasions of sin.
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.
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.
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.
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 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.
[0] https://news.ycombinator.com/item?id=36349576
[1] https://www.reddit.com/r/Cplusplus/comments/14aiwqj/cpprefer...
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.
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.
Rust isnt the only compiled language that provides memory safety by default. Swift does as well.
https://www.swift.org/migration/documentation/swift-6-concur...
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?
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.
I think you mean "one of which is Rust".