V 0.3 | Hacker News Reader

V 0.3

github.com

251 pointsamedvednikov328 comments

V looks interesting, and I wish it the very best. However the attitude of the lead developers toward criticism or negative feedback (even if it's not valid) is highly off-putting imo. Everything negative that people say appear to be taken as an "attack", and as far as I've seen they are quick on the trigger in regards to banning or blocking people that they disagree with. And at the very least they just completely disregard all negative feedback as lies, scams, conspiracies, etc.

The responses I've read by the devs are in stark contrast to what I've seen in other languages I use, such as Rust. I hope that as the language evolves, the developers will start reflecting on the way that they interact with others and how it impacts people's view of V. I could never justify using a language like V in production if I couldn't even trust the lead developers to be level-headed during criticism.

I'm sorry for ranting, I really wish the best for V and its maintainers.

Only I can ban, and I haven't banned anyone in 2 years. You can read my comments here about the attacks.

There's actual valid criticism and feedback like in https://github.com/vlang/v/discussions/7610

But there's also trolling, harassment, and completely baseless attacks.

The way Cadey was treated by your community entirely ended my interest in your language.

Who's Cadey? Do you have a link?

mst probably meant this: https://xeiaso.net/blog/vlang-update-2020-06-17

I think what was being referred to was any V GitHub posts, which would involve the V community. The V community has nothing to do with nor have any control over blogs and websites owned by others.

As for Cadey, it appears the person is continually self promoting, to include odd accounts continually linking to old and outdated blog posts on its website, at the expense of the V language and any chance given (see almost any HN post on V).

Cadey (or under various names) was the one that started off smearing V's author and the language with things like "V is vaporware", "V is lying", "recommend against using it for anything", hoping V would die off type nonsense, etc... Mind you, the attacks started against the very first released Alpha, as if it was supposed to be instantly production ready (and that is very much not how programming languages work).

So other programming languages are given the benefit of the doubt of even after say 5 or 10 years of development, while V was supposed to be a finished polished language from day 1? Just plain ridiculousness and clear bad intentions.

Xe/Christine never claimed V had to be polished on release. That's patently ridiculous. What they said was: the original features were not called out as being goals, so they took them as features that (obviously) didn't work. Those claims were eventually marked as "WIP" or whatever, which is exactly what Xe wanted. No one is claiming an alpha/beta doesn't have bugs, but V promoters like yourself claim any reminder of V's prior actions are saying that.

IMO, V has made great strides since the initial release, but none of Xe's claims were inaccurate. All Xe's first post ("V is for Vaporware") did was call out the website as being misleading.

Sure, people could see that it's a 0.x release and know it's an alpha/beta, but that's not the point! It didn't say that the features were WIP until after Xe's post. Compare vlang.io two days before Xe's post[0], and the day after their post[1] (notice the addition of "WIP" markers and a new paragraph about 1.0 above the fold).

It also doesn't help that any time a post about V comes up, people try to explain these things, but the author and people like you refuse to acknowledge it. What most people want is for V to admit the website was misleading at the beginning, but it is now a bit more clear. What we get instead are conspiratorial claims of brigading to destroy V. Unless people can point to some Discord or Reddit group that actually does conspire to destroy V, it's a hoax. As much as the author wishes, posting negatively about V because of its past is not a conspiracy.

[0]: https://web.archive.org/web/20190621013937/https://vlang.io/

[1]: https://web.archive.org/web/20190624052507/https://vlang.io/

And here we are again, like it's one the movies of Groundhog Day or Edge of Tomorrow, where somebody keeps hard pushing Cadey/Xe/Christine (and whatever other connected names) old blog posts to promote the website at V's expense.

V is an open source programming language. Of course the V developers and contributors are going to have continual discussions among themselves and then make changes to their goals, roadmaps, features, and timelines. To include make mistakes and have to do corrections. This should be common sense and understood, but apparently not, or least not when it comes to discussions involving the V language.

It's insanity to continually run through the wayback machine on any alpha version of a programming language's website and run around: "Why is there a change in this language feature?" or "But, you said the language would do this before." or "Why you changed the date?". What is more relevant is the present website and present version of the programming language, because things continually change and that's how development works.

In regards to your conspiratorial claims, lets check the previous posts:

1) Mst made a claim that somebody named Cadey was mistreated by the V community.

This looks to be false. Doubtful if anybody in the V community even knows who Cadey is. Furthermore, the "V community" is not in control of random blogs, websites, or posts on the internet or their content. If you are going to refer to the "V community" it needs to be at least somewhere officially recognized by them (like V's GitHub) or at least where one can prove they significantly congregate at.

2) The V creator didn't know who in the world Mst was talking about and asked for a link as proof.

3) This was then used as an opportunity by an odd account from 2010 (Neven) with only a few posts (really odd) to then re-push and promote upon us again the Cadey/Xe/Christine website.

Which drudges up 3 year old mostly non relevant crude, that nobody really cares about except V detractors that seem to get off on it, that is pushed on every HN thread involving V that I've seen.

Note- And it's such a repeating pattern, of what V detractors do (even without mentioning the downvoting, flagging, trolling, and gaslighting), that others are noticing it too. Among them, sph and johnfn, and check out their posts above.

I'd note that my attempt at "I'm not actually mad at you, but here's an explanation of why your current attitude is counterproductive" (with the obvious caveat I may've been complete wrong) got flagged to death rather than argued with.

Which is the original repeating pattern, I'm afraid :(

That's not at all the vibe I get from one of the lead devs posting here. I see it more as frustration from dealing with low effort snipes/trolls.

The language used on the main vlang site also seems calm, clear and unsensational (at least to me).

> frustration from dealing with low effort snipes/trolls

That's exactly what it is :)

>The language used on the main vlang site also seems calm, clear and unsensational (at least to me).

It wasn't always like this. Back in 2019, its website looked like this:

https://web.archive.org/web/20190303184805/https://vlang.io/

As you can see the website claimed that its compiler is "200x faster" than C compilers, while neglecting to mention that it merely translates V code to C, so you still have to run a C compiler.

"400 KB compiler with zero dependencies" (apart from a C compiler and libc).

"As fast as C" - a lie.

Apart from deceptive marketing, there were serious issues with the code quality of the compiler:

https://github.com/vlang/v/blob/d32e538073e55c603992b5b65ebc...

"As fast as C" is not a lie. It literally translates to C.

The 200x compile speed up referred to C++ compilers, this was vague and hard to measure, since the languages are so different, and was removed.

The code may not have been perfect at the time of the 0.0.1 release, but it worked. V could compile itself.

Now it's much better and more organized.

>"As fast as C" is not a lie. It literally translates to C.

No, just because it outputs C it doesn't mean it's as fast as hand-written C. Using that logic, every language that outputs machine code is as fast as assembly, which is obviously not true.

But it is true. V doesn't add any overhead. You can verify with `v -o file.c file.v`.

As long as you use the same data structures and algos, you'll get the same perf.

There's stuff like bounds checking, but it can be disabled, and it adds like 5%.

If you look at the C that's generated using -keepc flag, I think you will be hard pressed to find any glaring inefficiencies to "hand coded C"; especially none of which GCC optimization wouldn't handle with -prod compiler flag. Even if there were, for the very large majority of users who are not highly proficient in C (which is becoming more and more common these days - Grey beards are rare), the V way is going to outperform novice to intermediate-skilled C programmers hands down.

I don't see how that really follows. V heap allocates any value which is address taken. You don't need to be an advanced C programmer to use pointers.

> I'm sorry for ranting, I really wish the best for V and its maintainers.

I appreciate you posting this. I like the premise of V and really want for it to suceed, but this is a good summary of why I think so many people dislike V: the lead dev and community do not engage criticism in good faith.

I'm sure V receives its fair share of unwarranted criticism, but a lot of legitimate criticism and questions are either met with a) hostility or b) incredulity, which causes people to dislike the language for fundamental reasons.

Both the creator and community members gaslight (for lack of a better word) and act as if they're happy to receive questions or feedback, but even in this thread you can see people being treated like I mentioned above.

E.g. https://news.ycombinator.com/item?id=31947510, https://news.ycombinator.com/item?id=31947121, https://news.ycombinator.com/item?id=31947212, https://news.ycombinator.com/item?id=31947014, https://news.ycombinator.com/item?id=31946715, https://news.ycombinator.com/item?id=31947977

How's the first link an attack for asking simple questions?

(By the way there's not a single question there.)

Initially my intention was to link questions, but I decided to link to any genuine comments that reflect the GP's sentiment.

I've updated the language in my comment.

I don't have the time to go through every link, but let's just look at one or two:

> https://news.ycombinator.com/item?id=31947177

I mean, the article linked at the top is just outrageous - just read through it. For instance, it claims that V misleads by claiming that it has no null. But really what the author has done is found a bug in V that allows a variable to be set to null. A bug that unintentionally leads to creation of null is wildly different than V not supporting non-nullability at all. It'd be like using FFI in Rust to set a non-nullable variable to null and claiming that meant Rust had no type safety. It's absurd.

I can understand the maintainer's frustration.

> https://news.ycombinator.com/item?id=31947212

OP claims V has "huge promises it hasn't kept". V is version 0.3. This seems wildly unfair.

> https://news.ycombinator.com/item?id=31946715

OP kicks a conversation in poor faith with "Wanna know something funnier also posted in previous thread?" about a V bug - which HN turns a blind eye to - and then suddenly the HN community pounces on the V maintainer when he gets frustrated in return? What?

> > https://news.ycombinator.com/item?id=31947212

> OP claims V has "huge promises it hasn't kept". V is version 0.3. This seems wildly unfair.

Keep in mind that V didn't start out as a v0.1 with an ambitious roadmap, it popped up as website with a bunch of exciting features that made it seem further along than it actually was (https://web.archive.org/web/20190315194630/https://vlang.io/ and https://web.archive.org/web/20190315173156/https://volt-app....). I suspect that's what OP is referring to. Incidentally, this is also what prompted articles like "V is for Vaporware".

>> https://news.ycombinator.com/item?id=31946715

> OP kicks a conversation in poor faith with "Wanna know something funnier also posted in previous thread?" about a V bug - which HN turns a blind eye to - and then suddenly the HN community pounces on the V maintainer when he gets frustrated in return? What?

I specifically linked to the_duke's comment offering some good-faith feedback.

---

But I digress. My intention isn't to argue that V is bad, just to provide context to why it's such a divisive topic.

> I specifically linked to the_duke's comment offering some good-faith feedback.

My point with this thread is it follows a common pattern. A HN user will post something in bad faith. The maintainer will respond with annoyance. Then someone like the_duke will moralize about how the maintainer shouldn't be so antagonistic. Then GP will put it in a list and say "the lead dev and community do not engage criticism in good faith."

What is going on here?

> The maintainer will respond with annoyance.

The maintainer is the face of the product in certain ways. We would never defend a corporate CEO responding in annoyance to their free/paid users because it's unprofessional and puts the brand in a negative spotlight. In the same way, if you're leading/promoting a project you are held to a higher standard. You can choose to ignore bad faith comments, or respond in a positive way to bring the discussion to a higher level of civility.

Yes, it's annoying to have people give bad faith criticisms. But if you want a product to succeed and you want to foster a positive community, you should always elevate the level of civil discourse. So I disagree with your sentiment that other users are moralizing here.

If I'm going to engage with a product, it gives me much higher confidence knowing that the maintainers conduct themselves in a professional manner, even when a user is unprofessional.

There are some repeating thought patterns on some hot topics in this forum that makes me question whether it's work of trolls or naive people asking the same questions that end always the exact same way.

When it happens, it feels like living in Groundhog Day.

See any Brave post. There's a comment about BAT stealing money, people debunking it and the same arguments over 10 comments. Just below that someone mentions Eich's history at Mozilla, same pattern.

See any Urbit post.

See any V post.

See any foone post.

In these threads you find always the same archetypes of comments and posturing it makes me wonder if we're really living in a simulation of not very good AI. Or that a group of people is collectively pretty dumb and more predictable than you'd think.

> A bug that unintentionally leads to creation of null is wildly different than V not supporting non-nullability at all.

You have the "badness" ordering here totally the wrong way around. Soundness is about trust.

A known-unsound system is not necessarily bad. I use C and Python. I know the tooling can't give me very many guarantees, and that I have to do the book keeping myself. "Caveat emptor".

In a much, much stronger sense: there is absolutely nothing wrong with a sound system with explicit escape hatches. Bothing. I use sorry in Isabelle and admit in Coq. I do type casts in Java. I know where I can and cannot trust the tooling, and there are clear flags where I need to do my own book keeping. FFI in Rust is an explicit escape hatch.

I can't think of a single system that doesn't have some sort of explicit escape hatch from soundness. As long as it's explicit and understood and above all intentional, this is a feature rather than a bug.

But it's very hard to justify using a system that's supposed to be sound and isn't! I don't know where to trust the tooling.

And the blog's examples are not contrived. They are actually very straight-forward mistakes as far as type systems go... most production type system bugs are much subtle.

> But it's very hard to justify using a system that's supposed to be sound and isn't! I don't know where to trust the tooling.

At the point V was version 0.2. Of course it has bugs - even bad bugs.

The article went through each feature of V, found one bug per feature, and claimed that V failed to have that feature.

There are constructive and non-constructive ways to start a conversation about bugs in a language. One constructive way is to open Github issues. Writing an article claiming that a language fails to have those features at all is one of the least constructive ways I can imagine.

> There are constructive and non-constructive ways to start a conversation about bugs in a language. One constructive way is to open Github issues. Writing an article claiming that a language fails to have those features at all is one of the least constructive ways I can imagine.

Github issues vs. articles must be a generational thing; I have never used Github's issue tracker even for FOSS projects (admittedly not because we had better alternatives). I'm not even particularly old, but I am old enough to pre-date GH issue trackers as the de facto FOSS issue tracking solution.

Certainly, I would reach out to the author of a project -- especially a personal not-for-profit FOSS project -- before putting them on alert with a highly critical blog post. Except in exceptional circumstances (eg intentional spyware or backdoors embedded into the project).

But I don't think of articles as better or worse than GH issues in terms of form.

This kind of reminds me a tame version of the "disclosure debate" in security in the 90s/00s, I guess. Just because a lot of that debate was claimed to be about protecting users but was actually often about protecting egos (and "look how smart I am" zine articles that weren't entirely written in good faith or professional ethos). Except, of course, that in this case I think a simple cultural difference could explain a lot without any ill intent on either side.

(FWIW I'm not saying either of us is right or wrong. Perception is inherently subjective and all culture is relative. But I think I better understand how this project became so controversial...)

I don't really agree. V seems to attract a much larger than normal swath of people who enjoy trying to score points off of technicalities. e.g. people claiming the entirety of V is an unsafe language because they found a single bug in the compiler, etc. Languages like Rust never garner this sort of point scoring in the comments.

> as far as I've seen they are quick on the trigger in regards to banning or blocking people that they disagree with

Do you have any source for this claim? Without a source this simply reads as another person trying to sow uncertainty and doubt. I haven't seen anyone banned or blocked on Github.

Exactly. The amount of nitpicking is ridiculous.

There's an entire article half of which is about a single checker bug that has already been fixed.

Or claims like "it uses official system api (libc), therefore you can't say it doesn't have dependencies".

That's because V already lied once about its memory management, see https://news.ycombinator.com/item?id=31947048. Any highlighting of that fact is met with deflection and dodging.

V is still making dubious claims: his newly invented autofree isn't stable even today after years and users are encouraged to use garbage collection instead. It's hard to trust that when we've been lied to already.

What? "After years and years"... It's version 0.3. Not even stable 1.0. The conversation you had with the maintainer puts you in a worse light than him, in my opinion.

He's already promised something too good to be true and it turned out to be a lie. From wayback machine https://web.archive.org/web/20190520021931/https://vlang.io/...: "(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."

I was excited for that. We were all excited for that. Then it wasn't true. I would forgive him but he seems to be continuing.

Then he walks that promise back, pretends he never said it and suddenly invents this magical "autofree" system but gives no details on how it works. Rust was never that secretive, it was based on published theory.

He claims it removes 90% of reference counting but if that was possible then Swift or Python or anyone else would have done it.

If it was based on solid precedent, or there was any research, or he published anything about how it works, or he didn't take donations, or it wasn't advertised on the website, it would be fine. But that's not the case.

Let me get this straight. Someone is running an open source project. They said they are working on some ambitious feature. Said ambitious feature hasn't materialised up to your standards, and now you feel like you've been cheated or lied to?

Maybe you should ask for your money back.

So are we saying that open source programming languages are not allowed to make changes to their goals, features, or roadmaps?

And if they do make any changes, then people should go to the wayback machine and hold them accountable to what was in the past, and not what they are showing and saying in the present?

Seems to be very unrealistic, and more of a personal grudge or pet peeve.

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.

These aren't mutually exclusive. What isn't captured in individual posts about V is the historical context of previous discussions.

I think many people feel scorned or resentful towards the attitudes, which means they're more likely to speak negatively of it in the future.

When V was first announced, there was a lot of hype about "Volt": a cross-platform Slack app written in V (https://web.archive.org/web/20190315173156/https://volt-app....). It was slated to be released 'soon', but months went by and there was nothing. When it eventually did release, it was nowhere near as complete or polished as people were being lead on to believe. Same thing with V itself, and people were attacked for pointing this out.

There's a long history of over-promising or hyping things that don't exist, and not handling constructive criticism well. So there's a number of people who actively dislike V.

Right, people who dislike me will call me a massive arsehole (and not necessarily be wrong) but V-lang stans leave -me- cold.

I think the problem initially was that people accused the creator of malice for no reason other than not being more specific about which features were a work in progress. I agree that it's not good to treat every criticism as an attack, but sometimes criticism of V (as an outsider, I've never used it) feels more like anger towards the creator rather than a helpful suggestion. For example, there's a difference between saying "I've found a bug in an advertised feature" and "You're a liar", which is how much of V's critics sound to me.

FWIW, my view is that even the best programmers don't always have perfect non-programming skills and it is better to give them specific objective feedback via bug reports/technical comments etc and not focus on how they are not doing the expected thing or behaving in an expected manner. Focus on and encourage their good work if possible.

> However the attitude of the lead developers toward criticism or negative feedback...

I disagree about that, because there is a major difference between submitting a bug or disagreeing about a claim or feature versus outright trolling, smearing, instigating drama, or trying desperately to create negative public perception.

Issues and discussions can be brought to V's GitHub (https://github.com/vlang/v/issues, https://github.com/vlang/v/discussions), but instead what various competitors and detractors do is create drama filled smear blogs or bad joke posts (on various websites) against the author or language. That's not any attempt at being helpful or constructive, that's more about slander or to create such negative sentiment in the hope of killing off the language.

When issues and discussions are brought peacefully to V's GitHub, they are discussed and debated intelligently. If any such issues have any validity, then they are usually fixed.

> Everything negative that people say appear to be taken as an "attack"...

That's simply not true. What does happen, is various competitors and detractors do specifically attack and smear the language or author, and who have no intention to want to be helpful or make any improvements. To include engaging in downvoting or trolling those who appear to be V supporters.

Such attacks and smears are not about fixing anything, their point is to be destructive, create negative publicity, and dissuade others from using a rival language.

If there are those that don't think that is the case, then simply ask yourself why many of those engaging in such attacks and smearing who claim to be technically knowledgeable or interested in using the language are not making their case on V's GitHub? That's where a person can go to improve V and get it production ready. Continually engaging in smearing is not about fixing, improving, nor reaching out to V's developers or community.

V's creator here.

We're really excited about this release.

This is a big one. 5769 commits pushed to master, 1697 bugs closed. The highlights of this release are C2V, a fully automatic C => V source code translator, closures, and no more memory leaks by default.

There's a really cool C2V demo:

https://www.youtube.com/watch?v=6oXrz3oRoEg

Translating DOOM from C to V, building it in under a second and running it!

Thanks for posting.

> Translating DOOM from C to V

Like, you can literally translate a C project to V without any manual intervention?

Exactly.

This isn't a criticism, but what's the purpose of using c2v? As in, anything outside c2v just to compile it. The example of DOOM is taking the C code, converting it to V, then compiling it (which internally converts V to C before passing it off).

Generating V wrappers on top of C libraries in order to use them. Otherwise all functions and types would have to be manually converted.

Migrating older projects from C to a nicer newer language.

By moving from C to V you get rid of complex makefiles, headers (you get nice clean modules instead), you get a modern stdlib with strings etc (although C strings aren't converted to V strings by C2V yet), much easier cross compilation, etc.

Was it tested on very huge code base like say, the Linux kernel?

DOOM is big but not huge.

So not yet.

But we are planning to translate SQLite soon and yes the Linux kernel at some point.

Linux kernel might be a tricky one with all the inline assembly code.

Luckily V supports inline assembly code! It's used a lot in Vinix.

Yes I didn't mean to down size the impressiveness of translating DOOM, congratulation for that.

I was just wondering to which scale it would stretch properly.

Thanks for your replies.

How do you handle function-like macros and concatenation? Also, both D and Zig seem to have switched to including a full C compiler instead due to issues with translating C source wise, is that a possible direction for this in V or is the source translation good enough?

Macros are unwrapped by Clang when generating C AST.

No plans to support C compilation for now, translation works well enough.

A use case would be converting an existing c codebase to v and then continuing development in v, rather than c.

I think this is very good for legacy C projects specifically that are no longer being worked on, to breath new life into them and easier coding.

I presume the intention is that V will be compiled natively eventually, not via C.

Yes, there's our own fast native backend, about as fast as tcc. But it can't compile V yet.

It will never be as optimized as cc -O2 though, and it will never be as portable as C, so C will always stay an option.

If it works, devs can move to a safer language for future development of the project. Anyways, code as a sacred artifact perspective needs to go - by that I mean, having tools to modify/convert and answer questions about code much more easily. May be with AI that would finally be possible.

For libraries this can be useful if it means that you don't need to deal with a separate C toolchain in the build process. Instead you just bundle a copy of the library transpiled from C.

The "autofree" memory management [1] seems quite interesting, and a very cool mixture between garbage collection with static memory management. Has been there been any seminar / conference talk held on this topic related to the pros / cons of this approach vs a pure GC memory management strategy, since it seems like it could be used in _almost_ all modern GC languages.

[1] https://vlang.io/#memory

Ref: https://news.ycombinator.com/item?id=25514198

I tried c2v on some very simple commands in freebsd /usr/src/bin/ such as ls and pwd and it failed. Still, very good to see this progress! May be you can add some FreeBSD commands to your test cases?

This is why I don't believe a word from the author. I don't even know if the demo is actually translating it or a demo of how he wants it to work. I have no idea if 90% of it is hand translated (SDL, some complex routines, etc) with the easy 10% actually translated.

Or maybe 100% of it isn't translated but compiled to object files with a compiler with V generating wrapper functions. I have no idea what to expect

I just never heard of anyone using V and it actually working as they expect

c2v may have some assumptions that are not specified by FreeBSD C code. Probably easily fixable.

Rather than assume, you can use V and find out for yourself what works and what doesn’t.

> Rather than assume, you can use V and find out for yourself what works and what doesn’t.

Why would I bother? It's been shown the author says one thing while reality shows another

So you are commenting on something about which you have no direct experience, nor are you planning to change that. Why even “bother” repeating something you may have read or heard; why not just stay silent or learn something new?

My original comment was confirming to a poster that other people experience matches his. I never asked a (non rhetorical) question here or said anything untrue

The first public release of a C2V alpha is not going to handle all C programs right away. This is planned for a 1.0 release later this year.

How up-to-date is this [1] review from earlier this year for 0.3? Honestly, the review read nicely but left quite a questionable impression of V.

[1] https://mawfig.github.io/2022/06/18/v-lang-in-2022.html

All of the issues there were fixed several days ago, so it's no longer relevant.

Since it was another anonymous attack, it's not going to be updated and will stay like this for years.

And the issues discussed are questionable at best. Half the article is about a type checker bug, which was a 3 line fix.

Then false claims like being able to modify array.len.

Slightly off-topic but this whole thing made me curious.

I keep seeing V being "attacked" by various people with these kind of blogposts (or even HN accounts dedicated to criticizing V), with broad range of claims or counter-claims to what V wants to achieve.

While this is maybe not completely absent when other new languages comes up (like Golang or Rust), it feels like V really brings out the people to come up with ways of criticizing it.

Do you have any ideas about why or how come? Have you noticed anything in particular that makes people want to (almost) aggressively "prove" V to be wrong?

Basically, do you have any guesses to why V seems to have more "enemies" out there, compared to lets say Rust or Go?

IMO, it's pretty simple. At the beginning, V was making huge claims that turned out to be false or misleading. The developer clarified that many of those features were actually goals. Fair enough.

There's also the whole issue with blocking people who criticized the language (eg. Xe) because V was being "attacked" as if there's some conspiracy to destroy V. The claims may be outdated, but the response by the developers put many people off.

V has made huge strides since then, but people are very resentful.

There actually is such a conspiracy. People who wrote these articles literally wrote they wanted V to die.

I'll make a detailed post about this next week.

While wishing V would die is extreme, many people are just resentful about how V treated criticism in the beginning.

Not to mention that a conspiracy requires a coordinated effort. It's a lot more likely that blog writers are upset about something and decide to go on rants about other minutiae they find instead of submitting GitHub issues.

There are coordinated efforts on discords to brigade such threads, there are entire new accounts created just to reply to each of my comments negatively (luckily just today HN banned such an account), this very post about V 0.3 was mass flagged 3 times and removed from the front page 3 times, there are articles that take a simple bug fixed by a 3 line commit, and make a huge deal out of it spending a month writing an attacking post. Who would spend a month to write an article about a type checker bug?

Simply, V is very divisive. So, some people who peruse HN but don't have an account will see a V post, and make an account just to comment. Humans are just irrational.

I don't creating an account and monitoring my comments and replying to them with attacks and trolling for 3 years is "just commenting".

There's definitely trolls; I wasn't trying to imply otherwise. There's always going to be people who think your project is stupid, and it'll only get worse as the project grows. I think the best solution is to just ignore them.

Luckily in this case the amount of trolling goes down as the project grows :)

There are now V contributors who used to troll V back in the day.

> Simply, V is very divisive.

How is an open-source programming language divisive?

Seems the people brigading are toxic and divisive, not the language or it's maintainers.

Exactly! Thank you :)

> Who would spend a month to write an article about a type checker bug?

I have no horse in this race, have never heard of V, and frankly find the emotional charge in this comment section extraordinary... odd.

But I am a PL person.

Bugs in the type checker are pretty unambiguously a big deal. I totally understand why the examples in the blog post are alarming. The point isn't that they can be fixed by 3 lines; the point is that there were obvious soundness bugs in the type checker implementation and the language designer's attitude seems to be "NBD if the patch is small enough". Given the post and reaction, I would not be surprised if there are many more soundness bugs lurking. So, that's an issue if I want to use the language for anything serious.

That said, it looks like a hobby language in its early stages of approaching maturity, so the degree of divisiveness is seriously confusing. My reaction to all the drama is closer to "yup some soundness bugs; type systems get subtle fast, what a great thing to learn from" than "I hope V dies / the V critics are terrible".

I'm guessing there are weird personality/politics at play, but don't care enough to find out.

Anyways. I liked the Android examples.

You posted lower down asking to be called out for specific behaviour that people find objectionable.

This.

It’s complete nonsense that there is a conspiracy to kill v off. You know it. We know it. Saying it is just drama for the sake of drama.

> And the issues discussed are questionable at best. Half the article is about a type checker bug, which was a 3 line fix.

> Then false claims like being able to modify array.len.

This.

You’re just creating drama saying things like this.

Just say: “The issues in that review have been fixed now, please have a look and submit bugs in the issue tracker if you find them”.

If someone has a legitimate thing to say, and at the time they say it it’s valid… that’s fine. If was wrong at the time, then by all means call it out.

…but here’s the good story about v: you fix bugs. A lot. Quickly. You build lots of stuff. It’s very impressive.

Things aren’t always perfect; it’s v0.3 for goodness sake. It’s fine. Just a) don’t claim it’s perfect when it’s not, and b) just clearly point out when issues that have been raised are fixed.

