Yeah, still very new to all this, also it was my first posting on HN and I haven't actually received any meaningful comments on any platform or any guidance about the conventions and stuff. If you check out the article there is only 1 comments there while here it is about 170 now so I am learning a lot.

Actually, V's author was gracious enough to come to HN to address and answer a number of users (including on this thread). This includes that he has previously answered questions by vlang1dot0 (on other threads), despite repeated attempts at spreading misinformation or the obvious and continual trolling (with just the username alone).

If you notice, HN doesn't have zig1dot0, nim1dot0, or odin1dot0 accounts trolling any threads they can find pertaining to the language or alluding to why they aren't at 1.0 yet. Despite the fact that both Zig and Odin started around 2016 (3 or more years before Vlang) and have yet to achieve 1.0. Zig only managed self-hosting this year (2022), after more than 6 years of existence. Nim took 11 years to reach 1.0 (created 2008 to achieved 1.0 in 2019).

Add to this, the incessant and demonstrably false claims that V is vaporware or fake despite it having over 90 releases, applications written in it, and thorough documentation about the language.

https://github.com/vlang/v/releases (releases) https://github.com/vlang/v/blob/master/doc/docs.md (documentation) https://modules.vlang.io/ (modules)

By the way, types in V are zeroed by default. Zeroed means that they are assigned default values. Empty string for string types, 0 for integers, and false for Boolean types. When not sure what to initialize variables with, it is recommended to make them mutable, so to be updated as needed. In V, you don't assign null or nil. There isn't any *ptr = NULL or Var := nil. That is the context in which they are referring to.

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

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

Sure. I’ll open an issue tomorrow when I’m back at that machine.

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

Exactly. Yet and for example, Zig and Nim articles are posted at will without issue. Recently, Zig related ones have been very numerous, as if people had invested stock into it. In contrast, Vlang related ones often get flagged for unknown reasons. Quite strange. Where is the fairness?

vweb, volt, and ved are not a "little more than alpha"

yes, the os is being developed in V, and it can already run bash, GCC, G++, and Doom.

https://github.com/vlang/vinix

the person working on it, is an osdev, and not a compiler developer

And there are also people who have built even harder projects than V, but can still criticize projects with issues and rant with the best of them!

The absolute dichotomy being "doers" and "criticizers" is false. Linus could criticize things just fine.

It's hard to find a language farther away from V than PHP.

I think we were all more susceptible to hype when we were 15

This website boils my blood every time it comes up - like look at their considered harmful list, it is seriously ridiculous.

I did not know that C++ is new in 2007 ...

It's a very biased and old list of articles from an author who openly claimed that "V should die".

For example, the performance of V is measured on a debug build, without vlib cached, without vfmt disabled, with a 10x slower backend.

Here's V compiling itself in 0.3 seconds:

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

Also complaining about not running on all Linux flavors on day 1. Right now V runs on literally everything.

And so on.

That's why I asked to list the specific claims the poster had in mind here in the comments.

Now it's "tell people you're thinking of building it and they will come"

[see Kickstarter et al.]

I think/hope that it is still like that, just that haters are a subset of people, whose opinions are currently disproportionately magnified.

Good find, a pretty specific issue resulting in an unhandled error. That's why the language is not 1.0 yet :) Such cases are quickly picked up and fixed by the team. This one is already being worked on and will be fixed this week.

300+ contributors.

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

This is correct.

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

Which one would you recommend?

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

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

Maybe the author just likes to implement programming languages and sets high goals. All those who have experience with this know that it is a lot of work. Apparently, the author has been working on this for many years and has achieved a lot. I recently bought the Packt book; what is not clear to me at the moment is what are the specific innovations over the other already established languages. Thus, it would be helpful if on the main page of the language there was an essay on why the author thinks there is a need for a new language, and what the specific advantages are with respect to concrete features of the other languages.

Can you elaborate? There was never a claim it doesn't use memory (although it does use a lot less memory than most compilers). The language is indeed fast, V compiles itself in 0.3 seconds:

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

Early PHP lack of any design is the same of V.

That's what is most crazy to me. Even the creator of Nim (Araq) flamed this guy in the Nim forums but most of his criticism seemed to be superficial and opinion based. I don't know what to think. I'm not a language expert by any means. I just hope this guy succeeds, the goals are tremendous.

Thanks for your support :)

All big projects have open GitHub issues. You just linked to 500 open and 3000 closed bugs in V.

For example, Rust has 8000 open/35000 closed. Yet it's a very mature language.

V is very stable for its age. The compiler can build itself since the release (it now has 220k lines of V!) and we have big projects like the Vinix OS written entirely in V, and it can already run GCC/g++ and Doom for example.

It's definitely not anyone's fault for not taking this seriously.

I thought it was a gag and only these comments make me think it might possibly be a real language.

Nice to see there are some small projects (program) that have been running for 2 years (backend services) written on very early V. Quite interesting insomuch that when you get something compiled that does what you want, it works very well.

I created V because Go didn't work nicely with C for my project.

So just that would be enough for me to use V.

Variable shadowing makes code more bug prone and confusing.

As for the size: V uses system's official API (libc), including networking. Go has their own libs that have to be statically linked in to the binary.

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

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

Autofree works:

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

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

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

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

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

As I can't respond to amedvednikov's comment below, let me respond to it through yours (sorry):

> No things are closed source. Never have been.

That's not correct. I seem to remember that when V was released initially, the compiler was available for download in binary form only. The source code was only released later on.

No things are closed source. Never have been.

What things are broken for you?

What claims are not true?

no, we don't "merely use Boehm GC"

That's strange. All examples are compiled via CI on all systems.

