Memory Safety for SerenityOS
awesomekling.github.io
Memory Safety for SerenityOS
1–10 of 23 posts
Re: Memory Safety for SerenityOS
#2Because someone will ask this question: yes, there was an attempt to use Rust, and it's archived here: https://github.com/ADKaster/serenity-rust/
Re: Memory Safety for SerenityOS
#3Seems 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!
Re: Memory Safety for SerenityOS
#4Woo. Big cheers for Andreas and the team bringing this in to the world. This will be a great hit.
Re: Memory Safety for SerenityOS
#5I 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.
Re: Memory Safety for SerenityOS
#6Interesting, I would have opted for clang build with better safety defaults turned on, but it is Andreas and the community decision to make.
Re: Memory Safety for SerenityOS
#7I 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…
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++.
Re: Memory Safety for SerenityOS
#8So it is something like HolyC but for Serenity?
Re: Memory Safety for SerenityOS
#9So it is something like HolyC but for Serenity?
HolyC++
Re: Memory Safety for SerenityOS
#10The feature list basically sounds like Swift.