It's not nonsense, read my replies below and the upcoming blog post next week. It's on a scale I've never seen before.

I’m really sorry you feel that way; I honestly respect the work you do and I’m convinced you’re not correct about this… but hey; you’re deeper into it than me. Maybe there is? I don’t know.

…but, please also stop and read what I said.

You asked for specific examples where your interactions are causing problems.

this is it. Don’t post like this. You’re accusing people of attacking you, attacking other people (for example your comments on the author of Zig below).

This is what causes people to have bad interactions with you.

So people calling me a fraud and a scammer are not attacking me?

I don't know you, but I think you should PR-manage the situation without being confrontational. Writing a blog post about it just invites the trolls to write an answer!

Do you know how many "X is better than Rust", "X language is trash" articles are out there?

Just be passive-aggressive like "Hey! thank you for the bug report and for taking the time to make V a better language! We'll check these errors!". Dismiss them and go your road.

It's funny because in the previous discussion I got lots of "what's the problem? fix the bugs and publish your own post going through the points in this one".

I think it’s OK to write a blog post about your progress, with a positive attitude. A very different thing is to write a blog post refuting a troll. “Don’t feed the troll” is as old as the internet.

Whataboutism is not a defense of our your own behavior.

https://en.wikipedia.org/wiki/Whataboutism

Whataboutism doesn't apply here, you're using it wrong...

I think you don't fully understand or know of the scale of the attacks and trolling carried out by detractors and competitors. Which includes hiding what they do and their true purposes, and attempting to instigate and influence others to perpetuate attacks, drama, and smears for them. There is also the gaslighting whenever people recognize some of their actions, recognize their throwaway or troll accounts, or against attempts to call them out. This includes doing such on other websites, not just HN.

I sincerely hope you reconsider posting it. Even if you're a 100% right from your POV, it will still give off a negative energy and hurt your project. I think @wokwokwok has a good point, why not just focus on fixing bugs and building stuff instead?

Because these articles are meant to stay for years.

People will keep linking to them and say "didn't you see? V uses shell to do http requests! what a joke"

This most recent article by an anonymous author had all of the issues fixed within several days, but it wasn't updated, it'll stay like this forever, as planned.

I do understand that that must be frustrating. What I don't understand is why you think writing a blog post about it will have a positive effect on your project.

Hey.... even if people are attacking V-lang, don't worry. Any good thing that disrupts existing "kings" gets thrashed initially. That's human behavior. Ignore it.

But, if lead dev replies in ways that seems offensive, or attacking, that is something that actually creates permanent dent in the adoption. Even if you are right in saying what you are saying, it still matters, a lot, to be polite.

I'm someone who really really wants V to succeed. I love what rust is able to achieve, but not the complexity it brings. V-lang gives me what I want from a language.

Language is beautiful, now it's your turn to be the same. Ignore the trolls. Many of them are paid.

And best wishes.... keep the good work. It never goes in-vain.

You made that claim a couple of weeks ago, somebody investigated your claim, it turned out that you were grossly distorting the actual comment when paraphrasing. And given you continued to be active on that thread, you're clearly aware of this. Why continue spreading the lie? At this point you can't even claim it was an honest mistake.

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

Is "I think it is something that should be ignored until it dies into obscurity" different from "I think it should die"?

Yes, it is completely different, as explained in that comment. Glad we've sorted this out, I trust that you'll stop making this claim in the future.

Agree to disagree. An author saying that proves the bias and the attack angle.

It doesn't. But there's a more important point: you're paraphrasing somebody you clearly have a great deal of personal animosity toward, completely changing the meaning in the process, and with no indication that this is what's happening. You've continued doing that even when it's pointed out to you. There are two options I can see:

- You genuinely are not fluent enough in the language to either understand the original statement, or to write a fair paraphrase, and are not willing to believe this mistake.

- You know exactly what you're doing. That is, if you gave the actual quote, nobody would for a moment take it as a proof of your conspiracy claims.

Neither of the above is acting in good faith. I'd ask again whether you'll stop lying about what Xe said, but at this point the answer feels pretty obvious...

I disagree with you as well. Clearly the blog creator is hoping for V's death, for whatever hidden intentions that they have.

We cannot know what the blog author was hoping for, we can only know what they wrote. And what they wrote is not anywhere near what amedvednikov repeatedly claims. Why are you ok with such blatant misrepresntation? If this conspiracy actually exists, isn't there some evidence that actually stands on its own rather than needing to be lied about?

> There actually is such a conspiracy. People who wrote these articles literally wrote they wanted V to die.

That's not a conspiracy[0], but a review[1]. You should be glad for the people that actually spend time to market your product, raise your credibility, tell you how you see from outside, and provide independent checks. For free.

[0]: https://en.wikipedia.org/wiki/Conspiracy

[1]: https://en.wikipedia.org/wiki/Review

Yes, it's very different. Xe is predicting that V will die in obscurity, and recommending that people ignore it due to that prediction. Look at the second half of that comment:

> There are good ideas there, but if you sell someone the moon and give them a block of cheese that's kind of a scam.

Xe says "There are good ideas there". What do you think the metaphor of being sold the moon and receiving a block of cheese was intended to express? What does it mean to you? To me, it very clearly expresses that the language described by V's marketing would be extremely valuable and desirable, and that Xe is disappointed that V does not live up to what they expected. It's bizarre to me that you somehow see this as consistent with "should die".

What is your evidence that there's a conspiracy? Why do you believe that people are secretly coordinating on secret plans to destroy you?

Everything I've seen is completely consistent with individuals disapproving of what they see as you repeatedly claiming that V is far more capable and ready than it actually is and ignoring others who point out their perception of the same exaggerations.

I'll be curious to read your upcoming blog post about this topic, as I have yet to see you describe any justification for your conspiracy claims besides you finding it implausible that people could actually disapprove of how you talk about your work.

The blog posts that you keep claiming are maliciously-motivated conspiracy seem entirely normal criticism to me. They describe their goals and motivations, and those goals and motivations seem like very normal and reasonable motivations that explain the content of the blog post. I don't see anything that would need speculated malicious conspiracy to explain it.

> ...seem entirely normal criticism to me...

Creating a blog, with an obvious smear title like "V is Vaporware" and making comments like "I recommend against using it for anything...", is not "normal" criticism. That is attempting to go above and beyond, with drama and smearing.

To include following such blog posts up with more linking, smearing, drama posts, and attempts to use such to get more attention for one's self at the expense of the V language.

There are things that are actually vaporware. It is reasonable and normal for people to actually say when they believe that something has a lot of signs of being vaporware.

Are there really, truly no tools that you personally recommend against using?

It's great you're level headed on this. As an indirect measure, I've perused the Discords of competing languages and the vibe is a world apart in terms of maturity, age group, topics (bullying is very prevailing, talking politics rampant, excessive anime) - essentially unmoderated reflections of character. So it's no wonder that if that's the community forged behind the scenes (in those competing languages), that it's going to bleed out and become issues elsewhere - and V is one such topic that seems to be commonly targeted by those groups.

