I’m OOTL. Are these actual issues people have with the project?
C++ might not be as memory-safe as Rust, but let’s not pretend a Rust code base wouldn’t be riddled with raw pointers.
BSD tells me the team probably wants Ladybird to become not just a standalone browser but also a new competing base for others to build a browser on top of – a Chromium competitor. Even though BSD wouldn’t force downstream projects to contribute back upstream, they probably would, since that’s far less resource-intensive than maintaining a fork. (Source: me, who works on proprietary software, can’t use GPL stuff, but contributes back to my open-source dependencies.)
I don’t know if it’s riddled with it or not, but what I (think to) know is that one of Rust’s goal is to minimize them. No need for raw pointers when handling lists and buffers most of the time.
BSD tells me the team probably wants Ladybird to become not just a standalone browser but also a new competing base for others to build a browser on top of
Don’t have time to factcheck so going to take your word for it. Interesting bit of knowledge! Honestly wouldn’t have thought that. How else are Chrome, Edge, Brave, Arc, Vivaldi and co getting away with building proprietary layers on top of a copyleft dependency?
I’m no legal expert. All I know is that when I’m picking dependencies at work, if it’s copyleft, I leave it on the table. I love the spirit of GPL, but I don’t love the idea of failing an audit by potential investors because of avoidable liabilities.
The three currently-maintained engines which (at their feature intersection) effectively define what “the web” is today are Mozilla’s Gecko, Apple’s WebKit, and Google’s Blink.
After having their own proprietary engine for over two decades, Microsoft stopped developing it and switched to Google’s fork of Apple’s fork of KDE’s free software web engine.
Probably Windows will replace its kernel with Linux eventually too, for better or worse :)
How else are Chrome, Edge, Brave, Arc, Vivaldi and co getting away with building proprietary layers on top of a copyleft dependency?
They’re allowed to because the LGPL (unlike the normal GPL) is a weak copyleft license.
So Chromium is based on Blink, which is LGPL – a less viral GPL. Hence, it can serve as a dependency in closed-source software.
As to the shared heritage of these well-established projects – I don’t know how else to interpret it other than a testament to the complexity of building a decent browser engine.
Btw, quick shout out to Orion, a rare WebKit browser by the makers of Kagi that’s apparently coming to Linux as well. I’m a monthly supporter. Even though I still mostly use Vivaldi, it’s been coming along really nicely. Proprietary software but idc. I appreciate their unspoken mission statement: pay or be the product. (No-one should be a product, obviously, but that’s capitalism.)
If you cant tell from just looking at the relative successes of BSD and linux that copyleft licenses are better than I dont know how to convince you of anything
using the Linux / BSD situation as a benchmark ignores a lot of history. I would argue that the BSD lawsuit was the deciding factor.
the Linux project is not representative of a typical GPL code base. It rejected GPL3 and features a rather significant exception clause that deviates from GPL2.
Clang vs GCC is probably a better metric for the role of the license in viability and popularity. Or maybe Postgres vs MySQL.
Why has nothing GPL replaced Xorg or Mesa or now Wayland?
Why hasn’t the MIT or Apache license held Rust back from being so popular? Why would Ubuntu be moving away from GNU Coreutils (GPL) to uutils (MIT)? How did Pipewire (MiT) replace PulseAiudio (LGPL)? How did Docker or Kubernetes win (both Apache)? Actually, what non-Red Hat GPL software has dominated a category in the past 10 years?
If the GPL is the obvious reason for the popularity of Linux, why would RedoxOS choose MIT?
This is not an anti-GPL rant.
My point is that choosing the GPL (or not) does not correlate as obviously with project success as you make it sound. It is an opinion that would require a lot more evidence.
I don’t like that “C++ isn’t memory safe”. It is. Users of that language are usually just not experienced or educated enough and therefore more mistakes happen.
I agree though, that other languages like Rust or Java can make it easier to prevent such mistakes.
In my experience, using smart pointers alone already solves 90% of memory issues I have to deal with. C++ improved a lot in that regard over the decades.
I agree that experienced users can write code that leaks less than in C, leaving aside the bottomless pit of despair that is undefined behaviour. But the the language isn’t memory safe, it doesn’t even prevent you from returning a reference to a local or helpnwitg iterator invalidation. you don’t have to jump through any hoops to enable making that mistake.
If a language prevents you from doing stuff like that, this always comes at a cost, since it has to do the work for you, almost always. This is additional overhead you can get rid of in C++ and therefore gain a lot of performance. But that again comes with more responsibility on the developer’s side and you might need to implement appropriate checks yourself where needed.
You’ve missed the context. There are occasions in Rust where you have to use more boilerplate code which you wouldn’t have to implement in C++ to that extent.
But saying that C++ is free of boilerplate is of course ridiculous, if you are not able to heavily leverage templates, CRTPs, macros and alike.
sure, maybe, but performance doesn’t matter for deciding if a language is memory-safe or not. And C++ isn’t memory-safe by any commonly used interpretation of that word.
You may of course decide that the downsides of memory-safety aren’t worth it for your use-case, that is a separate issue
I think it boils down, how we define “memory safe”. C++ is perfectly memory safe, if you know what you’re doing. A lot of people don’t. Which is why Rust was born. that doesn’t make C++ a memory-unsafe language. It just demands more responsibility from the user. A design philosophy that comes with a lot more flexibility than Rust can offer.
Which is fine. Both languages have their perks. But saying C++ isn’t memory safe, while Rust is, is in my opinion just plainly wrong. Besides, with “unsafe” Rust inherently already the door for memory issues.
Modern C++ practises and dev patterns can handle most memory issues in C++ pretty easily. Consider smart pointers for example, or RAII.
It’s not the language’s fault if it is used wrong.
You’re right. Thanks for the links. Although I still think that C++ provides the tools to enable memory-safe programming, I guess the lack of enforcement makes it inherently memory-unsafe.
If the standard is “you know what you’re doing and never make mistakes”, then all languages are memory safe. All you’re doing is arguing against memory safety as a concept by redefining the term in such a way that it becomes meaningless.
Which language would you say is not memory safe then? Is there any serious language out there where you should expect memory issues if you don’t make any mistakes?
I’m very experienced with C++and I still feel like I’m juggling chainsaws every time I use it. And I’ve personally run into into things like use after free errors while working in Chromium. It’s a massive codebase full of multithreading, callbacks, and nonlocal effects. Managing memory may be easy in a simple codebase but it’s a nightmare in Chromium. Tools like AddressSanitizer are a routine part of Chrome development for exactly that reason. And people who think memory management is easy in C++ are precisely the people I expect to introduce a lot of bugs.
I’ve a very long track record using C++ as well and I can’t share the feeling. I don’t say it’s alyways easy. I’m just saying that it’s doable and therefore whether the software is memory safe depends on the expertise of the devs.
Modern C++ practises, programming patterns and as well tools from the STL (or even your own implementation) make life a lot easier. If you don’t use them, that’s not the languages fault. In the end, how you use the language still matters a lot.
If you’d like to think less about memory management, go on and use Rust or C# or Java or even Python if performance doesn’t matter. That’s perfectly fine. This can come with other issues, like more boilerplate in the case of Rust for example, but in the end those languages are tools. Choose the tool which gets your job done.
whether the software is memory safe depends on the expertise of the devs
No. Just stop. If a language depends on the expertise of the developer to be free of memory bugs, then by definition, it is not memory safe because memory safety means such bugs are impossible by design. Quit trying to redefine what memory safety means. A program being free of memory bugs does not in any way imply memory safety.
I don’t think this solely depends on the level of experience. People make mistakes, and these kinds of mistakes are very hard to find. And don’t tell me you are the perfect coder that makes no mistakes, introduces no bugs.
I’m not. But in my experience, using memory safe programming patterns, classes and possibly additional testing and analasys tools do the job quite well.
But yeah. I changed my mind about this memory-safety-property. The lack of enforcement really does make C++ inherently memory unsafe.
I’m OOTL. Are these actual issues people have with the project?
C++ might not be as memory-safe as Rust, but let’s not pretend a Rust code base wouldn’t be riddled with raw pointers.
BSD tells me the team probably wants Ladybird to become not just a standalone browser but also a new competing base for others to build a browser on top of – a Chromium competitor. Even though BSD wouldn’t force downstream projects to contribute back upstream, they probably would, since that’s far less resource-intensive than maintaining a fork. (Source: me, who works on proprietary software, can’t use GPL stuff, but contributes back to my open-source dependencies.)
well, its possible to check if a rust equivalent would be riddled with raw pointers: just check the Servo code base.
personally I think its a good thing to have another browser implementation, regardless of specific choices they make about language or license
I’m curious. Why do you believe the last statement to be true?
Anti Commercial-AI license
Did you paste the wrong link?
I don’t know if it’s riddled with it or not, but what I (think to) know is that one of Rust’s goal is to minimize them. No need for raw pointers when handling lists and buffers most of the time.
Don’t have time to factcheck so going to take your word for it. Interesting bit of knowledge! Honestly wouldn’t have thought that. How else are Chrome, Edge, Brave, Arc, Vivaldi and co getting away with building proprietary layers on top of a copyleft dependency?
I’m no legal expert. All I know is that when I’m picking dependencies at work, if it’s copyleft, I leave it on the table. I love the spirit of GPL, but I don’t love the idea of failing an audit by potential investors because of avoidable liabilities.
The three currently-maintained engines which (at their feature intersection) effectively define what “the web” is today are Mozilla’s Gecko, Apple’s WebKit, and Google’s Blink.
The latter two are both descended from KHTML, which came from the Konquerer browser which was first released as part of KDE 2.0 in 2000, and thus both are LGPL licensed.
After having their own proprietary engine for over two decades, Microsoft stopped developing it and switched to Google’s fork of Apple’s fork of KDE’s free software web engine.
Probably Windows will replace its kernel with Linux eventually too, for better or worse :)
They’re allowed to because the LGPL (unlike the normal GPL) is a weak copyleft license.
Thanks for teaching me something new!
So Chromium is based on Blink, which is LGPL – a less viral GPL. Hence, it can serve as a dependency in closed-source software.
As to the shared heritage of these well-established projects – I don’t know how else to interpret it other than a testament to the complexity of building a decent browser engine.
Btw, quick shout out to Orion, a rare WebKit browser by the makers of Kagi that’s apparently coming to Linux as well. I’m a monthly supporter. Even though I still mostly use Vivaldi, it’s been coming along really nicely. Proprietary software but idc. I appreciate their unspoken mission statement: pay or be the product. (No-one should be a product, obviously, but that’s capitalism.)
What about safari? Doesn’t it still use webkit?
yep. (see my other comment in this thread)
If you cant tell from just looking at the relative successes of BSD and linux that copyleft licenses are better than I dont know how to convince you of anything
using the Linux / BSD situation as a benchmark ignores a lot of history. I would argue that the BSD lawsuit was the deciding factor.
the Linux project is not representative of a typical GPL code base. It rejected GPL3 and features a rather significant exception clause that deviates from GPL2.
Clang vs GCC is probably a better metric for the role of the license in viability and popularity. Or maybe Postgres vs MySQL.
Why has nothing GPL replaced Xorg or Mesa or now Wayland?
Why hasn’t the MIT or Apache license held Rust back from being so popular? Why would Ubuntu be moving away from GNU Coreutils (GPL) to uutils (MIT)? How did Pipewire (MiT) replace PulseAiudio (LGPL)? How did Docker or Kubernetes win (both Apache)? Actually, what non-Red Hat GPL software has dominated a category in the past 10 years?
If the GPL is the obvious reason for the popularity of Linux, why would RedoxOS choose MIT?
This is not an anti-GPL rant.
My point is that choosing the GPL (or not) does not correlate as obviously with project success as you make it sound. It is an opinion that would require a lot more evidence.
I don’t like that “C++ isn’t memory safe”. It is. Users of that language are usually just not experienced or educated enough and therefore more mistakes happen.
I agree though, that other languages like Rust or Java can make it easier to prevent such mistakes.
In my experience, using smart pointers alone already solves 90% of memory issues I have to deal with. C++ improved a lot in that regard over the decades.
I agree that experienced users can write code that leaks less than in C, leaving aside the bottomless pit of despair that is undefined behaviour. But the the language isn’t memory safe, it doesn’t even prevent you from returning a reference to a local or helpnwitg iterator invalidation. you don’t have to jump through any hoops to enable making that mistake.
If a language prevents you from doing stuff like that, this always comes at a cost, since it has to do the work for you, almost always. This is additional overhead you can get rid of in C++ and therefore gain a lot of performance. But that again comes with more responsibility on the developer’s side and you might need to implement appropriate checks yourself where needed.
Every source I’ve seen has shown rust and c++ to be very similar in terms of performance.
It’s not just about runtime performance, but also about coding flexibility, and for example also reduction of boilerplate.
Ah yes, I love how C++ is has so little boilerplate. Sometimes I can even write several statements in a row without any!
You’ve missed the context. There are occasions in Rust where you have to use more boilerplate code which you wouldn’t have to implement in C++ to that extent.
But saying that C++ is free of boilerplate is of course ridiculous, if you are not able to heavily leverage templates, CRTPs, macros and alike.
sure, maybe, but performance doesn’t matter for deciding if a language is memory-safe or not. And C++ isn’t memory-safe by any commonly used interpretation of that word.
You may of course decide that the downsides of memory-safety aren’t worth it for your use-case, that is a separate issue
I think it boils down, how we define “memory safe”. C++ is perfectly memory safe, if you know what you’re doing. A lot of people don’t. Which is why Rust was born. that doesn’t make C++ a memory-unsafe language. It just demands more responsibility from the user. A design philosophy that comes with a lot more flexibility than Rust can offer.
Which is fine. Both languages have their perks. But saying C++ isn’t memory safe, while Rust is, is in my opinion just plainly wrong. Besides, with “unsafe” Rust inherently already the door for memory issues.
Modern C++ practises and dev patterns can handle most memory issues in C++ pretty easily. Consider smart pointers for example, or RAII.
It’s not the language’s fault if it is used wrong.
https://en.m.wikipedia.org/wiki/Memory_safety
https://www.memorysafety.org/docs/memory-safety/
https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
https://www.cisa.gov/news-events/news/urgent-need-memory-safety-software-products
why do you want to redefine what the term means? why does it hurt to admit that C++ is not memory safe? It’s not about your weakness.
You’re right. Thanks for the links. Although I still think that C++ provides the tools to enable memory-safe programming, I guess the lack of enforcement makes it inherently memory-unsafe.
Point taken, I’ll stop saying that.
If the standard is “you know what you’re doing and never make mistakes”, then all languages are memory safe. All you’re doing is arguing against memory safety as a concept by redefining the term in such a way that it becomes meaningless.
Yupp. I’ve changed my stance on this.
Since C++ doesn’t enforce memory safe programming paradigms, it is inherently memory unsafe.
Which language would you say is not memory safe then? Is there any serious language out there where you should expect memory issues if you don’t make any mistakes?
No. I changed my mind just very recently throughout this discussion.
I agree now that the lack of enforcement of memory safe techniques in C++ makes it inherently memory-unsafe.
That doesn’t change the fact though that it’s possible to write memory safe code, if you know what you’re doing, use the right patterns, classes etc…
I’m very experienced with C++and I still feel like I’m juggling chainsaws every time I use it. And I’ve personally run into into things like use after free errors while working in Chromium. It’s a massive codebase full of multithreading, callbacks, and nonlocal effects. Managing memory may be easy in a simple codebase but it’s a nightmare in Chromium. Tools like AddressSanitizer are a routine part of Chrome development for exactly that reason. And people who think memory management is easy in C++ are precisely the people I expect to introduce a lot of bugs.
I’ve a very long track record using C++ as well and I can’t share the feeling. I don’t say it’s alyways easy. I’m just saying that it’s doable and therefore whether the software is memory safe depends on the expertise of the devs. Modern C++ practises, programming patterns and as well tools from the STL (or even your own implementation) make life a lot easier. If you don’t use them, that’s not the languages fault. In the end, how you use the language still matters a lot. If you’d like to think less about memory management, go on and use Rust or C# or Java or even Python if performance doesn’t matter. That’s perfectly fine. This can come with other issues, like more boilerplate in the case of Rust for example, but in the end those languages are tools. Choose the tool which gets your job done.
No. Just stop. If a language depends on the expertise of the developer to be free of memory bugs, then by definition, it is not memory safe because memory safety means such bugs are impossible by design. Quit trying to redefine what memory safety means. A program being free of memory bugs does not in any way imply memory safety.
Yes. I stopped now. I was hinted towards the usual definition of memory safe languages at another point in this discussion.
Although it is perfectly possible to write memory safe code in C++, I agree that the lack of enforcement makes it inherently unsafe.
I don’t think this solely depends on the level of experience. People make mistakes, and these kinds of mistakes are very hard to find. And don’t tell me you are the perfect coder that makes no mistakes, introduces no bugs.
I’m not. But in my experience, using memory safe programming patterns, classes and possibly additional testing and analasys tools do the job quite well.
But yeah. I changed my mind about this memory-safety-property. The lack of enforcement really does make C++ inherently memory unsafe.