[cryptonector]

  - Multi-threading that uses separate memory spaces, meaning individual threads can run at max speed with no GIL overhead etc.

Hmm? Does that mean that they are actual processes sharing no memory? EDIT: If so then that's a big downside. In Rust you get thread-safety for traditional, shared-memory threading/concurrency. Ideally you should be able to get as good as Rust for threading. Ultimately, I think it all depends on this:

  - Compile time reference counting. This does an analysis similar to the Rust borrow checker to infer lifetimes, but unlike Rust doesn't make the programmer jump through hoops.

I mean, that would be a huge win, but there must be a trade-off. Can you elaborate?

[Aardappel]

This does not mean separate processes, it simply spawns one "VM" per thread. Lobster VMs are pretty light weight (just a self contained object that has everything for a program to run). The advantage is that everything inside one VM can be single threaded, down to memory allocator. The threads then communicate by sending each other lobster values, similar to a "tuple space". I personally think this explicit communication style of concurrency is safer and easier to use than shared memory concurrency.

As for the lifetime analysis, see some sibling comments: I need to do a good write-up of the algorithm. I wasn't anticipating this HN post :)

[cryptonector]

Ah, OK, sure. And I assume that Lobster compiles to bytecode then, that gets interpreted?

[brianpgordon]

Even if it does mean separate OS processes (which I doubt), keep in mind that on Linux basic POSIX threads are basically just processes with some shared memory mapped in. There's no real performance difference.