[kgeist]

As I said, I may be wrong. I think I will try V some day to see it for myself (maybe I'll write an article about my findings). As you are the author of the language, can you comment on what is the state of the auto-free system? How is memory management implemented?

[amedvednikov]

I don't think it's correct making claims like "it's a toy language" and "crashes on trivial input" without actually trying it out.

You don't need an article to clone the repo, build the language in <1s and play with it.

Autofree works:

https://www.youtube.com/watch?v=gmB8ea8uLsM

But it's not finished yet. We saw a better performance with a GC (due to all the extra copying autofree has to do), and made it the default.

I've always been anti-GC, but V is so minimal and doesn't result in many allocations in the first place, GC works really well with it.

In the end the user will have full control over how they want to do memory management: manual, autofree, gc.

[cyber_kinetist]

Is all the extra copying that autofree has to do related to the lack of move semantics in the language? Nim had to introduce a bunch of new language constructs/semantics to support their ORC backend, which is the solution that’s similar to yours. (See https://nim-lang.org/docs/destructors.html.) I expected V to move in the same direction but hadn’t found any discussion of move semantics in the docs so I found it strange.

[amedvednikov]

V will never have move semantics. Complicates the language too much.

[vlang1dot0]

So how do you plan to make autofree work without move semantics, an ownership model or borrowing annotations? If your answer is "like Lobster", then how do you plan to deal with the semantic differences between those languages which the Lobster model relies on?

[kgeist]

>But it's not finished yet. We saw a better performance with a GC (due to all the extra copying autofree has to do), and made it the default

On vlang.io I can find this:

>Most objects (~90-100%) are freed by V's autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via GC.

So it's been 2 years and it's still unfinished, and you just use Boehm GC instead (from what I understood). Isn't your landing page a little misleading? This is the problem with V: a lot of grandiose claims but at the end of the day you use a GC used in every other toy language.

[amedvednikov]

But it says right there:

Note: right now autofree is hidden behind the -autofree flag. It will be enabled by default in V 0.3.

Using gc means it's a toy language? Got you.

[kgeist]

>Using gc means it's a toy language? Got you.

No, I mean it's a common characteristic of toy languages to use Boehm GC because it requires zero configuration to work, as it scans conservatively. It doesn't require you to emit stack maps or provide the GC with type metadata. Boehm GC means low effort (in regards to memory management). It's perfectly fine to use it, and it's an amazing library itself, but it contrasts with all the claims on the landing page (in the section "innovative memory management").

[bheadmaster]

A toy language is a term for a computer programming language that is not considered to fulfill the robustness or completeness requirement of a computer programming language.

[ylluminate]

Then by this definition and by example of what has been done with V so far, it's definitely no "toy language."

[bheadmaster]

I don't think V has proven its robustness or completeness. One thing that could change my mind is if one of the applications got completed and was actually usable.

For example, I'm really interested in the Volt thingy - a lightweight, multiprotocol chat application:

    https://volt-app.com/

But if you open the website, you can see that there is no Linux or Windows support, and most protocols are not yet implemented. I've searched for other projects written in V, and haven't found a single completed project.