The cross-platform version of the browser uses Qt

The version of the browser native to SerenityOS hopefully still uses the SerenityOS GUI libraries

It looks like they ported Qt to SerenityOS. I saw a package called "qt6-serenity". Perhaps they use the SerenityOS GUI libraries underneath. Does anyone know?

Ladybird is a browser based on SerenityOS technologies that uses Qt as the GUI framework. In SerenityOS, they have their own browser using the same underlying technologies, but a different in-house GUI framework.

WebKit and Blink are similar in how they have their different counterparts like QtWebEngine or WebKitGTK. The equivalent to WebKit and Blink in SerenityOS is called LibWeb.

Hmm, I was actually asking if SerenityOS released a "fork" of Qt that re-implements class QPaint to use their native GUI API. I assume yes. QPaint is turtles all the way down to paint pixels on any platform -- MacOS, Win32, X Windows, Wayland, Android, iOS, embedded (auto), etc.

Exactly, adding to that: they are NOT repackaging/rebranding chrome/chromium, they are actually building a browser.

The "modern" distinction would be they are building a browser + browser engine, while most fancy new browsers tend to just reuse existing engines, like Edge did with Blink.

I would really like to see a version with a C API capable of being embedded, there's a lot of places where a lightweight HTML renderer would be useful, plus it would make it easier to port to other hobby kernels.

Agree. This market is currently cornered by WebKit, which is easily the most language and UI framework agnostic engine there is. Blink might be similarly easy to embed but I’ve not seen it used that way — Blink embedding tends to be via Electron, CEF, or Qt, whereas you might run into WebKit in some random program written with any number of UI frameworks.

There used to be Gecko as an option here too, but Mozilla decided that it shouldn’t be usable outside of XULRunner and made it effectively unembeddable unless you’re willing to commit to XUL.

I experimented with this a while ago but didn’t get very far.

The rendering was done into a pixel buffer with inputs being passed though a few relatively simple C++ classes.

I think that a small embedded version would make for a great UI framework with minimal dependencies.

I care more about the choice of licence… and sadly enough, they went with a pushover/permissive one. This seems like the kind of project where copyleft is by far the better choice.

The are building a memorysafe language too : https://awesomekling.github.io/Memory-safety-for-SerenityOS/

and their goal is to use it to incrementally rewrite SerenityOS

Firefox has tons and tons of C++ to this day.

Yes, but they are replacing it bit by bit - I mean, they even started Rust for exactly that purpose. So (without being a huge fan of Rust) the decision to start a "greenfield" browser project in a memory-unsafe language is questionable IMHO...

It's not clear to me that they are replacing it bit-by-bit.

https://4e6.github.io/firefox-lang-stats/

I don't have an over-time series, but if you're willing to take my memory at its word Rust's percentage has hovered at around 10% for a while now. It seems to have actually gone down recently. Combine that with efforts like Servo being wound down and their team being let go, and it makes me wonder what the future of Rust looks like in Firefox.

If anyone can shed some light on this I'd be interesting to know.

I think they stopped the rebuild. They were previously building a new browser engine called servo. Some of that work made it through to Firefox gecko. And then team was gutted.

This chart looks like it could use some filtering for what constitutes a language used to build Firefox. It seems questionable that HTML is used to build 16 % of it. I suspect that is a result of test cases being included in the chart as it is based off of the whole repo. I checked out the repository and it doesn't have the GitHub language bar I see on other repos, so I can't click the HTML bit in it to filter down the HTML files in the repo and see if they are mostly tests or not, but it is hard to imagine they would be anything else. Maybe bits of the browser Chrome but still, that wouldn't be a whole 16 % I think.

> Yes, but they are replacing it bit by bit - I mean, they even started Rust for exactly that purpose. So (without being a huge fan of Rust) the decision to start a "greenfield" browser project in a memory-unsafe language is questionable IMHO...

Maybe, but the speed with which SerenityOS, its programs and the browser has been implemented, with so few man-hours thrown at it kinda displays why C++ was chosen over Rust.

There is no comparable project in Rust that demonstrates just how quick you can go from "nothing" to Full-Fledged OS, with applications, with a browser.