Zig's author also publicly attacked V

There was a lot of jealousy when V was announced

Looks like the ones who need to self-reflect is Zig, they still don't have a self hosted compiler, meanwhile V compiles itself in less than a second

Yeah he was the first to call me a scammer and claimed V had a dependency on glfw.

He was really persistent with his attacks, even received a warning from dang.

I found it really surprising, because before the release he wrote:

> Wow, that's incredibly fast. Self-hosted in 2 weeks? Hot code reloading? This is everything I plan to do with Zig, but apparently done already. How did you do it so quickly?

Can you provide a link for that quote? I want to read it in context, and my attempts searching the web only brings me back here and another place with this quote without a reference. Thanks!!

It's legit, here you go: https://news.ycombinator.com/item?id=19086589

I'll also add, my personal reading of the quote has more than a note of "this sounds too good to be true." But that could well be a matter of interpretation.

it not that comment, there was some attacks after that

https://twitter.com/andy_kelley/status/1142503808901308418

I can't find the article where he mentions that it is a scam, i also remember people attacking the patreon backers

This tweet seems to be an apology so i guess we can move on

EDIT: there i found it: https://news.ycombinator.com/item?id=20230351

Don't think was an apology. I find it dubious Zigs README on GitHub reads "never to exploit them financially". What a weird comment... Notwithstanding the whole readme comes off like a weird socialist manifesto.

V seeking (and receiving) Patreon or GitHub donations is not exploiting anyone. Neither mechanism is a contract. Either can be cancelled anytime, immediately. So like it or not, the sponsorship is a pretty accurate reflection of satisfied people (unless one is simply too lazy to cancel their pledge...).

Yes, that's also the vibe I got.

Yeah you are right, i might have misread his tweet, after reading it again, it sounds like he knows he fucked up and is trying to save the face

Sure:

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

You might want to look into the somewhat dodgy history of the language. The negativity is not surprising.

Though you may just be asking rhetorically to probe for a response from the founder, in which case, never mind.

> Though you may just be asking somewhat rhetorically to probe for a response from a supporter

No, I was genuinely asking the question directly at the creator of the project, to understand their view of the contention they seem to be at the receiving end of.

I know the history of the project, but it seems to me like most languages in their pre 1.0 make claims about what they would like the language to be, not what it currently is, but they still don't receive their criticism in such manner. Or maybe I'm just reading into it too much. Hence the question :)

> most languages in their pre 1.0 make claims about what they would like the language to be, not what it currently is, but they still don't receive their criticism in such manner

That's because those languages make those claims in future-tense rather than past tense; they explicitly state them as goals, rather than presenting them as if they're already implemented. For example, I wrote a tiny scripting language for Erlang/OTP apps called OTPCL, and I make it clear in the README which features are actually implemented (like the parser and interpreter) v. which ones are in progress (like the standard library) v. which ones haven't been started at all yet (like the compiler). Same deal with up-and-coming languages closer to V's use case, like Zig; there's a clear distinction between those three levels of completeness.

V did not make that distinction originally; a large number of its radically ambitious goals were presented on the website as if they were already implemented, only to later be revealed to be "WIP" at best. A lot of people - including, at one point, Zig's creator - assumed malice here, figuring the disparity between the website v. the actual releases to be an attempt to swindle Patreon backers (I can't read the mind of V's author, but I would guess that it was more of a language/communication thing than anything outright malicious). In any case, that left a pretty negative first impression for a lot of folks, myself included - and while it seems V is making some progress, it's hard to get that bad taste out of my mouth and consider even trying it out when languages like Zig and Odin and Nim and Crystal seem to be a lot more transparent and realistic from the outset.

The history is not dodgy. There was an attempt to make it so by overblown picky articles attacking a 0.1 language. I'm going to cover these next week.

> You might want to look into the very dodgy history of the language. The negativity is not surprising.

This is a mostly content-free reply that casts vague aspersions; it's not especially helpful when someone asks, essentially, hey, what's going on here? to then respond that they may be interested in looking into what's going on. Of course they're interested—that's where the question comes from, after all. Please respond meaningfully, then, and abstain from replying with non-specific ad hominem.

Thank you. I got really tired of these vague accusations over the last 3 years.

Look, I'm not hostile towards the initiator or the language. I'm happy to give V a chance in the future.

But it started out with huge promises that could never be kept, and were tied to fund raising. This is why there was so much skepticism in the beginning, and why you are facing so much hostility now.

The way to change that is by professionalism and convincing arguments, benchmarks, showing how the promises are kept and responding to criticism in a good faith manner by providing technical explanations.

Not by responding with more hostility.

It's also perfectly fine for fans of the language to support it here, but there are many "content-free" posts in this submission that just hype up V with minimal value-add...

I personally don't see an ad-hominem in my post.

Can you please list here the huge promises that could never be kept?

1. 2. 3.

Nothing in this comment makes sense as a reply to me or what I wrote.

> This is why[...] you are facing so much hostility now.

You are confused about something. You seem to think I'm someone else.

I have some guesses.

I'll publish a big blog post about this. It will debunk all these "V is a scam" articles.

Basically V appeared out of nowhere and got popular very fast. It took a lot of shortcuts: it was self hosted on release, GitHub started supporting it 1 month after the release, it had hot code reloading, fast compilation (v self is <1s [0]) and so on.

People developing other languages and their communities didn't like it, and decided to attack it.

There were 2 strategies: making completely false statements (like claiming that the V compiler has a dependency on glfw, so the no dependency claim is false, and claiming that V programs use libc, system's only official API, therefore again the no dependency claim is false) and nitpicking over bugs that are inevitable in a 0.1 language, and sometimes complaining that features explicitly marked as [wip] are not ready yet. One of the common questions I saw is "why release it if it's not ready". While that's the whole point of open source. I got lots of help from 500+ contributors and got to this point a lot faster.

Then there was also a misunderstanding with the "preview" release one week before the source code was released, and many thought V was going to be closed source. Over this week unfinished features were not marked as [wip]. They were marked so after the open source release, and now there're no [wip] features on the website. Everything listed there is working in latest V.

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

> People developing other languages and their communities didn't like it, and decided to attack it.

I honestly doubt this is the case. Aside from some cargo-culters (which are far from being a majority), most programming language enthusiasts are very welcoming to new languages and ideas they bring with them. I have never seen a "language war" happening this way.

Personally, I admire the V's ambitions (if the autofree() ever reaches production-quality it would be a total triumph over Golang's garbage collection approach), but I dislike the unprofessional approach to the community (explained in many other comments - particularly false claims about language capabilities, deleting criticisms, unwillingness to admit shortcomings and making up excuses for each of them, etc.).

There are 0 false claims about language capabilities on the website or in the docs.

If you can link one, that'd be great, and it'll be fixed. I've spent a lot of time verifying all claims are valid.

For example there was the "functions are pure by default except IO" which caused lots of criticism and memes. I simply changed the wording to a more verbose but correct phrase. So we do admit shortcomings and not make up excuses "for each of them"

We do not delete criticisms, we actually welcome them and any kind of feedback:

https://github.com/vlang/v/discussions/7610

So you're sticking with "people are evil and hate me"?

So can you list the "false claims about language capabilities" here?

You're reading my words, but you're not trying to understand what I'm saying.

Unless you demonstrate an honest effort to understand, I will not continue this pointless argument.

You said there are false claims about language capabilities, I asked you to list them. It's a reasonable request. I don't want to have false claims on the website.

Saying "no undefined behavior" when what you really mean is "We define our language's behavior to be the same as C's" (in other words, you just punt undefined behavior to the C compiler) is deceptive at best. I'm specifically thinking of signed integer overflow here, but that makes me think there may be other cases as well.

In my opinion, the current documentation on the autofree engine [0] constitutes a false claim about language capabilities:

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

[0]: https://github.com/vlang/v/blob/master/doc/docs.md#memory-ma...

So, I am not entirely sure the best way to quantify whether this is true. However, I thought a fun test would be recreating "my first memory leak" -- the first memory leak I can remember fixing in code that I wrote. Specifically, I was essentially leaking some bespoke heap-allocated iterators I had created (inside of an infinite game loop).

So here is my little test:

    struct Iter {
    mut:
        pointer int
    }

    fn main() {
        my_array := [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ]
        
        for true { // simulated game loop
            mut iter := &Iter { 0 }
            
            // heap allocated iterator
            for iter.pointer < my_array.len {
                print(my_array[iter.pointer])
                print(" ")
                iter.pointer += 1
            }
            println("")
        }
    }

I compiled this with -autofree -gc none, with V 0.3. Checking it with valgrind, it continuously leaks memory.

So, from what I can tell, this description of the autofree engine in the documentation does not accurately describe the existing functionality available in V.

I am curious where the 90%-100% figure comes from. It is such a specific number that it implies to me, as a reader, that it comes from an empirical measurement of an existing system. But, there is no link to where this measurement was taken. In my opinion, the documentation should include some details about how these figures were generated.

No, it describes it absolutely accurately:

> until V's autofree engine is production ready.

So, to be clear, is the intended reading of the documentation as follows?

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

> These points are both currently untrue, and should not be relied on in code.

I'm hoping I don't come off as flippant here. I just don't see any way to interpret these claims as an accurate description without adding that third bullet point.

They are both true, and it clearly says it's not production ready yet, so there are bugs.

Okay, I really don't understand what you're saying here.

The claims are objectively false. The autofree engine objectively does not free 90%-100% of objects, it is objectively not true that "It just works."

If I understand you, you're saying that autofree doesn't work because of bugs in the compiler. But, the fact that the claims are false as a result of bugs in the compiler does not somehow make those claims true.

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

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:

> 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

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.

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.

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.

I think the highly aspirational nature of the claims about V upon its original launch are why it attracted so much scrutiny. It claimed to do a lot of things and didn't clearly separate things that might be delivered in the future from those that would be features present in the language today.

And, judging by the review linked upthread, as of last month this has remained the case. For this reason, I'm not surprised that the scrutiny continues.

If you look at other posts in this thread, you'll see that this review is completely irrelevant since the bugs it complained about were fixed in several 3 line commits.

I won't pretend to be up to date on your language and what is fixed or working, but if it was so easy to fix these bugs that were apparently so trivial, why weren't they fixed before announcing / releasing the features? Even just communicating that a feature isn't done yet and may need a little more time (e.g. a beta tag) would go a long way in rebuilding trust with people outside your community.

Meanwhile, defensive reactions like those I see in and around this thread make me feel like I trust you less.

I'm sorry but that makes completely no sense. "Why didn't you release software without any bugs?"

That's not how the world works. And it's open source, where hundreds of contributors help you find and fix these bugs. That's the whole point.

As I said in my previous reply, you're more than welcome to stick a beta tag on something that isn't ready for prime time yet. Take a look at Rust and their releases as an example of the ultimate in building a stable foundation that people trust.

I'm not asking you to never ship a bug. I'm saying I don't trust you or your language and giving you an example of how you might regain my trust. Feel free to ignore my advice, but if your goal is to encourage more people to use your language instead of encouraging more people to fight you, maybe you could at least give the impression that you were willing to hear someone out instead of telling them their opinion doesn't make any sense at all.

It literally says V 0.3 in the very center of the website. First thing.

Yeah, and that's not enough. I guess I'll hold off on trying your language until 1.0.

V has "enemies" because that's how they respond to people giving them constructive criticism and questioning their claims. Most authors would relish of thorough technical analysis of where their issues where so they could improve their new language and compiler, but not V it seems.

