Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

By structuring the language around RAII and structured concurrency. More details in my great-great-great-great-grandparent post. [1]

tl;dr: If threads never exit before their descendants, and you only borrow an item in callees and in descendant threads, that would negate the need for a borrow a checker.

As for sharing an item across threads and still not having data races, this will be done by implementing something close to Rust's Send/Sync.

There will be ARC implemented by RAII, just like Rust.

Basically, the language will be built around structured concurrency, including the standard library.

Does that answer your question?

[1]: https://news.ycombinator.com/item?id=32907696



Ah, sorry, my bad, I should have read the whole thread in detail first instead of just skimming it. (:

So do you also intend to completely disallow mutation? Because that's the only way I could see this matching Rust's safety guarantees without actually having a borrow checker.

Say, for example, that you allocate a new string, and you take a reference to it, and then you append to that string within the same scope. This triggers a reallocation which will make that reference invalid. To make that safe you'd either need to have a borrow checker (to be able to detect at compile time that the reference was invalidated), or you'd have to disallow mutation (the act of mutating wouldn't actually mutate that string, but create a new one, leaving the old one alone until it goes out of scope).


Mutation will be disallowed in general, yes. It's a bit more subtle than that, but you get the gist.

In my language, there are strings, which are fixed size and cannot be reallocated, and string builders, which hide the actual string behind another layer of indirection to avoid the problem with mutation.

That sort of pattern would be used as necessary to avoid the problems with mutation in the same thread. And Send/Sync would take care of the rest across threads.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: