Quote from: Syke on September 18, 2021, 07:22:55 AM

Quote from: Frink on September 15, 2021, 01:58:31 PM

#1 Rust ownership.. like I said I've automated this away so it'll have the performance of Rust, but be roughly as simple as garbage collected languages. Every once you'll need to worry about strong vs weak references but that's rare. Basically you don't need to think about it unless the compiler/IDE has a problem with the occasional edge case and there will be extra checks to make sure you didn't make a mistake in those cases.

Sounds interesting. Will it work in a multi-threaded environment without introducing race conditions, etc.?

Yes, it does. There is a "catch" when it comes to threading:for the most part, we thread your programs for you and you don't have to think about it.

Two ways threading works:
1) Functions are analyzed by the compiler and automatically parallelized.
A couple ways you can influence this parallelization:
"Atomic" objects may be created which work like very flexible go channels inspired by go. Basically any function called on an atomic object or variable read/write is done in a thread safe manner using something similar to locks (technically it's lock free for performance but you can imagine it like locks). While automatically parallelizing we'll provide a suggestions that if you were to mark certain objects as atomic, the parallelization can be more efficient but we require marking it atomic and don't automate this because it may not make sense in certain cases.

It's harder for a computer to estimate how many times a loop or recursion will execute than a human, so we allow humans to provide hints to the computer about this. Otherwise, computers can actually estimate more accurately and easier than humans.

2) Programmers can force functions to run in their own thread, again inspired by go and similar to go routines. This is particularly useful for say forcing a frontend and backend to run in parallel guaranteeing both get some CPU time.