Just from the Serenity project (if you've been following it), it looks like C++ is about 10x faster to write performant and safe code in than Rust.

> There is no comparable project in Rust that demonstrates just how quick you can go from "nothing" to Full-Fledged OS

https://www.redox-os.org/

>> > There is no comparable project in Rust that demonstrates just how quick you can go from "nothing" to Full-Fledged OS

> https://www.redox-os.org/

Doesn't that sort of prove my point?

I dunno if you've tried both SerenityOS and Redox - I have, and SerenityOS is just more complete and usable as a daily driver than Redox[1].

Redox developed over 7 years has less functionality than SerenityOS developed over 4 years.

[1] They both have a long way to go before being completely usable as a daily driver, but Redox has a longer way to go than SerenityOS.

Sort of... but that could be due to a host of other factors besides which language is better: how good the core developer(s) are at community-building, how committed they themselves are to the project... hell, even the fact that one project used GitHub (which reduces the friction for developers who are already on GitHub to start working on the project), while the other one has its own GitLab might be relevant.

I think it was more like "they were" up to the point the Rust team got layed off.

But would they choose C++ if they were _starting_ today?

Note that SerenityOS started in 2018, they decided to use C++ for it, and even the newly created language for safer userspace (Jakt) generates C++ as target.

So maybe, Jakt will get used as well.

I do mostly Python on my dayjob, but for low-level side-projects I've gotta say C++ with the C++17 or C++20 standard it's way faster to iterate with than say Rust or even something like Zig.

For me iteration speed's a big selling point that (plus the fact that's easier to find contributors) might also be important for projects like these.

I’m puzzled by your comment. I am expert in Rust for almost a decade, but only mildly conversant in C++, and have no interest in actively learning more C++.

Rust seems to me far easier to learn and get going in due in major part to its incontrovertibly superior standard tooling.

I can’t see any place for any meaningful difference in iteration speed between the two, save that you may well have to iterate more in C++ due to memory safety bugs the compiler doesn’t catch.

As for finding contributors, I get the impression that Rust is considerably more accessible, and thus will increasingly find contributors more easily, as people that just love programming will actively choose to learn Rust far more often than C++. (For the current state of affairs, I think it’ll depend on what sort of contributor you’re looking for, in skill, industry, paidness, &c. Some segments will certainly go one way, and others certainly the other.)

Iteration speed with both Rust and C++ is abysmal. Builds take for fucking ever on large projects and it's just slightly less bad for small-to-medium and medium-sized projects.

With Rust, though, it's as if someone looked at C++ compilation times (not to mention resource requirements) and said, "I think we can find a way to make it worse."

Crystal says "hold me beer" :-D

But I still really like Crystal.

I have a hard time deciding where in this thread to drop this link, but maybe here is a good spot. Andreas has a video about this topic, and I believe it's this one: https://www.youtube.com/watch?v=vAZvTFoSIFU

Published on April 1st 2022 ;-)

yeah, it's probably the wrong video. Sorry. :( I know it's there though. This question came up and I know there was an answer for it.

The biggest problem IMO with using C++ when I tried the browser is that it crash, it crash a lot and I would imagine they are segmentation fault.

Last time I tried the browser, most crashes were the typical "not implemented yet" code paths. Some feature wasn't built yet, so necessary flags weren't set, so the program caught the invalid state and died.

I don't think I've ever seen a crash in either Serenity or Ladybird that I could attribute directly to memory management. For volunteer C++ projects, their memory management seems to have been done excellently. Using modern C++ features and things like error return types instead of null seems to be a key part in making the browser this good.

It's also worth mentioning that as far as I know Ladybird doesn't implement a JIT engine, using bytecode to execute Javascript instead. That should also make life significantly easier for memory management.

It's still a young browser and I'm sure there are some nasty memory corruption bugs lurking in the depths, but I haven't seen those yet.

Can you recommend a language that doesn't crash?

There are some languages that can be formally verified, and have themselves been formally verified.

Formal verification is a complete pain in the ass to do and there's a reason it's mostly done only in the most critical of systems, but if a program passes 100% formal validation, you're as close to crash free as you can possibly be.

I believe Ada and some other lesser used language sport well supported formal verification methods. You won't be able to use C/C++/Java/Rust it you're going for 100% formal verification though. There are attempts to bring the concepts to more commonly used languages (Frama-C, for example) but in my experience they're stuck in PhD-ware hell, great for writing papers but terrible for writing actual software.

Frama-C is used in production to meet normative requirements for critical software at least at Airbus (DO-178C), THALES (CC EAL6/7), EDF (ISO 60880). I think that they use actual software in production.

For example C/C++, with the help of something like: https://www.absint.com/astree/index.htm

But there are actually other languages that are better suited to such methods: More or less everything from the functional space is quite well applicable to those.

Any language that enforces memory safety is unlikely to crash because of a segmentation fault.

They will instead crash because of an uncaught exception or a panic handler - end result is the same.

By removing segmentation fault crash you have removed a large portion of unwanted crashes, the end result is very different.

But the crashes doesn't get removed, they get transformed into error types or exceptions and you still crash when you don't handle them.

This is only true if the language does not employ static analysis.

A no-go? Every major browser is written in an unsafe language, except for parts of Firefox.

This was a missed opportunity to build in rust. Servo was the previous engine that got abandoned midway. They should have continued that.

This browser isn't that ambitious. They're not trying to revolutionize anything, just to make a working one.

And they will optimize it later.