• xlash123@sh.itjust.works
    link
    fedilink
    arrow-up
    62
    ·
    5 months ago

    I was wondering why it was written in C++, but the FAQ already beat me to it.

    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 are actively evaluating a number of alternatives and will be adding a mature successor language to the project in the near future. This process is already quite far along, and prototypes exist in multiple languages.

    Glad to see they are open to using safer languages. C/C++ was great for its time, but we really need to move on from them.

    • jqubed@lemmy.world
      link
      fedilink
      arrow-up
      17
      ·
      5 months ago

      As someone who has done no programming since taking C++ in high school more than 20 years ago, what do you mean by safer language?

      • brenticus@lemmy.world
        link
        fedilink
        arrow-up
        37
        ·
        5 months ago

        C and C++ require more manual management of memory, and their compilers are unable to let you know about a lot of cases where you’re managing memory improperly. This often causes bugs, memory leaks, and security issues.

        Safer languages manage the memory for you, or at least are able to track memory usage to ensure you don’t run into problems. Rust is the poster boy for this lately; if you’re writing code that has potential issues with memory management, the compiler will consider that an error unless you specifically mark that section of code as unsafe.

        • Kajika@lemmy.ml
          link
          fedilink
          arrow-up
          10
          ·
          5 months ago

          I’m not sure why people keep pushing that myth on C++. It’s been a decade we have smart pointers. There’s no memory management to be done ever.

          Using the old ‘new’ is like typing ‘unsafe’ in rust. Even arrays/vectors have safe accessor.

          Am I missing something?

          • brenticus@lemmy.world
            link
            fedilink
            arrow-up
            7
            ·
            5 months ago

            It’s been almost a decade since I used C++ and had to verify, but after some quick searching around it looks like it hasn’t changed a ton since I last looked at it.

            You can use smart pointers, and certainly you should, but it’s a whole extra thing tacked on to the language and the compiler doesn’t consider it an issue if you don’t use them. Using new in C++ isn’t like using unsafe in rust; in rust your code is almost certainly safe unless marked otherwise, whereas in C++ it may or may not be managed properly unless you explicitly mark a pointer as smart.

            For your own code in new codebases this is probably fine. You can just always make your pointers smart. When you’re relying on code from other people, some of which has been around for many years and has been written by people you’ve never heard of, it becomes harder to be sure everything is being done properly at every point, and that’s where many of these issues come into play.

          • bamboo@lemm.ee
            link
            fedilink
            arrow-up
            1
            ·
            5 months ago

            The part you’re missing is that while C++ does have newer safer ways of doing memory management, all the old ways are still present, in wide use, and are easier. Basically, C++ makes it easy to do the wrong thing and hard to do the right thing, and most codebases are built around the wrong things. It’s often easier to just rewrite it in rust than it is to refactor an existing code base, so if you’re going to expend that effort why not do it in a language that has stronger safety guarantees, a better dependency and build management system, and a growing community?

    • refalo@programming.dev
      link
      fedilink
      arrow-up
      15
      ·
      5 months ago

      Hard disagree. Safe C++ code can be written quite easily these days. And better tools are coming out all the time.

      • twei@discuss.tchncs.de
        link
        fedilink
        arrow-up
        15
        ·
        5 months ago

        Yes, but there’s a difference between “you can write safe code” and “the compiler will come for your family the next time you make a mistake”

        • refalo@programming.dev
          link
          fedilink
          arrow-up
          9
          ·
          5 months ago

          rust isn’t a magic bullet either, it still doesn’t protect against a whole host of problems, like stack overflows, out of memory/bitflips, logic errors, memory leaks, unrecoverable errors/panics etc., and many projects are full of unsafe context rust code anyways.

            • Kajika@lemmy.ml
              link
              fedilink
              arrow-up
              2
              ·
              5 months ago

              And C++, just checked the wiki and the 2 example of openssh’s heartbleed and sudo, both in C. Not C++. As expected.

              • twei@discuss.tchncs.de
                link
                fedilink
                arrow-up
                2
                ·
                5 months ago

                By that logic scratch would be the safest language out there (or can you tell me the last time a program written/built in scratch had a bug that affected millions of ppl around the world)

    • LeFantome@programming.dev
      link
      fedilink
      arrow-up
      9
      ·
      5 months ago

      I wish it was not C++ but their implementation is quite interesting. Not only is it modern but they wrote their own standard library including error handling right down to the main function. It is quite nice for C++.

      All that came from SerenityOS. I hope they do not lose too much of it with the split. I mean, the Ladybird Project Leader authored most of it ( their C++ framework ) so it will probably stick. Harder to do when you start using other libraries though.