Comment by riskable

1 year ago

I was very excited about this but I must say I lost a lot of that excitement when I found out it's written in a non-memory-safe language (C++). Browsers are one of the few things we use every day that really need to be as safe and secure as possible so it was a huge disappointment.

The past 20 years of seemingly endless browser vulnerabilities due to memory management issues has left me... Skeptical. We're still seeing vulnerabilities based on memory management bugs in Chrome and the non-Rust parts of Firefox!

The sooner we stop making stuff like browsers in unsafe languages the better.

10 comments

riskable

Reply
quux  1 year ago

Andreas has looked deeply into moving both SerenityOS and Ladybird to a successor language but at the time didn't find anything out there that met their requirements so he started a new language named Jakt which unfortunately never got enough traction to move to.

One of the issues preventing them from adopting a language like Rust or Swift was the large number of 3rd party dependencies they would bring with them, this went against the "we build everything from scratch" ethos of SerenityOS. Now that Ladybird is forked from Serenity I hope they can revisit this decision.

It wouldn't surprise me if they adopt Swift. Andreas really liked it and in the time since it was last evaluated Swift's C++ interop has improved a lot.

MaximilianEmel  1 year ago

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

lufte  1 year ago

Isn't it possible to write memory-safe code in modern C++?

  • indrora  1 year ago

    Very. In fact it’s becoming harder to write non-safe c++.

    Stuff like nullptr has been in the spec for a while, unique_pointer and other stuff has worked its way in too.

    And Rust has plenty of ways to turn memory into Swiss cheese. Anyone who does not actively acknowledge unsafe and the fact you can embed C into rust is delusional.

    • raphyjake  1 year ago

      > It's becoming harder to write non-safe c++.

      It's becoming harder if you understand those features and use them correctly, on top of your knowledge of unsafe C++. Even then those are opt in, and it still takes a tremendous effort. I don't trust anyone using C++ correctly. It's just hubris at this point. You can use unsafe and call C but that's a smaller surface area to audit. Most big companies are transitioning to Rust for a reason. Some big companies were trying to replace C++ even before Rust was a thing.

      Why make a C++ browser now? What's the point?

oldpersonintx  1 year ago

part of the reason Ladybird split from SerenityOS was to break the "no dependencies" requirement...Ladybird will now be integrating with best-of-breed third party libraries. These will be primarily C/C++ authored I assume, so you are getting C/C++ no matter what.

zogrodea  1 year ago

[flagged]

  • whs  1 year ago

    In Rust most function take a reference to its argument, which means the ownership is shared. However, you can also pass non-reference to it which indicate that you wish to transfer ownership to the function (of course the caller must be the previous owner). Once the function take ownership there's no way to take it out unless they returned it, so it achieve the effect you're looking for.

    I heard some HTTP library used that to expose a state machine, so functions that cause HTTP header to be sent will take ownership and return a new value which no longer expose HTTP headers setter methods.

    For freeing memory or resources, the recommended way to do it is in RAII-style, with custom Drop implementation that will get called when the ownership is dropped instead of explicit close() or free()