> No GC, but you don't have to manually release memory, like Rust but much easier.

That description could fit Fortran 77.

You don't need destructors to release resources if you never release them.

Good question. I haven't mentioned memory management because it's not done yet. I know for sure there won't be a GC or reference counting.

I want to do something similar to Rust's approach, but much much simpler. It's not an easy task.

Right now the language handles very simple cases. Small strings are placed on the stack, local variables that are not returned are clean up automatically.

Globals are not allowed, function args can't be modified, so that helps a bit.

No GC, no reference counting, no manual memory management... Hmmm.... Not everything can be managed by RAII/SBRM... Let say I have a function which loads a complex document (like spreadsheet), does some changes, saves the document and then exits. Who will dispose this complex, dynamic document from the memory? This is the CORE question! If there is a no GC, no RC, no manual management solution to this, then I AM REALLY INTERESTED to know about it...

Yes, which is why I asked. He seems to be saying it will have the ease of GC with the performance of fully manual memory management with none of the costs of either. I don't see how radically simplifying Rust's approach can do that, but I don't have to. If he can find a partial solution that is significantly better, that will be great. I don't know if he'll succeed, but I'm rooting for him.

No GC means you can have destructors, and they can manage resources other than memory, too.

+1 for well-defined concurrency.

To me the central concurrency scheme is one of the defining features of a modern language. Go and goroutines, ES/Node and event-driven paradigms, Java and threads... That does not mean a language can't handle many types of concurrency, but it's good to be opinionated on a preferred concurrency scheme from the get-go and have native methods for dealing with intercommunication (ie. Go's channels).

I'm liking Go's built-in, lightweight goroutine approach a lot more than the other "afterthought" approaches, but I think you need a runtime to dynamically allocate the goroutines and adapt flexibly. I don't want to write one myself or link to some library. If V doesn't have some goroutine equivalent (or better) built into the language, I probably won't be persuaded by its other features. Sending bits of code off to do their various jobs concurrently with (almost) the ease of calling functions sequentially would be hard to give up.