The same argument can be levied at any project that goes for a "don't use full LLVM for debug builds where iteration time and hence compile time speed is paramount". That includes projects like cranelift for Rust. I don't think it's reasonable to say this is a wholesale illegitimate/cheating approach.

It has tradeoffs, for the project developer such as the burden of maintaining two significantly different paths for codegen, and for the project user such as the need to trust that these different codegens are largely functionally equivalent (exposing and fixing a bug in debug means it would have been but now will not be present in release). But the tcc approach is arguably one of the better ways to minimize the negatives in this tradeoff, compared to cranelift, etc., as tcc is a small but popular enough project in general usage, meaning it has some battle-testing.

And I think the point about projects that "work fine" was quite reasonable, just showing there has been a non-trivial amount of battle-testing. There is now some basis to claim that the project is not full of trivial bugs, to the point of making it useless. Nowhere was it claimed this was a proof of the absence of all bugs -- that you included the Dijkstra quotation in this context is honestly quite humorous.

My understanding is that there has been some drama in the V community in the past, especially around the feature set and release timeline and promises from its author, but I don't see the justification for all this pompous negativity when it is finally out in the wild, warts and all, but showing some nice capabilities at the same time. I don't plan to use it for any hobby projects myself right now, but if I wasn't in the middle of using a different up-and-coming language with some of the same goals, I might.

V is also written to be as simple as possible :)

Compilation time is very important during development for the quick dev cycle (change, build, test).

You don't need to do -O2 builds dozens of times per day.

-prod (-O2) builds are definitely an order of magnitude slower, that's a fact.

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

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

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

    https://volt-app.com/

Did you consider writing an interpreter for the quick dev cycle mode instead? Compilation times are down to 0 seconds (if we ignore the parsing time). As LuaJIT's Mike Pall has shown, a well-thought out interpreter can be as fast as a naive compiler. It's also more portable, and experiments are easier to introduce. The main page at vlang.io focuses on compilation speed, not runtime speed. You also admit that the fast compilation mode uses simpler backends without optimizations. So why not just interpret it, if compilation speed and quick dev cycles is number one priority? That's what interpreted languages already excel at.

That is absurd. He's not saying "I have an idea, and with a bit of help we might reach extraordinary numbers", he claims "better faster leaner than everybody else".

I don't have time to help every single open source project that makes bold claims. I also don't demand anything, I just moved V to my ignored list. It may be unfair, and I may take a look in a few years again if there are enough solid news about V floating around.

So, you're saying C2V is closed source then? Which is exactly what Alex said isn't true.

We could, but it's not yet public. Rest assured, it exists and there is work going forward on it to get it out the door somewhat soon.

You may find the public `go2v` work interesting. It's being worked on by some other folks in the community: https://github.com/vlang/go2v

No, "it's fast because it's C" doesn't hold. You can write slow code in any language.

But you said it's unfinished and hidden behind a flag. And it's been like that for several years.

I found this in the docs:

>Autofree is still WIP. Until it stabilises and becomes the default, please compile your long running processes with -gc boehm, which will use the Boehm-Demers-Weiser conservative garbage collector

At this point, I'm sure you can find a justification for any kind of criticism anyone brings up, so I will stop bringing it up. Sorry for being a bother, and good luck with your Go clone.

It's trivial to have fast compilation speed if all you do is transpile to C (naively, i.e. without any program analysis) and use TCC to compile the C (again, naively, that's why it's so fast). Such "languages" are often written as CS homework assignments.

But even with the transpilation step, the V transpiler is still unable to output correct code on trivial examples, demonstrated in other comments. The fact that you have thousands of tests (Alex's words) and the trivial examples still fail, makes me completely sure that something about the whole approach is fundamentally wrong; which lead me to the "testing whether your regex parses html properly" comment. Tests are useless if the thing you're testing does not prove anything.

The fact that the author is pushing this unfinished mess as a completed achievement (instead of work in progress), without ever mentioning any downsides (except when presented with undeniable proof, at which point he makes up another justification for the issue), only shows the author's inexperience and disconnection from the community. V compiler is a toy project wrapped up in a pretty box to look like something serious. And when faced with criticism, Alex seems to turn to his three different accounts to argue with the commenters, instead of reading the damn Dragon Book and fixing his damn compiler.

To me, personally, V language is the perfect example of an overhyped griftwork.

Besides the obvious trolling, much of this is your interpretation and what you want the developers of Vlang to say instead. Let's keep in mind that others can have different interpretations, opinions, or things they like to nitpick about too. The developers of Vlang aren't obligated to you or me in any way, so are entitled to type their perspectives on their website.

The real deal are the many users, supporters, and contributors of Vlang. Where on GitHub (which is easy to check), it has more than many other newer languages (in various cases, more support than a couple of newer languages combined). Those people are the ones that count, who are using and improving the language daily.

"You can't put the genie back in the bottle", Vlang is firmly on the road to success and more popularity, despite its detractors and angry competitors.

> How is it related to spec'ing the language

You wrote a bit further up: "The problem is that in the initial releases the "high goals" were listed as "features" of the language". The "features" you mention are obviously the specification. Have e.g. a look at how long they specified Algol 68 and when finally a compiler appeared; CPL is yet another good example; actually at that time Wirth was one of the few who delivered a compiler simultaneously with the language specification.

All of those issues are related to autofree. From vlang.io:

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

I'm assuming because it's not considered good enough quality yet. It would be better to be explicit about that, but it's not unreasonable as-is.

I think it's only reasonable to mostly ignore autofree issues when assessing whether the language has trivial issues. Count all those issues as a single "autofree is alpha quality" conceptual issue. Counting each individual autofree issue in order to convey the sense that there is a critical mass of issues in the project in general is quite harsh, I think.

There are no trivial examples unable to output correct code in that comment.

Your attempts to discredit the language are just sad.