• stochastictrebuchet@sh.itjust.works
    link
    fedilink
    arrow-up
    53
    ·
    edit-2
    2 days ago

    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.)

    • dreugeworst@lemmy.ml
      link
      fedilink
      arrow-up
      37
      ·
      edit-2
      2 days ago

      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

    • Arthur Besse@lemmy.ml
      link
      fedilink
      English
      arrow-up
      12
      ·
      edit-2
      2 days ago

      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

      skeletor facts until-we-meet-again meme format, saying that every major web browser uses a rendering engine with a copyleft license

      • stochastictrebuchet@sh.itjust.works
        link
        fedilink
        arrow-up
        2
        ·
        2 days ago

        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.

        • Arthur Besse@lemmy.ml
          link
          fedilink
          English
          arrow-up
          12
          ·
          edit-2
          2 days ago

          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 :)

          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.

          • stochastictrebuchet@sh.itjust.works
            link
            fedilink
            arrow-up
            3
            ·
            2 days ago

            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.)

    • thann@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      11
      ·
      2 days ago

      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

      • LeFantome@programming.dev
        link
        fedilink
        arrow-up
        1
        ·
        3 hours ago
        1. using the Linux / BSD situation as a benchmark ignores a lot of history. I would argue that the BSD lawsuit was the deciding factor.

        2. 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.

      • pmk@lemmy.sdf.org
        link
        fedilink
        arrow-up
        8
        ·
        2 days ago

        By that logic proprietary licenses are best for desktop OSs because Windows has the biggest market share?

            • thann@lemmy.dbzer0.com
              link
              fedilink
              English
              arrow-up
              4
              ·
              edit-2
              2 days ago

              Actually macos was based off of BSD, but there were no basically contributions back to the community, so its whithered away. meanwhile linux is running in every sattelite and scientific insrument, it runs every router and nearly every server that are the internet. Microsoft google and apple all begrudginly make linux better while they make the operating systems they sell worse

    • Zacryon@feddit.org
      link
      fedilink
      arrow-up
      6
      ·
      2 days ago

      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.

      • dreugeworst@lemmy.ml
        link
        fedilink
        arrow-up
        18
        ·
        2 days ago

        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.

        • Zacryon@feddit.org
          link
          fedilink
          arrow-up
          2
          ·
          2 days ago

          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.

          • qqq@lemmy.world
            link
            fedilink
            arrow-up
            11
            ·
            edit-2
            2 days ago

            Rust prevents the things mentioned above in the compiler; there is no runtime cost for most of Rust’s safety measures. There is definitely a build time cost though.

            You can unsafe your way around anything, but that’s on the dev.

            • Zacryon@feddit.org
              link
              fedilink
              arrow-up
              2
              ·
              edit-2
              2 days ago

              I’m not just talking about performance costs. For example, compared to C++, Rust comes with reduced flexibility and increased complexity in certain cases.

              The borrow checker, for example, imposes strict ownership and lifetime rules, which can be difficult to work with, especially in complex data structures or when interfacing with existing systems. Sometimes, you have to significantly refactor your code just to satisfy these constraints, even when you know the code would be safe in practice. This can slow down development, require more boilerplate, and make certain patterns harder to express.

              C++ gives developers more freedom but expects them to take responsibility. That tradeoff isn’t just about raw performance; it’s also about how much control and convenience the developer has.

              • qqq@lemmy.world
                link
                fedilink
                arrow-up
                7
                ·
                edit-2
                2 days ago

                You said performance, so I responded to that. You can dislike Rust, that’s fine, but a lot of the things you’re saying aren’t correct. C++ isn’t memory safe, the person responding before showed that pretty easily. Rust doesn’t perform slower than C++, I responded to that claim. Rust provides tools to be memory safe, but the existence of unsafe I’d argue makes it also not memory safe, but at least better than C/C++. It also has tons of undefined behavior, just like those two.

                As for the personal opinion; you don’t have to like Rust. I actually have a very different view of the borrow checker and I don’t think I’ve ever “fought” it in a time when I was also doing something inherently safe. Every time I’ve had an issue with satisfying the borrow checker, which is rare, it’s been because I was doing something unsafe or interacting with C code, which Rust would argue is also unsafe. In my experience, it really eases the burden of programming actually and it makes debugging easier. It also makes design easier. As an example, I’ve been working on a very large C project recently and I ran into a bug where I was getting the wrong data printed out when I checked a value. After looking into it for like 15 minutes, I finally figured out that I had accidentally passed a stack pointer to a function that I wrote expecting a heap pointer. When the function went out of scope the data was garbage, but there was no crash and no compiler error. The borrow checker would have helpfully stopped me in my tracks there and saved that 15 minutes of debugging. The fact that it’s hard to implement your own efficient linked list or vector type has never been a problem for me really, especially not in comparison to the gains of not always having to keep ownership and lifetimes of pointers in my own head or in documentation that may go stale. I can’t express enough how helpful that is to my programming experience. C puts the burden of pointer lifetimes and ownership entirely on the developer. C++ makes that a bit better with the smart pointers at least, but those have some rules that aren’t enforced by the compiler but instead by convention.

                Basically I find the phrase “fighting the borrow checker” to be shorthand for “I can’t write C or C++ in Rust and I want to”. They’re not the same language and the constructs are different

                • Zacryon@feddit.org
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  2 days ago

                  That was not the only aspect, but yes, I mentioned that.

                  I don’t dislike Rust. I find it pretty cool. However, I disagree with the blanket statement “C++ isn’t memory safe”. C++ provides the tools for writing memory-safe code, but it does not enforce it by default. That’s a design choice: favoring flexibility over strict enforcement.

                  Yes, you can make mistakes that lead to memory issues. But that’s not a problem with the language itself; it with how it’s used. Stupid example: if you write code, which divides by zero at some point and you don’t make sure to check that, this is not the language’s fault, but your own.

                  Of course a language can accomodate for stuff like that and lift some of that burden from the user. Surely there are plenty of use cases and user groups for that. And that’s totally okay. Rust was designed with memory safety in mind to prevent common errors that occur to a lot of devs during the usage of C++, which is fair. But that doesn’t make C++ less memory safe. It is intentionally open and flexible on purpose. There are various programming patterns and even functionality within the STL that help to prevent memory issues.

                  So in other words: C++ is a tool, just like Rust. If you don’t know how to use the tool, that’s not the tool’s fault.

                  C++ makes that a bit better with the smart pointers at least, but those have some rules that aren’t enforced by the compiler but instead by convention.

                  You can always implement your own smart pointers. Besides that: which conventions do you mean?

                  Basically I find the phrase “fighting the borrow checker” to be shorthand for “I can’t write C or C++ in Rust and I want to”.

                  Nah, although it has its persk, I just think that it also imposes a rigid framework that sometimes forces you into cumbersome workarounds. With C++, you retain full control over memory management and can choose the best tool for the job. You’re not boxed into a strict ownership model that may force refactoring or add extra layers of abstraction. Instead, you have a mature ecosystem with decades of evolution that lets you balance safety and control based on context. Sure, mistakes can happen, but with proper practices and modern C++ features you can achieve a level of safety that meets most needs without sacrificing the expressiveness and efficiency you might require in complex systems.

                  • qqq@lemmy.world
                    link
                    fedilink
                    arrow-up
                    2
                    ·
                    edit-2
                    2 days ago

                    I disagree with the blanket statement “C++ isn’t memory safe”. C++ provides the tools for writing memory-safe code, but it does not enforce it by default.

                    This is such a weird take. C++ isn’t memory safe. The blanket statement is… true. You say as much in the second sentence.

                    With C++, you retain full control over memory management and can choose the best tool for the job. You’re not boxed into a strict ownership model that may force refactoring or add extra layers of abstraction.

                    You have full control in Rust too, at least to the same extent as C++. Rust isn’t memory safe either. Rust is just the opposite of C++ in the approach to safety: you opt in to being unsafe with the unsafe construct instead of being unsafe by default. They’re just different paradigms. I’d actually argue that you don’t have full control in either language unless you opt in to it, modern C++ tries very hard to abstract away memory management. You can write an entire program without a single new or malloc, which is pretty great.

                    Sure, mistakes can happen, but with proper practices and modern C++ features you can achieve a level of safety that meets most needs without sacrificing the expressiveness and efficiency you might require in complex systems.

                    This is just simply not true and is consistently proven incorrect every time an aspect of C++'s memory unsafety is exploited. I work in security and I still, in 2025, exploit memory corruption. The best developers money can buy still make mistakes with C and C++.

                    Besides that: which conventions do you mean?

                    The way you have to interact with smart pointers for example:

                    #include <memory>
                    
                    int main(int argc, char** argv)
                    {
                        std::unique_ptr<int> a = std::make_unique<int>(1);
                        std::unique_ptr<int> b(a.get());
                    }
                    

                    Double free, but compiles without warning. It’s convention to not use unique_pointer’s constructor, not enforced.

                    #include <iostream>
                    #include <string>
                    
                    int main(int argc, char** argv)
                    {
                        const char* c;
                        {
                            std::string a("HelloThisIsAHeapString");
                            c = a.c_str();
                        }
                        std::cout << c << std::endl;
                    }
                    

                    Use after free. No compiler error or warning, it’s convention to not maintain references to C++ string data, not enforced.

                    That’s all fine, whatever, but these are conventions. We’ve shot ourselves in the foot a million times and come up with our own guard rails, but the developer needs to know all of them to not make the mistake.

          • dreugeworst@lemmy.ml
            link
            fedilink
            arrow-up
            3
            ·
            2 days ago

            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

            • Zacryon@feddit.org
              link
              fedilink
              arrow-up
              1
              ·
              2 days ago

              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.

            • Zacryon@feddit.org
              link
              fedilink
              arrow-up
              1
              ·
              2 days ago

              It’s not just about runtime performance, but also about coding flexibility, and for example also reduction of boilerplate.

              • lolcatnip@reddthat.com
                link
                fedilink
                English
                arrow-up
                2
                ·
                2 days ago

                Ah yes, I love how C++ is has so little boilerplate. Sometimes I can even write several statements in a row without any!

                • Zacryon@feddit.org
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  2 hours ago

                  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.

      • lolcatnip@reddthat.com
        link
        fedilink
        English
        arrow-up
        9
        ·
        edit-2
        2 days ago

        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.

        • Zacryon@feddit.org
          link
          fedilink
          arrow-up
          1
          ·
          2 days ago

          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.

          • WhyJiffie@sh.itjust.works
            link
            fedilink
            English
            arrow-up
            1
            ·
            1 day ago

            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.

            • Zacryon@feddit.org
              link
              fedilink
              arrow-up
              1
              ·
              2 hours ago

              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.

          • lolcatnip@reddthat.com
            link
            fedilink
            English
            arrow-up
            3
            ·
            edit-2
            2 days ago

            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.

            • Zacryon@feddit.org
              link
              fedilink
              arrow-up
              1
              ·
              2 hours ago

              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.

      • Possibly linux@lemmy.zip
        link
        fedilink
        English
        arrow-up
        2
        ·
        2 days ago

        The good news is that the browser comes from Serenity OS which means it probably is lightweight and well written.