They mostly seem to deflect with denial or claims the issues were 'nothingburgers', but if that's the case, it should be trivial to offer a rebuttal in the form of a blog post, but instead we get ad hominems and conspiracy theories.

The "nothingburger" you quoted is a single word you took from a reply chain in which amedvednikov explained the 800 byte "memory leak" was actually just GC overhead and expected.

So it wasn't a memory leak, it is GC overhead, hence it being labeled as a "nothingburger".

What specifically do you feel hasn't been resolved or addressed properly?

>What specifically do you feel hasn't been resolved or addressed properly?

The author responding constructively to criticism. The bugs may be fixed, but if the author can't calmly engage and link to the fixed commit, or give evidence that, for example, everything compiled with GCC leaks those 800 bytes, well that's a major red flag about the project management of V.

Completely not true. We welcome criticism and feedback, we even have a topic with 800 messages called "What don't you like about V / what would you like to be changed?"

https://github.com/vlang/v/discussions/7610

Wishing V to die and making false accusations is not "constructive criticism".

There will be a blog post next week.

The community isn't too friendly, I'm sorry.

In the cited thread, I've deleted my contribution because of the tone of the discussion (passive-agressive know-it-alls with smirk emojis): https://github.com/vlang/v/discussions/7610#discussioncommen...

Is this how you welcome people to the community?

I enjoy V and contributed several PRs which got merged, but there's definitely an attitude problem there. I gave up contributions because of it.

This user is not a member of the V team, and never contributed to the V project.

He enjoys language development and submits his feedback and ideas, discusses other ideas etc.

I do not work as a big censor and read every single of the thousands of messages, and I do not have time to do it.

That was a rhetorical question, I am not implying you should do anything. Thank you for the transparency.

Out of curiosity, I checked the discussion in which you referred to by link. The person in question is not a developer or contributor, but appears to be passionate about the discussion. I don't think it's bad to have a difference of opinion, even among good friends. In addition, we can't always be right on every issue, and sometimes we have to "agree, to disagree".

The other person in that discussion on V's GitHub even apologized for appearing harsh, seems to have begged you to come back, and gave you a compliment.

Also deleting your part of the discussion also robs other readers from evaluating the full merits of your side. There will usually be people on your side of the discussion as well or see your point of view. I think you will find that overall and from what I've seen, people in the V community can be appreciative and welcoming, but like anywhere its a mix of different personalities and characters.

Just like work, and in life, you're going to come across a myriad of people who handle criticism in different ways. Be it for cultural differences, deductive reasoning differences, even down to childhood upbringing, you know the story... We all do. It's 2022.

Not that you've done so; but others seem to reciprocate back with bullying, and with twice the force of any denials. A lot of people need to get the wisdom that others are different from them, and simply move on. The same threads, blogs, comments have come up on every single V post - living rent free in many people's heads.

Should the null hypothesis be that all languages deserve equal praise & blame and thus equal amounts of negative & positive critique?

Maybe this language deserves more criticism. Or people are biased against it. Could be either explanation, or something else. But there ain’t just one single possibility.

It's because V made impossible promises, and used those to get donations.

For example from wayback machine http://web.archive.org/web/20190520021931/https://vlang.io/d...: "(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."

When people called him out for this saying that this was impossible he doubled down on it and said that it's fine to say things like that because of the "work in progress", as if it was coming.

It turns out, it was impossible. V eventually had to add reference counting.

The worst part is that he used lies like this to get thousands of dollars from Patreon sponsors.

It seems like he's trying to clean up his act, but he's still making some dubious claims. He claims to have invented an "innovative and flexible memory management" reference counting algorithm that removes 80-90% of overhead. But there's no way to do that with mutable data, as far as i know. And sure enough, it doesn't work, users are still told to use the garbage collection option. If that turns out to be true, I might change my mind, but I fully expect that it's a false promise too.

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.

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

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

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.

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.

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?

V backer here. I've never ever felt remotely scammed or deceived. So people who bring up the scamming topic can continue to do so with the imaginary money they did not pledge/donate.

Also I see the Patreon topic a lot - Patreon is not a contract. If one is unhappy they can stop pledging ANY time, immediately. So like it or not, the Patreon support you see is a very accurate representation of satisfied backers as well.

Thank you for the support!

> Basically, do you have any guesses to why V seems to have more "enemies" out there, compared to lets say Rust or Go?

You have to keep in mind that V is an up and coming language, that is an alternative to Go, and somewhat to Rust. V is in the categories of C and Go alternatives. There are many other competing languages in V's categories, such as Zig, Odin, Nim, etc...

Not too hard to see how "enemies" and rivals can "pop out of the woodwork" to take shots, the more popular that V becomes or the more they might feel that V is a threat to their interests.

As for Go and Rust, they are backed by major companies, where "enemies" of their language will simply not get any or little media "airtime" nor enough traction to establish a negative public narrative that can stick. You can attempt to say something negative about them, but will be ignored or drowned out in various ways.

> ...it feels like V really brings out the people to come up with ways of criticizing it.

V is an up and coming language in the categories of both C and Go alternatives. This means a wide range of competitors and "acolytes" who may "come out of the woodworks" to take a shot at a rival, at anytime. The more popular they believe V is becoming or the more threatened by it that they may feel, the more likely we are to see "shots fired".

This is not to say that various criticisms are not or will not be valid. In fact, constructive criticism can be good and healthy. Among them, bringing bugs and issues to the attention of developers or having technical discussions with the language's community.

But, the negative or non-constructive acts (attack blogs, downvoting, flagging, gaslighting, trolling, etc...) do shed light on some of the odd heavy-handed, sneaky, or aggressive vibes that many of us can see. It demonstrates the intentions of bad actors or those acting in bad faith.

> ...absent when other new languages comes up (like Golang or Rust)...

Golang and Rust are backed by major companies. They do have plenty of "enemies" and competitors taking shots at them, but they aren't given the media "airtime" for their negative narratives to stick and their attempts get drowned out by the size of the language's userbase or amount of "infomercials".

Various other newer languages simply lack the popularity, userbase, or sponsors for most to even take notice or care. So they are simply not talked about.

The claims made in that blog post are easily verifiable. Your claim that all issues have been fixed was hard to believe, so I checked myself. The first two have indeed been fixed (these involve printing "nil" for a null pointer rather than crashing), but the third (undefined behavior on integer overflow) still reproduces. I didn't go through the rest of them, but expect a similar pattern.

I encourage people following the progress of the V language to look at actual facts rather than trying to evaluate claims based on the language of those claims. One of the reasons why V is so divisive is that a lot of untrue claims are being made (unusually so for a programming language), and people don't respond well to that being called out.

> The first two have indeed been fixed

> I didn't go through the rest of them, but expect a similar pattern.

You verified two issues were fixed, ran into one issue and then you expect a similar pattern of what exactly...?

Why didn't your comment go like this:

"Hey I went through to verify the these issues were fixed and I'm getting an undefined behaviour on integer overflow, here is how I tested (show code), are you able to reproduce this?"

That would be much less divisive and result in a proper discussion.

I think you'll find if you try to "call" people out instead of asking questions you'll be met with the same tone you gave them.

-- EDIT - replying to @paskozdilar below --

It could be that GP tested incorrectly? Since things are getting so serious shouldn't we see the code GP used to test before mob shaming?

You seem to be jumping to the conclusion the issue is not fixed. I don't think hurling "narcissism" is needed at all here.

Similar pattern of false claims.

Author has clearly stated that "all issues are fixed". The other guy found one unfixed issue. That makes the author's statement false.

I don't trust a person that lies, especially when they lie with such conviction and confidence. Reeks of narcissism.

-- EDIT - replying to @hunterb123 above --

I have reproduced the same error as in blogpost.

Hey, I went through another one of the examples, the lack of SFINAE, here's how I tested: I used the same methodology as the linked blog post. I'm getting the same compiler error as the blog post. Are you able to reproduce this?

Integer overflow works as expected, like in C.

Signed integer overflow is undefined behavior in C. Is it also therefore undefined behavior in V?

Thank you for posting such a beautiful example of a false claim about your language.

The front page of vlang.io has prominently featured under "Safety" the line "No undefined behavior". Saying that C-like undefined behavior[1] is "expected" directly contradicts that. I'll also point out that Nim, another language which compiles to C as a target, addresses this correctly.

[1]: https://raphlinus.github.io/programming/rust/2018/08/17/unde...

Your website says on the homepage "No undefined behavior". Integer overflow in C is explicitly undefined behavior. What does the phrase "undefined behavior" mean to you? Because it's clearly something very different from what it means to the rest of the industry.

I think there's a communication issue on your end here.

If someone raises an issue re: integer overflows, and you don't change the behavior, it's not 'fixed'. It may be 'addressed' or 'resolved' by responding with with something like "it's working as designed" or "if it's good enough for C, it's good enough for me!", but it's _not_ fixed. I don't think you should claim:

> All of the issues there were fixed several days ago

I really do like V FWIW.

Honestly... At this point, and after trying to engage constructively in other comments, I don't think the claims are actually intentionally false.

They may just come from a fundamental lack of knowledge about low level development.

So, the review was my only contact with V until today, and I have to say your response seems unnecessarily hostile. I understand there night have been a lot of negativity around your project and it seems to be successful despite these, so nice for you.

The post seems to spend quite a lot of time on the V language and discussing it, so I got curious and put in some of the examples into V for windows. The results seem to be different, but my knowledge on V is too low to understand the implications fully.

The "No null" experiment does not give a segmentation faul, instead it prints &nil. That seems to be effectively a null value to me though. Adding another layer of null dereferencing creates an access violation/sefault.

The undefined behaviour for integer overflow is the exact same as in the post. (edit: and in the github issues it is marked as "won't fix" it seems V does not care about creating undefined behavior in the generated C code, just that the behavior is defined within V.)

The overwriting of len for the array seems to be fixed as the capacity is increased to the value of len seems to return nil references now.

The immutable->mutable trick seems to be caputred by the type checker.

The remarks on included libraries seems to hold, as well as the "simple webserver" being 2MB when compiling (although openssl seems to be included now).

I have no motivation to redo all the other experiments in the blog post. And your response as well as the small checks leave me not-very-impressed with V, as I can't take any of the claims on the website seriously like that. If you claim it is a v0.1 or v0.3 language, sure, make a list of features that actually exist or a roadmap when they are reached. This is especially true for the "novel memory management" which seems optimistically to assume it worked before when a changenote is included that the compiler doesn't leak memory anymore by default. That is not particularly instilling confidence, although it's the right direction.

The post is unnecessarily hostile. Created by a new anonymous account, with the goal of attacking V and "not recommending to use it". Also with referencing the notorious ridiculous "V is vaporware" articles, it's pretty clear what the goal of the author was.

It'd take 10 minutes to submit github issues, instead they spent a month on this.

Null is only allowed in unsafe code.

Overwriting of len was never fixed, because it was never an issue in the first place. The author made it up. It's always worked like in Go.

Included libraries, you mean the json library that's part of vlib. So each Go program that uses net.http also has library dependencies by this logic.

>It'd take 10 minutes to submit github issues, instead they spent a month on this.

If the author put in the work, I don't see the problem with it being a blog post. Also, given the history of github comments / issues being removed from the vlang github project, I don't blame them for wanting to keep their post for posterity.

Lol, no issues/comments are removed.

One and only time a github comment was removed was before the open source release and I just started this new job of an open source maintainer.

Actually, sorry, I did remove one issue recently. It said "Delete this project, it's a joke".

This is all around a terrible and nonconstructive attitude.

> The post is unnecessarily hostile. Created by a new anonymous account, with the goal of attacking V and "not recommending to use it".

What about it was hostile? It was written in a very neutral tone and was almost exclusively fact based, with just a couple of summative comments about the author's overall impressions at the end.

How could you possibly know the motives of an anonymous author? Seems like the author was smart to remain anonymous too, given the amount of vitriol the V community has directed his/her way for writing the review.

> Also with referencing the notorious ridiculous "V is vaporware" articles, it's pretty clear what the goal of the author was.

Of course a review will mention a widely circulated previous review. As much as you might like to pretend that it never existed, this isn't the CCP where we can expunge things that we don't particularly like from the historical record.

> It'd take 10 minutes to submit github issues, instead they spent a month on this.

I see, reviews are only okay if they are positive. Otherwise they must be github issues. What a convenient way to make sure that no negative review is ever "by the rules" and to question the motivations of anyone who dare write one.

> What about it was hostile? It was written in a very neutral tone and was almost exclusively fact based, with just a couple of summative comments...

The review started out hostile by links to blogs and posts that smear V and the author from outright competitors and detractors! Completely unnecessary, if the purpose of the review was to stand on its own merits. It also sets the tone, of not being neutral, from the very start. And, links itself with other attack blogs and threads from the past. It made itself the newest link in the chain of attacks.

The review is highly opinionated. It's an evaluation of claims, where the author gives his opinions on their validity. The author never gives readers his qualifications for even being able to properly evaluate the language, and uses a throwaway account, where he can easily run away. The V developers are held accountable for their opinions, but not the reviewer. You can never hold the author of the review accountable for anything he got wrong, was mistaken about, or is missing.

It's also not a fair or objective evaluation, where he sought to get any input from V developers to clarify their positions about claims made. So it's his own one-sided perspective. He is going to be one-man judge, jury, and executioner. And that one-man judge's sentence is, "...I would not recommend spending time on V". Which is clearly very negative. It is also very presumptuous, that readers should come to his same negative conclusions, versus do their own evaluation, check out what the V community has to say, or check out the latest version of V.

> I see, reviews are only okay if they are positive. Otherwise they must be github issues.

Nobody said that reviews must only be positive. What is being conveyed is that if the reviewer really had a problem with using V, wanted it to become production-ready, or wanted something fixed then the way to do it is to submit issues or discussions to V's GitHub.

Otherwise, it shows the intention that one's purpose is not to fix anything, but to spread drama and smear. The reviewer has a throwaway GitHub account, where it would have been easy for them to verify various conclusions with developers, submit issues, or create a discussion at V's GitHub site.

> Null is only allowed in unsafe code.

That’s clearly not the case, as the exact code in the post prints ‘&nil’ in current V master, and if you add a dereference you get a segfault (which someone else just filed as https://github.com/vlang/v/issues/14911).

> Overwriting of len was never fixed, because it was never an issue in the first place. The author made it up.

The home page claims the language has “no null (allowed in unsafe code)”. println(*[]&int{len: 1}[0]) is not marked unsafe, yet it still segfaults by dereferencing a null pointer. Can you explain why you say this was never an issue?

(I’ve filed this as https://github.com/vlang/v/issues/14914. A related issue in maps was filed a year ago: https://github.com/vlang/v/issues/10837.)

> It's always worked like in Go.

Go is not a language that claims to have no null.

> The immutable->mutable trick seems to be caputred by the type checker.

Just add the immutable variable's reference to a mutable array, now mutate the immutable variable using array[0], magic!!

The compiler is so basic and naive, it's laughable how their authors have guts to fight everyone about it's stability.

I think you're missing the point here Alex. The amount of work you've put in, the number of projects you've made, and the drive you have are amazing. Everyone wants you and V to succeed but you make claims that are not true yet. You claim V has safety features but if it's trivially easy to exploit those safety features, then you don't actually have safety features. You claim V is as fast as C but there are many many many cases where V is slower than C. On average, V seems to be much slower than any compiled language. You claim V can compile a million lines of code in a second when that is not the average case. You claim V can do so many things but each time someone actually tries to verify those claims, it turns out there are many cases where it's not true or only true in one very narrow, specialized case.

When people read "V compiles itself in less than a second", they expect V to compile itself in less than a second for the general case (not just one very specific case). When people read "as fast as C", they expect V programs to have the same runtime as equivalent programs directly written in C. When people read "no null, no globals, no undefined behavior, immutability by default", they expect there to be no issues with this 99% of the time. When people read "Despite being at an early development stage, the V language is relatively stable", they don't expect this number of issues. I could go on, but the V documentation is filled with this.

In my opinion, if you keep going in this direction, no one will ever take V seriously. You might get some GitHub stars, you might get some inexperienced language developers helping you out, but if people can't trust V's claims, if V's claims continue to not hold up, no one will use V anything more than casually.

The simple solution to this is to walk back your claims and preface everything as unstable which is more accurate. Your GitHub description should make it obvious this is an experimental language with many issues. You should only list features in your README which are true and work for the average or general case. Any other features can be listed somewhere else as in progress or testing. Toning down your marketing is all it takes to earn back some trust.

> You claim V is as fast as C but there are many many many cases where V is slower than C. On average, V seems to be much slower than any compiled language.

This is false.

> Everyone wants you and V to succeed

The same people who write articles about V and say V should die?

> This is false.

Ok could you provide some benchmarks supporting this? I admit the article could be cherry picking benchmarks.

> The same people who write articles about V and say V should die?

Anyone saying that is probably fed up with the inaccurate claims. If you just make it clear to the user what features are in progress and that V is in an experimental state, I don't think anyone reasonable would have a problem with it.

Do you understand what I'm saying with the rest of my comment? Languages typically have a lot higher threshold of quality (a lot less bugs) when they say they have a feature implemented or when they say the language is "relatively stable".

Sure.

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

> they expect V to compile itself in less than a second for the general case (not just one very specific case).

What on earth are you talking about? There's no specific case. Check the video. Try it yourself. Have you actually tried it?

Can you list the inaccurate claims here please and in progress features that are not clear to the user?

As Rust proved it fast, safe and simple don't go together (fast and safe requires borrow checking on the data types, which is complex).

That "review" was a thinly disguised hit piece against the V language.

1) The "review" is now significantly wrong and already outdated.

Doesn't mention it is reviewing an Alpha or even the version.

Anything of substance in the review was mostly minor and has already been fixed:

https://github.com/vlang/v/issues/14803 https://github.com/vlang/v/issues/14787 https://github.com/vlang/v/issues/14786

2) The author of the "review" used a throwaway account for the apparent purposes of recommending to not use V.

The author of the "review" can run away and hide, where the creators and developers of V are accountable to the public and supporters.

This includes that the author of the review never has to update or make corrections to his hit piece, while still spreading links to it all over the internet.

3) The "review" is used as a linked reference document for further attacks by competitors and detractors. And as has already happened on various other internet sites, including here.

4) If the author of the "review" was really eager to use and fix the V language, he could have brought those issues (he has a GitHub account) to the V GitHub (https://github.com/vlang/v/issues).

Who is going to fix any issues that the author believes is a problem?

It is going to be the V developers. So if the author of the review wanted those things that he believes are a problem fixed, that's who he has to bring them to.

5) The author of the "review" starts it by linking to a number of very contentious posts from competitors and detractors of V, to include those that smear the author and language.

This turned the "review", right off the bat, into setting off drama. A smear campaign on the V language will never get any of the issues fixed on its own, just only invite more drama, smearing, and attacks. Which looks like the original intent.

6) The author of the "review" has shown no interest in working with V developers, and that's prior to publishing the review and spreading links to it.

No intent has been shown to modify his review for correctness, fairness, or language version.

7) The author's review doesn't provided the necessary context and is highly opinionated.

Without feedback or the opinions of the V developers, this is a one-sided negative review full of many debatable points, that does little to help readers outside of trying to produce a negative impression and smear the language.

If the review author is not interested in working with V developers, and rather produce and disseminate drama or facilitate smearing, then that's a reflection of their real intent.

V minor contributor here. My 2 cents: I do get the feeling claims were founded/solid but am not an expert on the subject.

Article's author citation related to V's version which got tested:

> I’ll be using the current version of V built from git which is 50ab2cfd1ae02d4f4280f38c60b8dbd17f7599f6.

To be perfectly fair to the language, for me, it was love at first sight. Syntax is beautiful.

If ever V reaches maturity (0 segfaults + addresses concerns raised in Reddit, HN and other sources such as ^), I would definitely prefer it to Golang, potentially even Rust.

Not to mention its future is secured if C projects are ported to V.

Thank you for digging! I really appreciate your attention. There are lots of bug fix in 1 year, and will be better time by time. I started to use Vlang 1 year ago, and I created lots of ISSUES on GitHub, and most of them are already fixed.

I like Vlang (also like Rust and ...) so, I'm happy for your attention & deep insight. I hope you to dig and share again sometime.

I've been following vlang's GitHub issues lately and it feels like every second issue is about broken codegen in areas which seem so basic you wonder why it was even merged in that state. So I have mixed feelings about this. On one hand, the list of features/fixes is impressive and there's a growing community, and even a book, on the other hand there are endless edge cases which weren't properly thought out/tested and which break the compiler. Maybe vlang needs some sort of fuzzing?

Interesting. I have always felt the opposite. It's always been stable for me, that's why I rewrote V in V so early.

We also have thousands of tests.

Do you have any examples?

Right now on the very first issues page 5 issues out of 21 (if we skip feature requests) are about broken codegen (i.e. C errors). I'd expect a stable implementation to have very few codegen problems, not like this; I'd expect something like subtle correctness issues or various bugs in the standard library to be much more common (larger surface area).

Another interesting example is this: https://github.com/vlang/v/issues/14804

Passing a variable to a function works, but passing a string literal doesn't. I wonder why stuff like that even happens, it leaves an impression that the compiler has hardcoded special cases internally and breaks on input which wasn't foreseen by the implementation authors. Your solution is to get rid of the method entirely instead of fixing it, which is also somewhat strange to me. Can you explain?

>Interesting. I have always felt the opposite. It's always been stable for me

It could be that the patterns you use when writing V code are well-tested but when someone strays from the path and does something you wouldn't do when writing V code it easily breaks the compiler.

strconv.v_sprintf is an internal function only used by the compiler in string interpolation. It should simply be made private.

Are there plans for docs to be updated? The 0.3 release notes claim:

> Option and Result are now separate types: ?Foo and !Foo respectively. Old code will continue working for 1 year and will result in a warning/hint.

Yet, doc/docs.md still states:

> V combines Option and Result into one type, so you don't need to decide which one to use.

Is there an up-to-date doc, or how does one find out more about these types? I found parts of the RFC overhauling the error handling [0] pretty bizarre, so I'm interested to see how the implementation turned out.

[0]: https://github.com/vlang/rfcs/pull/7

edit: linked to the wrong RFC initially.

Good catch, these are supposed to be up-to-date. Will update asap.

Combining them in general makes sense to me, at least to the extent of having an Optional<T> be an alias of Result<T, ()>.

There are some obvious cases where a none optional is separate from failure, like a hash map lookup or an element from an iterator. But I often also see optionals used to signal e.g. an unparseable string, where it would seem equally reasonable to return a Result or throw an error.

I’ve been writing a lot of Swift lately, and because it uses `throws` rather than a Result type, it’s made the often arbitrary choice of returning an optional value or raising an error more noticeable to me. Especially when using `async`, as pretty much everything declared `async` also throws, so if an Optional is actually what you want to return, you get some fairly gross boilerplate at the site of use:

    guard let value = try await getValue() else { … }

This has turned into a bit of a ramble but my main point is that implementing Optional as a Result with void error type makes a lot of sense in my head.

Yeah that was my idea initially when I designed the language.

I don't think any other language has them merged.

There were issues later with the 3 states (Ok, Error, none) instead of a simple binary state.

Since the `or {}` block handles the "not Ok", developers had to check whether it was an Error or a `none`, it's not pretty.

Requisite: what is this and why should I care? From the Github page:

Simple, fast, safe, compiled language for developing maintainable software. Compiles itself in <1s with zero library dependencies. https://vlang.io

I first learned about it from https://simonknott.de/articles/vlang (2019), which was an interesting introduction, if a touch dated now

It can be thought of as Go but with faster and easier C interop, and better optimization brought by Clang/GCC's -O2.

But also with nice additions like sum types, enums, string interpolation, if expressions etc. Full comparison here:

https://vlang.io/compare#go

>It can be thought of as Go <..> also with nice additions like sum types, enums, string interpolation, if expressions etc.

I've noticed the language design itself is rarely criticized, it's mostly about the implementation. So I think you're on the right path here.

I've had my eye on this language for a couple months; in particular, V UI subproject, a SwiftUI-like code-first framework for doing GUIs, caught my eye, since I rather like SwiftUI and I still need to make a human-friendly KyuWeb client for the server to be of any use. Unfortunately V UI doesn't seem to have progressed much since I last had a look on it. Here's hoping it gets the attention it deserves, because from what I've researched of GTK, it looks about as fun as a kidney stone to use, and having a modern low-level language with a closely-integrated, cross-platform modern GUI framework could really put V above the rest (SwiftUI does not have first-class support outside of Apple platforms currently).

https://github.com/vlang/ui

