Hacker News Reader

Comment by SiVal | Hacker News Reader

My two biggest questions about V are 1) How is memory managed?, and 2) How is concurrency done?

"V has no runtime". No GC, but you don't have to manually release memory, like Rust but much easier. Sounds great. How?

And "no race conditions ever" and "everything is thread safe". You can do that with "no runtime" fairly easily if there's no goroutine-style concurrency. I didn't see any mentioned, but I could have easily missed it.

Those two aspects of the language are fundamental enough that I would certainly want to read about them near the top of any overview of the language.

View on HN

> 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 means you can have destructors, and they can manage resources other than memory, too.

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.

+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.

Reply on news.ycombinator.com