Memory Safety for SerenityOS | Hacker News Reader

Memory Safety for SerenityOS

awesomekling.github.io

81 pointstodsacerdoti21 comments

Because someone will ask this question: yes, there was an attempt to use Rust, and it's archived here: https://github.com/ADKaster/serenity-rust/

What issues did you guys run into?

Andreas (creator of SerenityOS) recently answered this on his livestream[1] at the 5:00 mark.

In his opinion, he says Rust was not good at modeling object-oriented programs and that Serenity is primarily object-oriented GUI programs.

1: https://www.youtube.com/watch?v=9U9rv4TqY80

I wonder to what degree they have actually had problems with memory safety, vs. worrying because people are always telling them they will have safety problems.

Reference counting is useful at all extremely rarely, making its poor performance characteristics usually not a bother. Most usually, simple moving, and destruction when the thing with the pointer in it (unique_ptr, most commonly) goes away, does exactly what you want. But he must already understand this.

Maybe he wants a language for his, let us say, more casually skilled participants to keep them out of trouble, in less demanding corners of the system. Sort of what Google meant Go for.

Pike and team meant Go for that.

Their anecdote for creating Go in first place, was not wanting to wait for C++ builds at Google.

Google at large keeps being an heavy user of Java and C++.

I can actually comment on that fist question, having contributed to Serenity a bit in the past.

I did two big patches in the system, the first by adding websockets to the system[1][2] and the second (still ongoing) about allowing Browser to run in Linux directly[3]. Each went through several iterations trying to iron out all the lifetime and memory safety bugs I encountered, including in the first case one that got through the whole PR process and only got caught months afterwards.

The first change (WebSockets) took me a while to finalize, the main issue during its development was to solve the issues of the underlying socket never getting closed. This was actually due to RefCounted pointers getting implicitely captured by lambdas, which I solved by creating weak pointers for a bunch of them. This fix, however, ultimately broke the expected lifetime of the underlying socket by deleting it too early sometimes, which caused a sporadic disconnect issue. Now, this was not caught at all during the PR process, and was only found and fixed by Andreas a few months later[4]. This is directly a lifetime issue, and would have been caught by either a system that holds references directly.

The second change (headless-browser) took me at least twice as long than expected to do to make it work, due to some random crashes that I could not track down. This was ultimately diagnosed as me passing the wrong type of argument to the MemoryStream type, which accepted both BufferedSocket and TCP/TLSv1.2 Sockets directly but expected the behavior of BufferedSockets - it took two other people on Discord to debug this issue[5]. Note that that bug still allowed the headless browser to work for a little bit before it crashed, just not long enough that I didn't notice the bug. This bug was ultimately due to an invalid type constraint that I believe was left as-is as a workaround for another issue, but it could have been easily caught any language that didn't allow implicit reinterpretation of random memory data, so it ultimately is memory safety that lead to that happening.

Since I'm currently two for two in "memory safety-related issues" in my PRs, then yes I'd consider that, just like any other system, Serenity is having problems with memory safety - and that's just my personal experience. It's possible to do some things in C++ to try to limit these issues, and there's a lot of that being done in Serenity already. But in C++, all it takes is either a mistake by someone less skilled (me) or a workaround by someone who didn't think it'd be an issue, and the memory safety issues pop up again.

[1] https://github.com/SerenityOS/serenity/pull/6420

[2] https://github.com/SerenityOS/serenity/pull/6610

[3] https://github.com/SerenityOS/serenity/pull/13473

[4] https://github.com/SerenityOS/serenity/commit/1735d978ed2449...

[5] https://github.com/SerenityOS/serenity/pull/13473/commits/2d...

Thank you. Detail is always welcome.

It looks as if the new language would not have helped the first problem, unless it lacks lambda support, or prevents capturing by copy. On first impression, I would chalk that fault up to over-use of refcounting, something that the new language seems like it would make worse.

The second seems like bypassing the type system, something you would have misused "unsafe" for in the new language.

I may have misunderstood something.

Seems a lot like a stripped down version of Swift, similar syntax and ARC instead of a GC or borrow checker.

I'd guess that if C++ interop with Swift were better, Swift would have been a stronger contender.

In any event I'm excited to see where this goes!

Two years ago I told him:

> Well, you are held back by C++ obviously.

To which he replied

> Not in the slightest :)

Told you so :P

https://www.reddit.com/r/programming/comments/fda1z9/comment...

The feature list basically sounds like Swift.

So it is something like HolyC but for Serenity?

HolyC++

I have a feeling Terry would have objected to automatic memory management, and the idea of "safe" programming in general.

Woo. Big cheers for Andreas and the team bringing this in to the world. This will be a great hit.

Interesting, I would have opted for clang build with better safety defaults turned on, but it is Andreas and the community decision to make.

Congrats to the serenityOs team, can't wait to see where this goes

This blog post doesn't seem right to me. In the first part it says that the project is not an individual project anymore but the work of many. He then worries about the stability and maintenance of the project overtime in the long run. So as a result he makes the choice to create a language for fun to adress this issue instead of relying on an already existing stable and mature language. I fear that this decision will have the opposite desired effect on maintenability and contributions... I would have loved to see him being a little bit more open to other languages like Haxe, or D or go or any other language already stable and well maintened. It also impact the work of other contributors... But we will see how it plays out !

It's a project they built for fun. If they find the idea of building a new language alongside the OS fun, then they should do that! If I were in their shoes I would find that fun too!

I kind of agree. I love watching SerenityOS evolve and the momentum the project has, but I'm not sure inventing another language is the best way forward. I think the blog post could have been a bit more in-depth. All that being said, I'm still curious to see where all this is going and I hope Andreas will post a hacking session using this new language soon.

The project is an exception to every single other open source project imo.

And the reason is that they build every single thing from scratch. Not a single external dependency.

So I would argue, the community is already prepped for this and a new programming language would fit like a glove.

You took the words out of my mouth. I'm very curious to see where this language goes. It's a big project, but so is an OS, and they're doing just fine there. Even if SerenityOS or Jakt are never a household name, they're remarkably valuable in terms of seeing how people would do this, the things they think of, and how this community interacts and grows their project. SerenityOS is just as valuable socially as it is computationally.

Reply on news.ycombinator.com