Hacker News Reader

Comment by lawl | Hacker News Reader

i'm pretty sure that half of these features don't work.

Such as the famous "autofree" where everyone doubted it could work and the solution now was.... to drop in boehm-gc.

for anyone unfamiliar with v, take everything on that list with a giant spoon full of salt.

The solution V seems to apply here is a bit more nuanced than that. They’re going in roughly the similar direction as Nim did with the new ORC, which is essentially keeping the GC but try to do some compiler analysis to insert free() calls at compile time as much as it can using scope-based memory management and move semantics. The confusing thing about V is that these design decisions aren’t written properly on the docs, so the author’s claims might feel like “selling snake oil” although it’s already implemented in another language with great success. It would have been much better if the creator of V had acknowledged any previous work done on the topic. Also, the choice of Boehm GC is a little bit disappointing, but understandable since it’s basically the easiest garbage collector you can stick it into a language (without designing your own GC). Maybe this will change later on.

Though I’m still not confident enough on the usability and stability of the language. Almost all claims of the usability/stability of the language seems to come from the main creator himself, I would like to hear some takes from people other than him who have used the language in any serious form.

> keeping the GC but try to do some compiler analysis to insert free() calls at compile time as much as it can

This is correct.

> Also, the choice of Boehm GC is a little bit disappointing

Which one would you recommend?

> Almost all claims of the usability/stability of the language seems to come from the main creator himself

The creators of Vinix and vsql don't have any issues with the usability/stability.

>> Also, the choice of Boehm GC is a little bit disappointing >Which one would you recommend?

boehm is conservative. this is a costly and very unnecessary implementation for a language which already has a compiler and knows explicitly which values are pointers.

Thanks, will investigate.

We'll have our own GC in the future anyway.

> i'm pretty sure that half of these features don't work.

That's just bashing. It's one thing to actually use something and criticize, its another to not even use the language and assume things.

> Such as the famous "autofree" where everyone doubted it could work and the solution now was.... to drop in boehm-gc.

Autofree is still part of Vlang. Also, many other languages have multiple methods of memory management. Which many argue is a good thing. Take for example, Nim, which has several (see below). Yet, I have never seen anybody at HN lose their minds over it and bash Nim about it.

Nim has: gc:refc, gc:markAndSweep, gc:boehm, gc:go, gc:arc, etc...

So exactly why can't Vlang have both AutoFree and GC? Yeah, the correct answer is that it should not be a problem. And as a newer developing language, they should be allowed to experiment to find what works best, as the other languages before it.

I assumed that there was a English language barrier from the original author that made the mistake of present versus future tense for the feature list. When combined with a lack of feature tracking that looked to people like big claims were made without substance, but to me it always felt like everything in V was "work in progress."

They definitely have a hacker mindset to get the minimum working examples through and keep on developing, which is admirable in some ways. The downside is I don't think there's a lot of development experience hanging around that project, so things stick to minimal implementations.

I've never been able to quite understand what was going on with V (and the associated messenger client Volt written in it), but it seems to be something a bit more complicated than just a language barrier. I made a habit of checking the Volt website for a while out of interest in using the project, and it was somewhat surreal how fast the documented timeline would change. There was a super specific timeline in terms of what month features would land out as far as 2-3 years (e.g. "support for $os in $current_year + 2, open source in $current_year + 3), and but then as the months went by, the items on the timeline would not land, and the timeline would get revised pushing things out with no announcement of any sort. The platforms that were supported seemed to be constantly changing; one month there would be a Windows binary with Mac and Linux listed as "coming soon", and then the next month, there would be a Mac one but the Windows one was gone with no explanation. Charitably, I think the developer had fairly unrealistic expectations for how future work would progress and probably a lack of focus on following the plan they had publicly stated. I don't _think_ there was any malicious intent, but ultimately I felt like I wouldn't be able to trust that the products would be reliable if/when they did end up releasing and lost interest in following the timeline.

> There was a super specific timeline in terms of what month features would land out as far as 2-3 years (e.g. "support for $os in $current_year + 2, open source in $current_year + 3), and but then as the months went by, the items on the timeline would not land, and the timeline would get revised pushing things out with no announcement of any sort.

That just strikes me as youth and inexperience

This has very much been the case for me when trying out V. It advertises some great features that just barely works in the right circumstances.

Can you give an example of features that barely work for you?

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

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.

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

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.

Reply on news.ycombinator.com