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.
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.
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.
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.
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.
22 comments
[ 3.7 ms ] story [ 54.8 ms ] threadIn 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'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!
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.
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 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...
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.
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.
> 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...