HN Theater @HNTheaterMonth

Autofree exists and does work (https://youtu.be/gmB8ea8uLsM), however, it doesn't work where a user can have a complete lack of understanding about memory management like various GCs do or have never used it before. Autofree, as it is, also requires looking at examples of usage in various programs.

The website and documentation does explain the situation, for those that cared to actually read them. "Right now allocations are handled by a minimal and well performing GC until V's autofree engine is production ready." This should be enough to understand that autofree is WIP and not enabled by default (which is referred to in the documentation).

The other issue, is that people who have never used V or autofree (not even talking outright detractors), might interject or repeat uninformed opinions about the situation. Where those that have more thoroughly experimented with autofree and have used V or are in the V community, would likely understand the situation and history of it (have read other things about it on V's GitHub or asked about it on discord).

⬐ zamberzand

I understand that autofree is WIP. I read that part of the docs, and I have watched the demo.

But I don't really understand what the intended reading of the documentation is.

If I were to completely take these two paragraphs out of context, they are factually untrue:

> 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 reference counting.

> The developer doesn't need to change anything in their code. "It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything or expensive RC for each object.

So, what does this mean? Well, nothing, necessarily. If the context clarifies that these points are all untrue, then, the documentation could be considered perfectly accurate as far as I'm concerned.

However, when I asked if the intended reading of the documentation was that these points are untrue, the answer was--no, these points are all actually true.

I don't understand that position. These claims are straightforwardly untrue.

To me, your response is reinforcing my original proposed reading. That is--to me, your response indicates that I should read these claims as being false, and that the documentation is acknowledging them as false.

Now to me, that is a perfectly good response to my original comment. If this part of the documentation is not intended to be read as a statement of fact, that makes perfect sense to me, even though I do think it could be communicated better.

As it stands, though, I'm not really sure what I'm meant to get from this[0] comment.

[0] https://news.ycombinator.com/item?id=31955809

⬐ Tozen

When a person new to V reads the documentation (which they should be doing), they would also see the following.

"Note 2: Autofree is still WIP. Until it stabilises and becomes the default, please avoid using it. Right now allocations are handled by a minimal and well performing GC until V's autofree engine is production ready."

So, autofree (as a WIP) is not at this point working as intended, which is described by, "The developer doesn't need to change anything in their code. "It just works"..." I don't take this as any attempt to mislead or deceive, like you seem to be doing. The documentation is even telling people to avoid using autofree, as it's WIP.

Yes, there is a difference between how autofree is suppose to work versus how it is presently working. Yes of course, I can totally see how people get very excited about autofree, and want it 100% working or want its development accelerated. But, it should be obvious that at this point, when a person is using it, they are experimenting. When a person takes it upon themselves to enable autofree, in an alpha status language, they shouldn't be surprised there are issues.

Then bringing it back to what I had typed about earlier, using autofree at this point, requires that the person understands something about memory management and looks at examples of its usage. Particularly when a person is going to enable it, against the recommendation of the documentation.

⬐ zamberzand

It seems we are essentially in agreement on how the documentation is meant to be read, which is that the points it makes about autofree are not meant to be statements of fact.

⬐ Tozen

Not exactly, because what I'm saying is that the V website and documentation is explaining what autofree does, describing what autofree is, and how it works.

It appears you are implying that if autofree doesn't work perfectly as it is described, then that indicates a false claim or deception.

The counter to that (and what I'm saying) is that the website and documentation states that autofree is WIP and even recommends not to use it, and tells users that at this time GC is used instead. There is no deception, they are being clear. So if the user goes against the recommendation of the documentation, they should not be surprised that WIP autofree in alpha status V, is not working perfectly.

Furthermore, autofree does exist. We are not talking about a lie or false claim, where something is not in existence. Autofree does function, so here too, we are not talking about something that does not work at all. We are now talking about to the degree it is working or how well it works. Which on that point, the website and documentation both indicate WIP, so a user should not yet expect it to fully function.

I further elaborated that if you experiment with it, you may get autofree to work well. But, that can depend on: the program, can require experience using V, some memory management knowledge, and/or going through examples of V programs that use it. The expectation (and what those in the V community are aware of) is that as V goes to higher versions on its way to beta status, we will see better performing versions of autofree that requires less to no needed user knowledge about details.

V is not 1.0, so why so bothered that autofree isn't stable enough? Especially if the person is not even using V. Clearly the majority of V supporters and users are not bothered, and are finding V useful to them.

Autofree exists and somewhat works (https://youtu.be/gmB8ea8uLsM), it's a matter of perfecting it so that it requires minimum user knowledge about memory management. You can enable Autofree and use it, but the user must understand what they are doing and reference examples of code and programs that do use it.

So in the mean time, the V developers decided to experiment with and select GC as an alternative memory management method. That should not be a problem for a language in Alpha, nor for anybody "outside looking in", that understands language development. GC usage worked out great for them and the users, so they made it the default. Autofree and manual, would be the other options that users can choose, but they must enable those.

Furthermore, other languages like Nim, have multiple memory management options. I don't see people on HN getting so hot and bothered about that, just for some strange reasons, they seem oddly bothered by V adopting and having multiple options (GC, Autofree, and manual) instead of one.

It does work, and there's a 1.5 year old working demo:

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

0 GC is used.

None of the people who ever donated or are still donating felt they were being scammed. They often write about this here on HN.

⬐ wb13579

A demo, sure. But answer us this: does autofree ever crash, and does autofree ever leak?

⬐ amedvednikov

A 0.3 language feature that is marked as "not ready for production" on the website have bugs. How unexpected.

⬐ wb13579

That's what I thought.

Last time it seemed impossible, you said it was "work in progress" for years, and it turned out to be a lie.

This time it seems impossible, and it's been "work in progress" for 1.5 years. You can see why that's suspicious.

⬐ amedvednikov

You have a very strange definition of a lie. There's a working example. Anyone can run it and inspect it, it's all open source.

Autofree hasn't been a priority because of how unexpectedly well the GC is performing with V, but it will be finished.

All this is clearly stated on the website.

⬐ wb13579

Your claim of "(Work in progress) There's no garbage collection or reference counting. V cleans everything up during compilation. If your V program compiles, it's guaranteed that it's going to be leak free." was absolutely a lie. That's why you had to eventually fall back to reference counting.

The newer reference counting system has an example but it's very easy to conjure a working example of a system that has fundamental holes. When people use it for larger programs it crashes or leaks even today. Is that incorrect?

you heard wrong, it's been delivering quite well

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

no one has been scammed, whatever that means in opensource development

⬐ tene

Oh, that's really cool to hear! I'm glad that they've turned around.

So, where can I download the version of V with non-nullable references, no uninitialized memory, no mutation without call-site mutability annotations, that can compile 1M loc/sec, and a functional autofree?

⬐ amedvednikov

All the features you listed are there, maybe with bugs, which is expected for a 0.2/0.3 version, but they are there.

⬐ tene

If someone advertises their language as having no Null, no reading from uninitialized memory, and no mutation of immutable values, then I really do expect to be able to rely on those being completely absent. It is dishonest and shameful to say "No null" on the front page of the website when the developers are well aware of ways that their system fails to actually prevent null references.

If I'm buying a sandwich advertised as "no cockroaches", then I think it's appropriate to be pissed off about there being bugs in my sandwich, especially when it's clear that the sandwich shop knows all about the bugs in the sandwich and they just prefer to falsely claim their absence.

I would have no complaints if the developers would just describe these things as ambitious goals they haven't actually accomplished yet, instead of declaring that they've completed work they know they have not completed.

⬐ amedvednikov

No, you would look at the version of the language, realize it's 0.2 and not production ready yet.

⬐ tene

No, I really wouldn't, and don't. This is the kind of thing that reads to me as honest for a new in-development language: https://github.com/cruxlang/crux#status

Features are explicitly listed as working, partially done, and not yet implemented. You're really truly allowed to say "This doesn't work yet, but we're working on...", and it is legitimate to criticize people for choosing to lie instead.

⬐ amedvednikov

Well that's what it literally says on the website:

> V avoids doing unnecessary allocations in the first place by using value types, string buffers, promoting a simple abstraction-free code style.

> Right now allocations are handled by a minimal and well performing GC until V's autofree engine is production ready.

It wasn't vaporware back then, it isn't now.

Here's a 1.5 year old demo of V's autofree working:

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

⬐ vlang1dot0

Your demo includes code that uses manual memory management because of autofree bugs.

https://github.com/vlang/ved/blob/9b85e6291c9fe9135db1e300de...

⬐ super_flanker

Again!! Same video you've been throwing on whoever asks about "autofree", knowing very well that it doesn't work.

I asked this question before and was banned on discord, do you have control flow graph analysis anywhere in V? If not, how do you suppose your autofree engine would work flawlessly?

⬐ amedvednikov

Nobody bans for questions.

And the video I posted proves that it works. Keeping saying "it doesn't work" is ridiculous.

⬐ amedvednikov

Also, we now have an operating system Vinix, which uses autofree. Does that work as a proof for you or is that also not enough?

⬐ super_flanker

And that's why vinix [1] is full of manual free calls? That tells how good autofree is, isn't it? Can you compile v compiler with autofree? Last time I checked, you can't.

[1] https://github.com/vlang/vinix/search?q=free&type=code

⬐ delian66

You can actually compile the V compiler with -autofree.

The resulting executable however does segfault - try it with:

    ./v -autofree -o x cmd/v
    ./x version

You seem to talk a lot about things, that you are not well informed about.

⬐ super_flanker

> The resulting executable however does segfault

Doesn't give lot of confidence that it works, does it?

> You seem to talk a lot about things, that you are not well informed about.

Unlucky for you, it's not discord, you can't ban me here. So freaking deal with it.

⬐ delian66

I have never banned people on any platform.

Letting them speak and reveal how vile they are is better in my experience.

⬐ amedvednikov

Because surprise it's 0.2, and autofree has bugs, can you imagine?

⬐ super_flanker

Nowhere from homepage you get the clue that it's 0.2, do you?

⬐ amedvednikov

It says 0.2 right there in the center of the home page, under the big "The V Programming Language"

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.

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

⬐ paskozdilar

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

⬐ paskozdilar

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.

⬐ 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").

⬐ 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?

autofree demo:

V's compile time memory management demo. Running the Ved editor on an 8 MB file with 0 leaks.

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

⬐ lawl

Yes, we know, this is always your reply. We also know that boehm-gc is just temporary until you fixed the issues with autofree. Do let me know when that happens.

⬐ Tozen

There isn't any reason why Vlang can't have both autofree and boehm-gc. I don't understand the "must be this or that only" logic being applied to it. Other popular programming languages also have multiple memory management options, and so can Vlang.

⬐ amedvednikov

Well you said it doesn't work, which is not true. You also claimed this about half of the features on the list, which is also not true.

Regarding autofree/gc, here's a good summary from another comment here:

https://news.ycombinator.com/item?id=31060052

> Initially the goal was that this system would manage all memory for the programmer automatically, this goal has since moved to "manage 90% of objects in memory and use GC for the rest". I suspect we will see that number continue to drop as the author realizes this is intractable without whole program analysis (which they can't do and still hit their compilation time targets).

A demo of autofree with zero GC/RC:

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

> Other items are very much in an alpha state if they work at all.

Can you list items that don't work at all or are in alpha state?

Generics missing some advanced features like protocols doesn't mean they don't work.

And no I don't live in Sweden. You seem to get a lot of things about V wrong.

⬐ creata

Hey, in the unlikely event that you (or another V dev) are still here, could you explain roughly how V's memory management will differ from Swift's?

Swift uses reference counting and does analysis to allocate on the stack or elide reference count modifications wherever possible, and as far as can tell, the V docs suggest that it's going for the same idea.

⬐ vlang1dot0

You solved the memory management for one particular program written in exactly the style necessary to avoid leaks for the demo. You'll find as you fix other programs, you'll introduce UAFs into this one which is, I suspect, one reason your commit activity around autofree has basically dropped to 0 recently.

⬐ amedvednikov

> Can you list items that don't work at all or are in alpha state?

Nothing, as I expected.

⬐ vlang1dot0

No reply to the autofree comment? Unsurprising.

Since you want it so much, here you go:

- "No undefined behavior" -> How does V prevent this? V currently can't even generate well formed C code for all valid V so how do you prevent UB in the generated C? As of now, for any reference x in V, *x and ******x are both accepted by the checker. int32.MAX + 1 is instant UB yet V does nothing to prevent this. What is your plan to prevent UB in the generated C?

- Generics -> The example shown in your own docs expresses how "wip" this is (https://github.com/vlang/v/blob/master/doc/docs.md#generics). Why is `T.name` allowed? `T` can be literally anything since there is no constraint on it. You're obviously deferring type checking the function until it's monomorphized which is far more like C++ templates than "generics". How do you plan to deal with template bloat slowing down compilations?

- -usecache -> Another one of the 20% implemented features. This was done to give V a huge boost in compiling simple programs but the implementation is so busted, you yourself disabled it on the benchmarking site.

- "go" keyword -> From your docs: "V's model of concurrency is very similar to Go's. To run foo() concurrently in a different thread, just call it with go foo()". At least you've documented it but have completely buried the lede that unlike Go, `go` spawns an OS thread not a green thread. Speaking of green threads, how do you propose to keep the efficiency you claim ("within 3% of C") while still having transparent C interop? Are you going to use segmented stacks to allow 100,000s+ green threads and then run into the same issues Go has calling into C or are you going to larger stacks to make C interop feasible which limits how many green threads you can run before using enormous amounts of memory?

- "immutable" references -> As shown on Discord, "immutable" references can easily by laundered into mutable ones by assigning the reference to a mutable variable and then assigning into that.

- native backend -> Can handle hello world and programs that use string interpolation. Given that it can't handle the average 100 line V program, you should not be extrapolating the performance of 1,000,000 V programs.*

⬐ amedvednikov

> No reply to the autofree comment? Unsurprising.

autofree was placed a bit lower on the prioritization list due to the focus on C2V and amazingly well integrated -gc boehm, which solves all leaks for now.

- "No undefined behavior" -> How does V prevent this?

By not having UB. You have any examples of UB in V?

`x and *x` type checker bug in the compiler means the compiler doesn't work? Then by this definition none of the compilers do, because all of them have bugs.

> How do you plan to deal with template bloat slowing down compilations?

Is that your example of an alpha or a broken feature?

> - -usecache -> Another one of the 20% implemented features. This was done to give V a huge boost in compiling simple programs but the implementation is so busted, you yourself disabled it on the benchmarking site.

No I didn't. V hello.v uses -usecache. And v self was removed for now because it's unfair: V modules are in vlib, all of them get cached, and the compilation is too fast. How is it 20% implemented?

> - "immutable" references -> As shown on Discord, "immutable" references can easily by laundered into mutable ones by assigning the reference to a mutable variable and then assigning into that.

Not anymore, a large amount of these bugs have been recently fixed.

Native backend is being worked on by a very experienced developer, author of radare2, so we will definitely see v self -native work this year.*

⬐ vlang1dot0

Can you explain how a conservative garbage collector solves all leaks?

Why won't you see it? It's public:

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

You can also download it and try it yourself.

As for compilation speed, here's V compiling itself in 0.2 seconds:

https://pbs.twimg.com/media/EoAx9fsWMAE2M4U?format=jpg&name=...

⬐ judge2020

The nearly 1 second compilation is impressive, but why claim it has 0.2 second compile time when using a cache? It doesn’t represent the real-world time it would take to compile v or another program from fresh in order to install it.

⬐ tomcam

I often compile projects before the cache expires...

⬐ amedvednikov

-usecache here means that vlib is cached. It will be the default in 0.2.1.

The entire V compiler is built from scratch.

Author of the language here.

Very excited about this release.

This is the first major release after 0.1.

The focus has been on stability and compile-time memory management. The demo of that was posted here recently [0].

7600 commits, 4110 handled pull requests, 340 contributors, 20k GitHub stars. What a journey!

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

⬐ breck

Have you given any thought to choosing a longer name for the lang? I really hate single letter identifiers. By going to 2 symbols you reduce term overloading by ~35x on average, ~3 you get 1,000x less namespace conflicts.

Though I guess "VLang" works.

⬐ himujjal

Hi. How is cyclic references handled? One of the maintainers said it would be removed and made not possible.

Also garbage collection. What are you doing for that? ARC?

⬐ amedvednikov

From the home page:

V avoids doing unnecessary allocations in the first place by using value types, string buffers, promoting a simple abstraction-free code style.

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 reference counting.

The developer doesn't need to change anything in their code. "It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything or expensive RC for each object.

For developers willing to have more low level control, autofree can be disabled with -noautofree.

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

---

So yes, for the ~0-10% of objects not freed by V's autofree, ARC will be used. We will implement weak references and probably have a simple cycle detector, so pretty much a minimal GC.

Unlike in Go or Swift, it won't be used on all objects, but only on the small percentage that couldn't be handled by autofree.

In the YouTube demo I posted, 100% of all allocations in the text editor is handled by autofree.

⬐ slavapestov

> Unlike in Go or Swift, it won't be used on all objects, but only on the small percentage that couldn't be handled by autofree.

Swift also has value types, and optimization passes to promote heap-allocated objects and closures to the stack where possible using escape analysis.

⬐ azakai

Similar in Go as well: Many things are by value, and it does escape analysis too, allowing a lot of things to not require the GC.

⬐ gus_massa

> Remaining small percentage of objects is freed via reference counting.

That should free most objects in a simple scenario, but how do you free objects in a cycle without a garbage collector?

⬐ dgb23

This sounds interesting. I would love to understand how autofree decides what it can handle, and when ARC comes in.

⬐ amedvednikov

Check this test out:

https://github.com/vlang/v/blob/master/vlib/v/tests/valgrind...

It has lots of comments and will give you a good picture.

⬐ vlang1dot0

I think having actual documentation about how the memory system is supposed to work would do a lot more to answer questions than linking to the tests.

For example:

x = [1, 2, 3] // is this stack or heap allocated?

foo(&x) // how does the compiler know if x needs to be ref counted or not?

return &x // is this valid or UB or a compilation error?

⬐ YorickPeterse

How exactly does V know when/where to release memory?

⬐ amedvednikov

See my reply to the sibling comment.

⬐ saagarjha

How does V deal with cycles?

⬐ CodeHz

It looks similar to nim's ARC/ORC gc approach... Just curious, have you ever compared them?

⬐ Too

Sorry but again this is one of those "V can do X (except when it doesn't and i get to define what that means)".

I don't want to be a hater and I'm genuinely impressed by the project. But it's honestly very hard to trust anything about this when all kinds of claims pop up, always with a big caveat at the end, usually after being questioned in forums and not in the official documentation.

What happens today if i don't pass in -autofree? If it was working it would be enabled right? And if it's not working, then how do i code without it? Sure, the language has a 0.x-version number but it's not exactly being advertised as something that is incomplete unless i dig very deep into documentation or twitter-threads. Some kind of roadmap of promised/planned/delivered features would greatly improve the confidence in this being not vaporware.

⬐ edko

Congratulations on the release! It looks very interesting. Does the GUI library embed a web-view, or does it use native controls? What's you estimate of when it will be available for Android and iOS?

⬐ amedvednikov

As for Android/iOS, V itself has been running on phones for quite a while:

https://www.youtube.com/watch?v=fIijYm1MfmI&feature=youtu.be

The UI library will support mobile asap, since it'll receive lots of attention now that 0.2 is out, and we now have 2 people contributing to it.

⬐ amedvednikov

No webview, that's not our way :) Although we do have a webview module for embedding the system's webview component.

The GUI library renders everything, and the result looks very similar to the native widgets:

https://raw.githubusercontent.com/vlang/ui/c2f802a137b5171da...

We are going to support native widgets, for example TextBox will be native due to accessibility and support for Chinese/Japanese/Korean/R2L input.

However things like text rendering will always be handled by the V graphics library, since GDI+ is just way too slow (calculating text bounds is ~10 times slower than in V), and Apple's drawing API is not very nice to use, and it's also 2-3 times slower at rendering text.

⬐ solarkraft

It's great to see accessibility/compatibility taken into account here, but are you only doing that for the text input or going further? E.g. can I copy text or use a screen reader?

⬐ amedvednikov

We will do this for the text rendered via V's graphics library as well, by using system accessibility APIs directly.

⬐ csande17

> GDI+ is just way too slow (calculating text bounds is ~10 times slower than in V), and Apple's drawing API is not very nice to use, and it's also 2-3 times slower at rendering text.

Does V's text library support the kinds of shaping and nested bidirectional layout needed to render Arabic text? I've heard that's a cause of a lot of complexity and slowness in text rendering, so stripping it out would be an easy performance win for people like me who can't read Arabic anyway.

⬐ da_big_ghey

It definitely looks like good progress. You mentioned that DirectX and Metal support have been added; I'm curious why platform-specific APIs were prioritized over Vulkan. Were they actively prioritized for some reason, or did contributors just work on those first?

⬐ amedvednikov

Vulkan is too complex and is not supported by Apple and older hardware.

We use Sokol, an amazing wrapper library, and it only supports the big 3.

https://github.com/floooh/sokol

⬐ da_big_ghey

Makes sense, though I'd dispute that Vulkan is "too complex". It's definitely not simple, but that's because it's a complex problem. The driver guesswork that something like OpenGL uses comes with costs, too.

Vulkan is supported pretty well on Apple through MoltenVK: https://github.com/KhronosGroup/MoltenVK

Mesa does software implementation of Vulkan, too: https://en.wikipedia.org/wiki/Mesa_(computer_graphics)

⬐ amedvednikov

Yes, I wanted to mention MoltenVK. That's another dependency and another layer of abstraction, which is not our way.

We'll see how it goes, maybe at some point Vulkan will be supported by Sokol, this library is growing very quickly.

⬐ zaphirplane

What is v’s take on inheritance / traits / mixin

⬐ somurzakov

Поздравляю, отличная работа! Не думали написать статью на habr.com ?

⬐ chubs

Amazing stuff! And if you really have managed to solve compile-time memory management, that's super impressive stuff.

⬐ higerordermap

Turing ded

⬐ NiekvdMaas

Congrats on releasing V v0.2! It's a great language and the compile times are amazing. My only issue is keeping up with the constantly changing vlib.

Do you have any plans to resume working on Volt (the original V app)? I thought the idea behind it was great, but there hasn't been an update in 1.5 years.

⬐ amedvednikov

Thanks!

Yes, it has been blocked by the memory management work and the 0.2 release, both of which took a while, especially since most of the compiler had to be re-written from scratch (using an AST). The UI library was also re-written several times as we tried different approaches (native vs custom rendering).

The good news is that Volt was always being updated and made compilable, and a public beta is also coming this month.

I'm already using Volt as my primary Discord client (and my 8 GB RAM laptop thanks me for that, since I've freed 2 GB of RAM).

Here's a sneak peek:

https://media.discordapp.net/attachments/731265552395534357/...

Some layout issues, and Chinese/Japanese/emoji not being rendered correctly, but the latter has been fixed on a branch.

The moral of the story is: if you want to deliver a software application quickly, don't write a new language/stdlib/ui lib for it from scratch.

At least I got to create a cool language and share it with the world :)

⬐ abc-xyz

Did you ever release the code of the original Go version of Eul/Volt?

⬐ amedvednikov

Some layout issues, and Chinese/Japanese/emoji not being rendered correctly, but the latter has been fixed on a branch.

The moral of the story is: if you want to deliver a software application quickly, don't write a new language/stdlib/ui lib for it from scratch.

At least I got to create a cool language and share it with the world :)

⬐ lasagnaphil

I still don’t fully understand the memory management side V. From what I’ve seen V takes a similar route as Nim’s recent ORC feature (https://nim-lang.org/docs/destructors.html#move-semantics), which automatically inserts destructor calls using move semantics. The question is, is there a similar move semantic model in V akin to C++ and Nim, or does it work in a totally different way? This wasn’t clear when reading the documentation, which made me a bit skeptical about it.

⬐ moldavi

vlang uses Lobster's memory management model: RC, eliminating as many increments and decrements as possible with some static analysis. Lobster was able to eliminate 95% RC ops with some extra monomorphization, so I'm guessing vlang is close to that.

⬐ amedvednikov

Yes, I'd also say 90-100%

⬐ tuananh

it's very impressive to know this is one person's work.

i first heard of him via Volt app. and then he went on to create vlang which looks very good from what i've seen

⬐ amedvednikov

Thanks!

I no longer work alone though, we have a large team, and I think only about 50% of code is written by me at this point.

Although the autofree engine this video is about is fully my work.

⬐ jokethrowaway

So this is basically a go-like language which can be compiled into C (which would explain fast compilation small size)? Neat!

I guess community and adoption will make it or break it

⬐ amedvednikov

Yes, but it improves quite a lot on Go:

https://vlang.io/compare#go

⬐ pipologist

Nice work. V is coming along nicely. How would you say the autofree engine works, is it RAII?

⬐ amedvednikov

Yes, pretty much.

⬐ None

None

⬐ WhoCaresLies

More stars and more contributors than ZIG, no wonder the zig developers were jealous when this language was announced

⬐ lasagnaphil

From what I’ve seen, the purpose and direction is quite different between the two (Zig seems like a better C, while V seems like a better Go.) I think it’s unnecessary to stoke another flamewar between the two. I may have some doubts with V, mostly with the fact that the language spec for managing memory isn’t clear and the compiler seems incredibly unstable right now - probably would need a few years to be usable for early testers. But I really don’t want that criticism mixed with any mentioning of Zig since the two aim for different needs.

⬐ WhoCaresLies

history is written, there is no reason to hide that fact

i still remember everyoner jumping at V, calling the dev a liar and a thief because it was becoming popular

⬐ WhoCaresLies

!!Conspiracy theory warning!!

I have the feeling that few people got tasted to work on a new language to replace C/C++

It is very weird, maybe my simulation is being a little bit too deterministic?

⬐ dpc_pw

Oh, someone is fixing Go? Nice.

⬐ vsskanth

Very happy to see vlang make steady progress. Been following this language since it was initially posted on HN.

What is the trade off here with auto free ? Is it still possible to have memory leaks in some scenarios ?

What about concurrency or multi threaded situations ?

⬐ moldavi

vlang uses Lobster's memory model, so the tradeoffs are:

* It falls back on RC when it can't guarantee something's lifetime, so it still does some RC.

* Can't store objects on the stack. (Lobster mitigates this with other aspects of their memory model, I'm not sure if vlang does)

* Vulnerable to cycle leaks. IIUC vlang has no weak refs to break these cycles yet.

* Space overhead per object to store the RC.

Still, its nice to see more languages not using GC. Hopefully as Lobster innovates, vlang can adopt more of their techniques.

⬐ amedvednikov

Right now it's possible to have leaks due to bugs in the autofree engine. Once it's stable, there will be no leaks.

For mutable objects shared across threads, reference counting will be used.

⬐ vlang1dot0

Even garbage collected languages do not prevent leaking memory because doing so requires understanding programmer intent. For example, adding objects to a static hash map and never using them is a memory leak that no GC will fix.

V has the same issue and autofree will not be able to fix it.

Reference counting is also necessary even in entirely single threaded programs to handle some situations.

It's concerning you state things that are categorically false with such certainty.

⬐ moldavi

Your comment, while true, is too pedantic to be useful. No language I've ever seen can prevent that broader definition of memory leaks, so it's not a useful distinction to make when comparing languages.

⬐ vlang1dot0

Ok but then the author should not be claiming that.

The problem with V is that the author makes astounding claims and when people push back on that even slightly they get harassed. Even your comment nit-picks mine over technicalities while ignoring the obvious issues with the author's.

Given how many of the "features" of V are completely unimplemented or only work in the most narrow of edge cases, it's not clear to me why so much grace is extended to the author who's generally been unable to deliver his promises all while collecting a tidy sum on patreon.

⬐ moldavi

I agree with your characterization of V's rather unbelievable claims (after all, V promised memory management with zero overhead many times, which as we can see, was not quite true).

However, I think the best thing we should do is make sure people have an accurate understanding of V's actual tradeoffs. We can point out V's actual problems, rather than the flaws which all languages have.

More to the point, whether a language has leaks or not depends on your definition of leaks: "unreachable yet still allocated memory" or "reachable and useless memory". Most people (for better or worse) subscribe to the first definition, so to most people, Alex's claim is correct. Some folks (you included) subscribe to the second definition, where Alex's claim would not be correct. There is much to criticize about V, but his post here is probably not the best target.

I appreciate you also bringing awareness to V's broader situation, that might be appropriate for a top-level comment.

⬐ vsskanth

Very happy to see V Lang making steady progress in spite all the hate it received on HN when it was initially posted.

⬐ dilsmatchanov

V avoids doing unnecessary allocations in the first place by using value types, string buffers, promoting a simple abstraction-free code style.

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 reference counting.

The developer doesn't need to change anything in their code. "It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything or expensive RC for each object.

taken from vlang.io