(I'd also like to see first-class support for the BSDs, but I know better than to hold my breath on that one.)

Wow. Despite a lot of the negativity here, V looks great. I might take a stab at writing something over the weekend with it. Congratulations on the release.

I don't care about all that fuzz-buzz, no nitpicks here as well, all I care about is here:

https://github.com/vlang/v/issues

Lovely language, but above scares me off for now. Respect to all involved and hope one day will be a day where there will be only a super sophisticated bugs left that affects 0.01% of users.

Before using V I had a similar concern. However I then looked at Go and see it has 7.5k issues on GitHub. Granted much bigger user base = more stuff uncovered.... So for right or wrong, 7.5k issues in 100K stars versus 750 issues on 30k stars... It doesn't look so crazy suddenly. Personally I like to see issues as it means people are actually using the language, finding bugs, and driving incremental improvement.

A project with 0 issues barely indicates flawless implementation no more than the possibility it simply has 0 users.

May I ask what for you're using V? And what are your biggest concerns about V at this stage?

I'm using V mostly for data science related applications (in production). Honestly my biggest fear is that this constant V backlash is going to do serious harm to the community and seriously impede development/adoption... I have no concerns with the language itself or the development thereof - only the consequences of threads such as these, which surface every other week. I entered in with realistic expectations from something that is version 0.3; unlike others who seem to think version 0.3 means "Mars lander ready".

I think V will persevere, because the community has enough support and momentum to continue, and because the direction and syntax of the language will continually attract as well.

Even the outrageous trolling and harsh criticisms also brings attention and curiosity about the language, that other developing languages can't and don't get. V will stay in people's minds and on their lips, keeping it popular. Many critics will say one thing, but will also be trying and using V, and it has been the case they become contributors to the language or are eager to see its next release. As the language makes corrections and continually improves, it's "baptism by fire", will make it even more viable and useful upon each release and in the long run.

All popular languages have more open bugs on github.

TBH, I have criticized V before, because when it launched things and claims were weird and maybe inflated, honestly don't quite remember looking at V in a good light is still hard for me.

But I am willing to give it a try, so here's a shot. Can you pls, explain a few things in short really don't want to read all of the docs to figure out the basics.

1. What platforms are well supported by V and how does it work non traditional or extension based C code?

2. What happens for edge cases where the C compiler quirks are being used for code when you transpile C to V?

3. How safe is V really? Like is it memory safe, if so maybe a quick description as to how, does it provide a memory model? What about an ABI? does it match the platform C ABI or something?

4. What happens to linking to C code, is it as easy as Zig? maybe something like zig cc?

5. How is the multithreading in V? Does it have something like openmp atleast something like rayon or do we use platform threads?

6. What about the C++ interop? anything interesting more than what other languages can do?

7. What's the current state of the compiler in terms of stability? And especially the std lib?

8. Lastly anything you want to point out as a very interesting feature in V that is not hype but so comfy that I would like to atleast use V somewhere in my stack? Maybe something like Zig's cc or Nim's metaprogramming or Haskell's mind bending type system, Idris's dependent types, etc.?

Preferrably not like Rust's safety thing, I love Rust but just saying things like it's safer is very weird claim without any context. Just some details are fine no need to waste your time on making a hater change their mind.

Personally I am trying to keep open mind to things, I might be harsh because of ignorance or preference or just because of being a young douchey programmer but being mean to something that has stuck around, and where a bunch of people seem to be putting in effort somehow seems worse than just shitty on it, even if it's a scam.

Do you actually expect a response to that wall of questions? If you're that interested please read the docs, it's not that hard.

Fixed the formatting, reading the docs takes time and in case of languages they don't give a lot of critical information about it's state in the docs, I have worked from Haskell to Rust to C++ professionally never has the language docs told me all the key details about the language to make a selection I was only able to get into them after months if not years of trial and error.

I am not gonna pretend I have any love for V, but I will say I might look into it but spending several months or years with the language when I have such limited free time is not an option for me and many others.

I fixed the formatting so it should be more clear as well. If no one wants to answer then fine I didn't ask the questions to get a definite answer as I said I am not entitled to an answer I just would like to know those things.

I can wait for V to one day take over the world, die off, or someone to just make more fun memes. I don't really have a dog in this fight.

1. Windows/Linux/macOS/Android/iOS/pi/WASM/*BSD/Haiku/SerenityOS

2. For stuff like i++ expressions, V allows them. Some stuff gets translated to adapted V code. Some (~2% of the syntax) will result in an error. Those will be fixed this year.

3. Memory safe, bounds checking, C ABI.

4. Ridiculously easy. The main reason it was created (was using Go before). Just run `C.foo(1,2,3)`. Use C2V to generate V wrappers.

5. Only system threads for now.

6. Same as with C. Need export "C".

7. Very stable, at least for me. Never had a crash/segfault.

8. Hard to pick. Fast compilation, hot code reloading, nice clean sum types, clean json serialization and ORM (mysql,sqlite,postgres).

Cool thanks for a quick run down.

With 30K stars on GH, I feel late to the party but Vlang looks amazing. Given this is the 0.3 release, it's almost shocking how much has already been achieved.

The comparison page was very useful to quickly get a feel for V's "aesthetic" and design goals: https://vlang.io/compare

Thanks!

Indeed, a lot has been done.

Almost 14k commits with a clean linear history (no merge commits), 7200 PRs merged, 500+ contributors.

We have an amazing team :)

The comments on this thread are suspiciously hyperbolic.

Which ones? The positive ones or the negative ones? I posted one of the positive ones.

I've been following V with interest for a while (a few years, maybe?). It got a lot of shade early on, somewhat justifiably-- the initial claims were highly suspect. Past V comment threads on HN leaned very negative.

That said, I like V. I'm glad to see the maintainers are still chugging along despite the criticisms. It gets better with each release.

I'm still not doing anything in production with it, as it's pre 1.0, and the Postgres performance issues are still a blocker for my production use-cases. But, I really hope to someday have V in my toolbelt for the places where I currently reach for Go.

Follow up for any future readers. The Postgres perf now seems acceptable. Slower than Go’s pgx library, but within the same ballpark.

Great job with the language. I’ve always found the controversy quite interesting. You know you’re doing something right when everyone attacks you. How did you get GitHub to support V just one month after release?

Thanks!

This is how GitHub started to support V:

https://github.com/github/linguist/pull/4564

Can I suggest: On your github homepage (https://github.com/vlang/v) you should put some sample code, I scrolled all the way through it and did see anything.

There are tons of examples in the examples folder

There are indeed lots of examples in the top directory `examples/`.

Also there's a big link on vlang.io, top menu.

Also view the Docs link just below the V logo, on the link you provided. It's true quite a bit of projects these days put sample code in the readme... But it probably isn't where code examples belong. Certainly wasn't the trend in 90s or early 00s.

The v2048 webassembly game demo crashed not just Chrome browser but my entire IPHone SE causing it to reboot. I reproduced this twice now.

Thanks, will have a look. wasm is not tested by CI unfortunately (yet).

I'm curious about the status and/or roadmap of REPL for vlang? Do you plan for an expressive experience with the REPL, like in interpreted languages (python, ruby...), or it just compiles each line?

REPL compiles each time, but we also have a WIP interpreter. That one is the real thing :) Not finished yet.

https://github.com/vlang/v/blob/master/vlib/v/eval

Googling anything related to this language must be fun

"vlang" works fine :)

But probably ommits potentially useful matches where the language is referred to as "v"

Yeah that's true. And searching for it in chats is a pain. Lots of youtube.com?v= links instead...

Dupe: https://news.ycombinator.com/item?id=31930011

It's not a dupe. This submission was falsely mass reported and removed from the front page within minutes.

After emailing HN mods, the flags were removed 18 hours later, but it was gone of course.

I've asked HN mods for a permission to re-submit this.

I find it funny that as soon as you [0] asked someone to list these major bugs in V especially when it turned out that they haven't used the language, they begin to continue their regular deflection and dodging of the question.

It is a pattern I keep seeing here on HN, but its great that V hasn't given up and it is still active and maintained. No idea why this post was flagged.

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

Wanna know something funnier also posted in previous thread? The hello_world.v has potential memory leaks. I tried it myself and got a similar result. Somehow the creator cannot reproduce this.

  ==57519== LEAK SUMMARY:
  ==57519==    definitely lost: 0 bytes in 0 blocks
  ==57519==    indirectly lost: 0 bytes in 0 blocks
  ==57519==      possibly lost: 816 bytes in 3 blocks
  ==57519==    still reachable: 0 bytes in 0 blocks
  ==57519==         suppressed: 0 bytes in 0 blocks

[1]: https://news.ycombinator.com/item?id=31931083

edit: Got something even better.

  $ valgrind --leak-check=yes v examples/hello_world.v
  ...
  ==58037== LEAK SUMMARY:
  ==58037==    definitely lost: 4,463,772 bytes in 106,561 blocks
  ==58037==    indirectly lost: 5,275,772 bytes in 84,005 blocks
  ==58037==      possibly lost: 0 bytes in 0 blocks
  ==58037==    still reachable: 47,149 bytes in 263 blocks
  ==58037==         suppressed: 0 bytes in 0 blocks
  ...

You can stop spamming this nothingburger. 816 bytes is probably due to some GC overhead. It's nothing.

"Probably" doesn't cut it if someone is going to user your language. Let's agree that this isn't a serious matter though. The compiler leaking is nothing as well?

It's not probably anymore, you're too late. See the message below.

And no, 800 bytes is not a serious matter.

I do think V is amazing and has a bright future. Thank you for putting time in it.

If I may, I still believe even 1 byte is a serious matter imho.

I'd agree if it was happening in a loop somewhere. And a long running web service would leak memory over time.

This doesn't happen, we have V web services running for months without leaks.

But since there were several responses with this message, I'll make sure valgrind reports 0 :)

Ahhh, if only Electron or Chrome shared that sentiment =)

Electron or Chrome are not the topic of this thread.

I also don't appreciate whataboutism, sorry.

This type of hostile response to a very valid question is why you are not changing the opinion of many users here on HN.

A leak is a valid concern, because it implies problems with memory management.

"We choose to not free some memory on purpose" can be a valid explanation , but needs more context.

You could be more persuasive by linking to the relevant code and explaining what memory it is and why you are leaking it.

Otherwise your responses just seem like deflection.

I'm sorry but this is the truth.

This is completely irrelevant. Each V program uses an extra 800 bytes.

If you look at what actual performance and low resource usage V brings to the table, you'll see it's not a problem at all.

Well... I tried!

Since it seems to be important to many people here, I'll make sure valgrind reports 0 bytes :)

You are missing my point!

My post wasn't about this concrete issue, which can also be explained.

My point is about a civil discourse culture driven by (precise) technical arguments,not hostility or deflection. Which I am not seeing, which is why you only increase the skepticism here rather than change minds.

Unless the leak was actually unintended and is a bug.

But that's also fine, any language (old or new) has heaps of bugs in all corners of the codebase. But then just own up, explain and fix it.

How is it a civil discourse when OP led off with

> Wanna know something funnier also posted in previous thread?

This wasn't a good faith attempt to report a bug from the beginning. It's just an attempt to score points off of V.

To my defense the GP to which this was answer to led off with

> I find it funny that as soon as you asked someone to list these major bugs [...] they begin to continue their regular deflection and dodging of the question.

which I found dishonest (especially since those bugs are well described in the post the commenter linked) as the exact opposite happened in the same thread.

Why is this a nothingburger? If you're making the claim that it's safe and it actively leaks memory, how do we know it doesn't also allow buffer overruns or double frees?

It would be nice if you allowed an option to compile with memory tracking so that as a user of the language you can debug this sort of stuff to make sure it's not a big deal waiting to happen.

800 bytes in some GC cleanup is not "actively leaking memory". It's a nothingburger.

We know it's not a big deal, we have lots of valgrind tests running on CI. And we have V web services running for months and not leaking memory.

Reproduces on GitHub Actions: https://github.com/judge2020/test-v/runs/7150691976?check_su...

Like I thought, this is some minor GC overhead.

Wouldn't be there with `v -gc none hello_world.v`.

I checked with valgrind too and see similar memory leaks. Is v compiler written in vlang yet? I see lot of warnings and leaks for the compiler.

It has been written in V from the start (the first public release).

V doesn't free memory when building V for performance reasons.

A compiler is a perfect example of an app where freeing memory is totally fine on exit, by the OS.

Fortunately V is efficient and doesn't result in gigabytes of RAM used when compiling large bases of code (V itself is about 110k loc + 100k of vlib).

Once there are code bases that require gigabytes of RAM, we'll add an option to free it as it goes.

Yeah it's a common pattern :)

Interesting to note that this thread was also flagged (now restored) within 40 minutes of it being posted.

Yeah it's happened 4 times in total now.

You do not engage with criticism in good faith. This is a reoccurring problem in all your threads. This is why you get down voted and flagged. It's not a conspiracy against V, it is your own behavior.

You may want to be specific, all criticisms were addressed by the author in this thread.

Also, this thread was flagged before any criticism was posted btw.

You'd think those people that wanted their criticisms addressed in good faith wouldn't flag a new release that solves their criticisms.

Yeah, please be specific. I've received so many vague accusations like this, and never ever were any actual examples given.

Unsupported ad hominem against the person and technical assertions without any evidence: https://news.ycombinator.com/item?id=31946432

Unsupported conspiratorial assertions: https://news.ycombinator.com/item?id=31946840

You know what the common thread in all the problems and issues you identify in this post? You communicating poorly: https://news.ycombinator.com/item?id=31946635

This is not a constructive way to engage with someone, even if they are spamming: https://news.ycombinator.com/item?id=31945932

I'm not even sure what to say about thread, you got all hostile on someone who was basically on your side because the blogs post you hate made him think something that you yourself agree with which that V is not production ready? This person might have come back to check out your 1.0, but I doubt they will now! https://news.ycombinator.com/item?id=31930435

And just the level of cognitive dissidence here. Why are you mad about someone calling your 0.3 not production ready software immature?

  It's interesting how you can call the language immature without even trying it.
  0.3 pretty clearly means it's not production ready software.

I'm not even that far back in your comment history. That's all the free emotional labor I'm willing to do for you today.

Edit: Also I don't want to be the tone police, but I stepped past a lot of comments that seemed to run afoul of the "it's not what you said it's the way you said it" rule. My last piece of advice would be to read through your comments and ask yourself if the tone of them is best for achieving your (I presume) goal of promoting V.

Without any evidence? Really? Here's the account I was talking about: https://news.ycombinator.com/threads?id=vlang1dot0

Everything else can be found in the "V is scam" articles. There will be a big article by me covering all that.

"Immature" != "not ready for production".

Regarding that immaturity comment, here's a good summary by someone else from this thread:

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

One troll does not prove everything else is a conspiracy.

>"Immature" != "not ready for production".

What? https://www.merriam-webster.com/dictionary/immature

It takes a lot more than one troll to mass flag a post 3 times within a day.

Why is assigning a constant unsafe?

    struct App {
    mut:
        gg &gg.Context = unsafe { 0 }
    }

https://github.com/vlang/v/blob/f0cee25213e25289ae4c60ba9a6a...

Because it's null (unsafe{0} will be replaced with unsafe {nil})

It needs to be inited recursively with

app := App { gg: &gg.Context { ... app } }

And that doesn't work yet. It used to work in the initial V, but not right now.

It'll be fixed in 0.4.

It's interesting how the language author of V was bullied and harrassed for his early language [0] and with time V has made very substantial progress with C2V [1], and an OS written in V [2] and various language improvements.

This (and many future updates of V) has now rendered pretty much most criticisms in this attack post irrelevant, after all of this V is gaining traction, a community forming around the language and with great backing, It goes to show that programmers are far too quick to jump the gun on languages.

I congratulate Alex for persisting on V.

[0] https://xeiaso.net/blog/series/v

[1] https://github.com/vlang/c2v

[2] https://github.com/vlang/vinix

Thank you!

There's also Gitly, which we're launching next week.

https://github.com/vlang/gitly

Publishing a few critical articles is not bullying and harassment.

Yet we see this harassment continuing on this thread. The article I linked is just a drop in the ocean.

Nitpicking over leaking bytes and language features every release is exhausting for the language author when we both know these will be fixed in another release.

The fact I see activity in language and that the author is active gives me confidence in V.

> Yet we see this harassment continuing on this thread. The article I linked is just a drop in the ocean.

Which comments on this thread were Xe Iaso's?

> Nitpicking over leaking bytes and language features every release is exhausting for the language author when we both know these will be fixed in another release.

I don't know what will be fixed in another release. Nitpicking to you was useful to decide if V was worth my time now.

Who said it was just that person? The harassment is still continuing on this thread and has happened on other threads and posts where V is posted.

You said Xe Iaso bullied and harassed the V author. I said the articles weren't bullying and harassment. You said this harassment continued. Did you mean you were wrong about Xe Iaso but other harassment started?

> The harassment is still continuing on this thread

I saw little or none. I understand it feels like harassment when someone believes their critics are conspiring and malicious.

Yes, it did, it is bullying and harassment no matter if it was past or present. I would also go to say it is pretty much toxic behavior as well, and yet it is still continuing on the V author by others in this thread.

> I saw little or none.

I've assumed you read the comments against V in this thread and it seems like you clearly haven't.

Also, you're not the person being harassed about memory leaks after the author said this was fixed already.

Hi, I'm Xe Iaso. I'm never going to write about V again. I'm only keeping my old articles up out of a desire to not break links. Even if I took it down, it's still in the internet archive's wayback machine, so there is no point in me removing my articles.

If the V person unblocks me and unbans me from the places I've been banned from (at least Twitter, GitHub and Discord), I'd be happy to add a disclaimer about the post being "out of date".

I want V to succeed because competition is good, but I also need to call out misleading statements for what they are.

Believe what you want, but I did not write those articles in an attempt to "smear" or "defame" V or its team. I regret writing these articles as they have created negativity and hate that is slung around like candy for no real reason. I have no plans to write anything about V on my blog in the future and this experience has taught me many things about how to write about programming languages in the future.

> I've assumed you read the comments against V in this thread and it seems like you clearly haven't.

Try imagining someone can disagree with you.

> Also, you're not the person being harassed about memory leaks after the author said this was fixed already.

Disputing the author's claims is not harassment.

So, it's V v0.3?

What is with programming languages and terrible names?

I think it’s a cool name. Or I guess letter. You can nickname it Victor if you want.

Except that it's incredibly hard to search for if people just call it "V" and not something like "vlang". I was trying to search for a thread I saw about it on Twitter and failed miserably, even with the "posts by people you follow" filter, because all the results were about various "X v. Y" court cases.

Well, how do people google for C, or D, or R? Normally with a query like "d language", right? And indeed, googling for "v language" gives me vlang.io as the first result.

I intentionally didn't use Google as an example. Major search engines obviously have tricks to index things like this, though I'll note there are still gaps. For example, googling "v language data structures" produces nothing related to V itself.

That said, I'm specifically talking about trying to search things that Google doesn't index, like a Discord server, an internal wiki, or a specific non-textual filter on a public site. As mentioned, I tried searching for a specific Twitter thread about V from people I follow and didn't find it because they just called it "V", which on Twitter returns a ton of results for things like court cases.

I'm sure if I spent forever massaging my query I could track it down, but if it was called "vlang" or "VL" or something similarly distinct it wouldn't be a problem. For example, PHP, Perl, OCaml, SQL, Prolog, etc. are all quite easy to find regardless of where and how I'm looking.

Just like with Go/golang, "vlang" is used for searching.

I just downloaded V. The following V code segfaults, much like C would:

    struct Node {
        val   int
        left  &Node
        right &Node
    }

    fn main() {
        n := Node { 123, 0, 0 }
        m := *n.left
        println(m)
    }

That's a bug, the compiler should require `unsafe { n := Node { 123,nil,nil } }`.

Just found my new hobby, learning V! Love the batteries included approach here. Kuddos :)

Enjoy! The documentation also works as a tutorial, pretty much.

> performance of C on the web > Simplicity: the language can be learned in less than an hour

This sounds like a killer language. Gonna try it out on a small project.

Hopefully it lives up to it's promises.

Anyway, congrats on 0.3.

Thanks!

To be fair, "in one hour" was updated to "over a weekend" on the home page. I just did the same in README.md.

The language has definitely grown as you can see by the size of the docs.

But it's definitely not bigger than Go, and that one has always been famous in the industry for being simple.

The best thing is that V is always going to stay small. No constant changes and new complexity (looking at you, C#).

I'm still excited about V and impressed by the progress they've made. It's been a fun language to tinker with.

This looks pretty interesting and I have a few immediate ideas for use cases.

I'm getting a 504 from CF when trying to look at the vpm site currently, so I can't look around what the situation with packages is like.

I will for sure check back later and play around with it over the weekend, maybe.

vpm has been restarted, I'll move it to another server soon, this one is too busy

Feels like so many great languages are coming out at the moment, or at least I'm only just learning about them. Though a language that can be learnt in an hour and has the speed of C might just bump this one up to the top of my todo list

Previously on HN https://news.ycombinator.com/item?id=20230351

Ah yes the famous glfw dependency of the V compiler. Complete scam.

How dare you earn more than zig!?

The audacity!

What a great surprise this language is

Zig looks bloated compared to this one

V is slowly becoming a realistic threat to Rust.

Or, if you like to see the world as a playground for collaboration rather than arena for competition: V is slowly becoming yet another language to play with, together with Rust and all the other fun languages that are coming alive

VLang is genius language. It's less boilerplate than Go, safer than C, simpler than Rust, and it's fun to use. Waiting for a Monad tutorial in V, ahh no, it's built-in.

VLang is the best language to me now to develop server-side application.

Thanks! Glad you like it :)

Golang + Rust = Vlang

You could say that. A very simplistic way to sum it up.

There's no ownership in V and it's not planned.

But it does borrow immutability, sum types, some elements of memory handling.

V is much closer to Go, about 80% close I'd say:

https://vlang.io/compare#go

Reply on news.ycombinator.com