Commonly used languages, such as C and C++, provide a lot of freedom and flexibility
in memory management while relying heavily on the programmer to perform the needed
checks on memory references. Simple mistakes can lead to exploitable memory-based
vulnerabilities. Software analysis tools can detect many instances of memory
management issues and operating environment options can also provide some
protection, but inherent protections offered by memory safe software languages can
prevent or mitigate most memory management issues. NSA recommends using a
memory safe language when possible. While the use of added protections to non-
memory safe languages and the use of memory safe languages do not provide absolute
protection against exploitable memory issues, they do provide considerable protection.
Therefore, the overarching software community across the private sector, academia,
and the U.S. Government have begun initiatives to drive the culture of software
development towards utilizing memory safe languages.
Swift 5.9 introduced bidirectional interoperability with C++ to seamlessly bring Swift to more existing projects. Swift 6 expands interoperability support to C++ move-only types, virtual methods, default arguments, and more standard library types including std::map and std::optional.
C++ types that do not have a copy constructor can now be accessed from Swift 6 as non-copyable types with ~Copyable. And for those times when it’s useful to expose a C++ type with a copy constructor as ~Copyable in Swift for better performance, a new SWIFT_NONCOPYABLE annotation can be applied to the C++ type.
Swift now also supports calls of C++ virtual methods on types annotated as SWIFT_SHARED_REFERENCE or SWIFT_IMMORTAL_REFERENCE.
When calling C++ functions or methods that have default argument values for some of their parameters, Swift now respects these default values, rather than requiring you to explicitly pass an argument.
Platform Support
Swift is designed to support development and execution on all major operating systems, and platform consistency and expansion underpins Swift’s ability to reach new programming domains. Swift 6 brings major improvements to Linux and Windows across the board, including support for more Linux distributions and Windows architectures.
Why build a new browser in C++ when safer and more modern languages are available?
Ladybird started as a component of the SerenityOS hobby project, which only allows C++. The choice of language was not so much a technical decision, but more one of personal convenience. Andreas was most comfortable with C++ when creating SerenityOS, and now we have almost half a million lines of modern C++ to maintain.
However, now that Ladybird has forked and become its own independent project, all constraints previously imposed by SerenityOS are no longer in effect.
We have evaluated a number of alternatives, and will begin incremental adoption of Swift as a successor language, once Swift version 6 is released. (More background.)
For sure it is good because any other engine is direct or indirect an Google project, all development over the past decade was funded by Google. But this, to create a new indie engine in 2026 comes 15-20 years too late as to be capable to gain any minimum market share. The browser market is a brutal competition with over 70 companies victims in this battle, and I fear that Ladybird won’t be an exception.
Rust has its own non-security issues, you just won’t hear about it, as they’re being drowed out by “OMG, this Rust developer has PRONOUNS and CATS, what happened to free speech, why not everyone is a fundamentalist christian like me?” style smear by the likes of Brian Lunduke.
I’m not going to have interest in any new browser that’s written in security nightmare languages like C or C++.
NSA Releases Guidance on How to Protect Against Software Memory Safety Issues
then I have good news for you: https://linuxiac.com/ladybird-browser-team-selects-swift-as-preferred-language/
That is good news! I wouldn’t have guessed Swift, but I can see why Swift 6—which has been GA for a year—might make sense: https://www.swift.org/blog/announcing-swift-6/
From their FAQ https://ladybird.org/#faq
Sure, but any competition to Chromium is good
For sure it is good because any other engine is direct or indirect an Google project, all development over the past decade was funded by Google. But this, to create a new indie engine in 2026 comes 15-20 years too late as to be capable to gain any minimum market share. The browser market is a brutal competition with over 70 companies victims in this battle, and I fear that Ladybird won’t be an exception.
Fair concerns. I share the skepticism, but am still always happy to see projects like this attempting to swim against the current, late or not
https://servo.org/
Rust has its own non-security issues, you just won’t hear about it, as they’re being drowed out by “OMG, this Rust developer has PRONOUNS and CATS, what happened to free speech, why not everyone is a fundamentalist christian like me?” style smear by the likes of Brian Lunduke.