Have we not learned our lesson yet, or am I misunderstanding the situation? I believe it was a Microsoft study that linked unsafe memory access to ~70% of exploit chains.
> I'm curious
Is it really curiosity though? Because the answer is straightforward, the project started as a hobby, the developer picked whatever language they were proficient in. Andreas is open with the fact that he started Serenity OS and LadyBird as a rehab project. Put too much barrier in this setting (like learning a new language and all the ecosystem) and it might not happen at all.
> Is it really curiosity though?
I'm kind of annoyed at this whole train of comments ("I'm curious..."). In so many occasion I see something cool and the main comment track is "why hasn't this been writte in rust?" (or some other allegedly safe/better programming language).
It's like seeing a beautiful painting being painted and arguing about the kind of paintbrush the painter has used.
It's so sad.
No it is not. You don't use your browser for its artistic value (which is in the eye of the beholder). You also don't make an announcement for a painting.
This is more like using a non-inox screw in a high-humidity environment. Yes, it will hold on for a while. But it is objectively a bad choice. Non-inox may had been the only choice 300 years back, but this is 2024.
And writing a browser from scratch is a huge undertaking. When you invest resources in such a project, you probably want it to be more weatherproof than its C/C++-based predecessors. So it is quite reasonable IMHO to ask why C++ was chosen for this project.
There is no good safety language right now to write a browser in, except for c/c++. Rust might sound like an alternative but it's safety story is sad when compared to c/c++.
Ada might be a cool option, so is ATS.
If this is a work of art whose code is to be admired and only viewed as a creative work, fine I’m sorry I asked the question and that it was criticism of one’s vision.
However, if this is something that is intended to be “driven” by other users in the future I think it’s a perfectly acceptable question to ask why more modern safety mechanisms are not being employed. Maybe there is a rationale I’m unaware of or a reason why those mechanisms are not employed.
I believe you are right. But I also think that your phrasing is not very nice. It shows a lack of empathy and understanding and feels entitled.
You could convey essentially the same message but be way nicer to everyone involved, and that would be way more efficient.
If your ideal is a browser engine written in a safer language, and want to work towards that goal, phrasing things the way you did in your comment is one of the worst way to do it because you risk putting off people and they will associate this bad feeling to your idea. See how people react to comments about Rust.
Some of your options are:
- writing a browser engine yourself, in a safer language
- contributing to an existing browser engine like Servo
- convince projects to switch to a safer language, or to accept contributions in a safer language
- convince someone or a group of people to do those things
- fund such an enterprise
At this point, the world needs proof that a browser engine can practically be written in something else than C++, because it's what all three major engines are written in. There are strong evidences that Rust can be an option given the existence of Servo, but look how Ladybird is progressing so absurdly faster than Servo.
If you don't work yourself towards your goal, you can only humbly share your wish.
Lobbying is fine too, but you really need to make sure you don't make others hate your idea because of the way you communicate. Specifically in this topic, you need to take in account that many people are already annoyed by the numerous "why not Rust" comments, so you are walking on eggshells.
What's more, don't forget the global picture, and that security (although critical, we agree) is only one aspect. Security is irrelevant in a project that doesn't even exist. C++ is better than other languages for a lot of reasons in other aspects and you will need to address this, in the context of writing a browser.
Good luck in your endeavors, I hope you succeed, I believe it's a good ideal.
I’m happy there is someone out there genuinely interested in creating another alternative to the near monoculture that is web browsers. I hope that they gain traction in the open source community as well as wider adoption upon maturity.
I’ll try to follow the project development and maybe I can learn myself why other languages may not be as well suited as C++. It seems that language proficiency is the most common answer I’ve received besides earned criticism of the way I formed my question.
It's like seeing a beautiful painting and realizing the painter didn't use lightfast colors. In ten years the painting will not be beautiful anymore.
Yes, the painter / author put in a lot of work, and this deserves acknowledgement. But ones decision to use it or not is not only based on the amount of work put in.
it's not - it's a stock standard way to ask a question in bad faith.
I appreciate that the author birthed the project as a way to direct his energies towards more productive means. I don’t think it’s relevant to the question though.
Perhaps it's a similar situation for Ladybird.
>Memory safety remains a relevant problem: all Chrome exploits caught in the wild in the last three years (2021 – 2023) started out with a memory corruption vulnerability in a Chrome renderer process that was exploited for remote code execution (RCE). Of these, 60% were vulnerabilities in V8.
> V8 vulnerabilities are rarely "classic" memory corruption bugs (use-after-frees, out-of-bounds accesses, etc.) but instead subtle logic issues which can in turn be exploited to corrupt memory. As such, existing memory safety solutions are, for the most part, not applicable to V8. In particular, neither switching to a memory safe language, such as Rust, nor using current or future hardware memory safety features, such as memory tagging, can help with the security challenges faced by V8 today.
Technically no. But if you can decrease those 40% where it could help you can than focus more on the logic issues. Maybe.
As for the other 60%, they point to logic errors as the root cause, but that's true of all memory corruption bugs: they wouldn't exist if there weren't logic errors behind them. The actual difference here is that the vulnerabilities are either in the machine code generated by the JIT (e.g. type confusion), rather than V8's own code; or they're in code they insist must be memory-unsafe for performance reasons.
So the takeaway there should be that JS engines for hostile code should either not use a JIT at all, nor memory-unsafe code paths, or use stronger tools to verify the correctness of the JIT and those code paths. But hey, retaining the capability to speed up bloated web apps ever so slightly is more important that
This doesn't imply, though, that another project in C++ will share these traits.
At the end of the day, LadyBird is still a hobby project, so one of the main objective is to have fun which does not always coincide with rationality (although the decision to move on from NIH[1] is a sign that this might be changing).
But it was definitely started as a hobby project so your point still stands, mostly.
(to be clear, I'm not answering to the question of which programming language should be used to write Ladybird)
> Have we not learned our lesson yet,
"We"? Do you speak in the name of the developer? What an odd choice of pronoum.
Either way, if you are adamant about writing a new browser in your "memory-safe language" of choice, be the change you want made. Go ahead and write a new browser from scratch. Show the world how it should be done.
for the same reason people still use the English language, despite being full of crazy inconsistencies and being very hard to become a native speaker, coming from another language: proficiency.
Proficiency is one of the most, if not the most, valuable metric when choosing the tool you will use to take on some complex/daunting task.
(The success of legalese is still debated, but its existence is generally accepted)
BTW Rust (or any other so called "memory safe" language) is not the equivalent of legalese, it's the equivalent of using French because it's the "language of diplomacy" (that's why many English words come from French) instead of English.
If you're not proficient in French, French legalese won't save you.
If you are not proficient in French, you likely ought not to conduct diplomacy in French.
If you are not proficient in Rust, you likely ought not to achieve memory safety by writing everything in Rust.
- French itself does not add much value to diplomacy. The reason to use is that everyone else who does diplomacy is expected to know French (and probably isn't a native speaker which makes things a bit more equal). English is probably taking over there, like it has done in other domains.
- The recent C++ versions are not actively promoting shooting yourself in the foot like older variants, but they aren't exactly trying to prevent it.
- Rust is going out of its way to prevent writing memory unsafe code. It is still possible if you know what you are doing, but just trying out stuff at random is more likely to give you a compile-time error than undefined behaviour.
- Most programmers aren't very competent, not matter what they believe about themselves. With Rust they are less likely to commit serious errors. Or get anything done, but that's a separate discussion. The French will probably point out your pronunciation mistakes too before continuing discussion, but that's also not the point here.
Funny, given that the word diplomacy is a French word, together with embassy, treaty, alliance, passport and protocol :)
> Rust is going out of its way to prevent writing memory unsafe code
But if someone is not proficient in Rust it will only slow them down and they'll end up fighting the language and the compiler instead of using the language.
It's a common complain among non Rust programmers.
> Most programmers aren't very competent
I strongly believe Andreas Kling is very competent.
For the rest of us who are not him, incompetence does not go well in hand with Rust, which is a very complex language.
EDIT: pretending that a very proficient C++ programmer will chose Rust because "it's 2024" it's the same thing as pretending that they will chose Haskell, which is equally memory safe and also equally complex.
Why nobody ever recommend Haskell or Smalltalk?
It doesn't seem much like a discussion about memory safety to me, but rather promoting Rust.
This is true. But it only tells about the cultural dominance that France had at the time the convention started. If history had happened differently, Chinese, Hindi or something else could be in similar position.
> But if someone is not proficient in Rust it will only slow them down and they'll end up fighting the language and the compiler instead of using the language.
This is indeed the choice. Make it difficult to write code but more likely that the result is correct, easy to achieve high performance but risky (C++ and similar) or just accept the overhead of checking everything over at run time (JVM and CLR languages, etc). I would say there is a niche for the first.
> Why nobody ever recommend Haskell or Smalltalk?
I think at this point it's well known that the pure functional lazy evaluation model rules out too many useful data structures and makes it easy to introduce accidental complexity. As for Smalltalk, it seems (I've never actually used it) to me that most of its once unique ideas have been copied to current mainstream languages. It also seems to have a huge number of fragmented implementations and most of them seem to have a heavy runtime virtual machine.
French is still very much relevant, but it took centuries to make it less relevant than before to the point where we are now.
Rust in comparison is minutes old and there's no evidence it will dominate the field of system programming in the future. See: Ruby on Rails for web development.
> This is indeed the choice. Make it difficult to write code but more likely that the result is correct
I don't buy it.
Making it hard to write code it's nobody's choice, it's accidental complexity, that any sane language designer would avoid if possible, because it severely hinders the language adoption.
The opposite is also true: code easy to write will also be more easily correct.
Elixir is easy to write and will almost automatically be correct in complex scenarios such as distributed systems.
> pure functional lazy evaluation model rules out too many useful data structures
Rust is Haskell with a different syntax though and makes it very hard to write simple linked lists.
> most of its once unique ideas have been copied to current mainstream languages
same happened to FP, ROR and it's happening with Rust
Even Java is more functional than ever, because it's a good paradigm, not because it's a fad.
Again: this seems to me more promoting Rust than a discussion about memory safety and I am really not interested in that. So I'll see myself out.
This is true (for some values of minute). It is also why I was suggesting that C calling convention, HTTP etc, not Rust, would be the computing lingua franca. Now that I think of it, a few years ago TCP/IP would have been on the list but now with HTTP/3 it's not that certain any more.
> Rust is Haskell with a different syntax though...
This is quite bold claim, but if you have a rigorous proof beyond "all Turing complete languages are the same" I would be interested in seeing it. It's a pity you left.
> ...makes it very hard to write simple linked lists.
This is interesting in the light of the beginning of the sentence, because in Haskell linked list is the easiest data structure. Simple linked lists aren't always that simple though. There is a reason why they used to be a recurring technical interview question.
> Again: this seems to me more promoting Rust than a discussion about memory safety
Funny, to me this seems more about promoting JIT and garbage collection. Nothing wrong with that, as long as you admit that there are niches where those are a problem but memory safety is still useful. And so far there haven't been other serious language candidates for that niche.
Has the rise of these memory safe languages caused any shift in the proficiencies of the average developer?
I see a lot of younger people gush over python early in their careers but see a lot of Java/.NET in enterprise.
I personally grew up learning Delphi, PHP, and HTML. Java and .NET came later, but I rarely had a hand in initiating the projects so my language proficiency typically flowed with the job/project I was working on professionally.
That's a good question, but I have no answer for it.
AFAIK the data is missing or is inconsistent.
But I can link to you the obligatory Ken Thompson's "three weeks away from an OS"
Are there any other languages that im missing? If ATS has a prettier syntax, it'd be my candidate for writing a web browser in.
It is Azure that is more keen in adopting memory safe languages, and has the mandate that new systems code should be done using them.
And we all know how secure the average user's Windows computer is.
And Windows' security is so good that it's Windows who's powering tens of billions of servers, smartphones, IoT, appliances, routers etc. throughout the world? Oh, wait, no... These are all running Linux.
And the uptime. Let's not forget the uptime with patch tuesday.
Windows does not strike me as the ecosystem we should strive to immitate.
https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...
Those that have glass ceilings should not throw rocks.
> Have we not learned our lesson yet
Why are you speaking like this project is asking you to write code in C++? You are free to exclusively write Rust. Other people writing C++ has 0 impact on what you're writing or what lessons you've learned.
Interpreting JavaScript at all it at all is a problem. Ladybird's LibJS compiles it to bytecode and interprets that (which is usually better than intereprting the AST). The bytecode interpreter is written in C++, and it's still pretty damn slow - websites take a long time to load, and LibJS is the main bottleneck.
The reality is, modern websites throws so much junk at your JS implementation, that you basically need to JIT-compile it in order to have any sort of reasonable performance. And with JIT all memory safety guarantees are thrown out of the window - it doesn't matter if you write your compiler in Rust, C++ or a .NET language - if there's an exploit it's disproportionately more likely to be in the output assembly than it is to be in your compiler.
Browsers nowadays make a best effort, and they have a stack of other mitigations in case the JIT leaks: https://chromium.googlesource.com/chromium/src/+/main/docs/d...
That point is 50% FUD. A language which "maintains strict memory safe contracts" but has an `unsafe` keyword; or has a "native code interface", or uses libraries implemented in a different language, doesn't really strictly maintain its guarantees. And on the other hand, a language in which you can, in principle, load and execute arbitrary code from a string you got from the user, can be hardened very well by statically-checkable constraints.
So, it's a matter of degrees rather than absolutes. If you then add considerations such as programming paradigm flexibility and performance, C++ is very much a valid choice even for the use case of a browser.