Conversation

I don’t think any programming language unveiled in 2022 should lack memory safety. We have to move on from the “it must be as fast as unsafe C” mindset, because the engineering cost of unsafe-by-default is so very high. Nice syntax and whiz-bang features don’t make up for it.
44
1,450
I’ll go as far as to say that a new language introduced now should also provide concurrency safety. Rust managed it. Pony did it a different way. Swift has a different take on it that’s rolling out incrementally. For new languages, this should be table stakes.
4
276
It takes an enormous amount of effort to bring a new language into the world and make it useful, to port code, reimplement core libraries. If you aren’t getting safety out of it, why incur that cost? Is the end result actually better, or just more pretty?
2
190
I’m subtweeting hard because I think y’all need to consider your end goals very carefully. You can chart a course that is safe-by-default with opt-outs. There are many designs out there to build upon and improve. Interop with C will be an opt-out, and that’s fine.
3
161
But think about the case where you are wildly successful and all the code you care about gets rewritten. Will you be happy with what you’ve achieved? Without memory safety, table stakes in this security-conscious world, I would not be. Don’t trade away what you can’t get back.
7
177
Replying to and
Doug, are you suggesting the idea of intellectual property should not be a trivial issue? I know inventors of brand new designs and manufacturing secrets that had their assets stolen by people within their trusted circles. I have been very lax at respecting my donation of time.
1
It took me a bit to understand the gist, but I think he means you’re so successful everyone switches to your language and rewrites the world, but it’s a missed opportunity because you didn’t give them safety
1
2