For starters, you are a known troll account. Your very account name, vlang1dot0, was made to harass and troll. That is all that you do on HN.
I was referring to the GitHub releases, which very clearly state they are releases. Each of these Vlang GitHub weekly releases has a compare tag to show what has changed from previous releases.
This is a comparison of changes made between the latest release and the one of 4 weeks ago:
https://github.com/vlang/v/compare/weekly.2022.35...weekly.2....
That's 150 commits and 722 files changed. The releases are clearly different, with numerous changes. That's 1 month of changes, if we looked at 3 months, 6 months... We would see even more massive amounts of progression.
Now, back to the FUD you are pushing with your known troll account. The game you are trying to play is to obfuscate the clear as day lie that V is vaporware. Nobody is falling for it. And the more you keep engaging in trolling the V language, the more obvious it becomes to everyone else what you are doing and what your agenda is all about.
They've been working on C2V for a long time now and even still it falls over quickly for anything other than the exact version of doom they are using. Multiline comments crash the tool for instance.
I don't know what the story behind your account is, but it looks like you've been posting mostly in threads on this one topic for a couple years now. That's not cool on HN, regardless of how good or bad you feel a programming language is.
(I noticed that you've also posted a few comments about other languages, like Rust and C++, but they're a minority of your posts, and unfortunately quite a few have been flamewar comments too - which is not what this site is for.)
HN is for intellectually curious, respectful conversation on topics that interest you. Since agenda-driven or single-purpose accounts aren't compatible with that, we don't allow them here. We also don't allow trollish usernames (see https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...), which given the account history, this looks like.
I've banned the account for that reason, but if you want to pick a different username, we'd be happy to rename it and unban it. hn@ycombinator.com is the best place to let us know what username you'd prefer.
Yes! Thank you! I have noticed this account constantly trolling V posts as well, amongst a few other user accounts. I feel it's fine to express concerns in one or two posts, but to repeat them for years is wrong and bullying. Is there a way to submit these accounts or report them?
No he didn't understand at all. Both the OP and I'm saying that while `make` claims that tcc was not used, the compiler does seem to use tcc even in that case. I have demonstrated that this is a plausible explanation by moving the tcc binary and showing the stark performance difference.
(This is my final response on this matter. I have already given enough information and an inability to interpret it is not my business.)
I've just tested it, and turns out all C compilers are terrible at hundreds of thousands of print calls (for me Clang was stuck for minutes with 100% cpu usage).
The claim was made about actual code, like the V compiler itself, which is about 220k loc and compiles in 0.3 seconds, not some unrealistic test with a million of prints.
I'll make it clear on the home page with a link to the benchmark.
The check to fix the issue is indeed 8 lines long, and not one, the bulk of the patch is updating the places where the compiler was relying on this behaving with unsafe blocks and the rest is adding tests.
The patch adds two consecutives if statements to forbid the behaviour and could surely be written as a 2 lines or one line patch.
Not checked the timeline. It it is a bit irrelevant, I am not here to score point for either author.
I have a test project of around 5k lines of V, taken from a prototype in Go. Using V has been much more pleasant than Go or Zig, but I like zig comptime features. V is a nice language syntactically. Go has better tooling and is mature. I also rewrote the same code in Zig which I would trust today for production. Finally, I really like zig (and Jai) build system, and Jai very logical design and meta-programming features (no, I am not in the beta).
Hopefully from that statement, everyone can see that I am rooting for the adversarial team and therefore you can all discard my commment as biased
While I would agree with many of the comments regarding how the V site is not clear enough on the level of maturity for each of the attempted goal, and very quick to celebrate work in progress, I feel that balanced comments on this thread are mixed with some which would probably trigger me should I have invested lots of energy in trying to make V successful.
Thanksfully I only contributed one AST optimisation as curious bystander, so I can read this thread as most will do: noting how people are capable of listening without hearing.
All this discussion did was to radicalise even more both parties. I would hope V developers will take the time to review what was posted in this thread, when the minds have cooled down, and will try to understand the cultural differences which can exist between people when it comes to reviewing public claims made.
I attempted once to bring this exact topic in the discord channel but reading the room there was zero appetite for change, so I stopped as I felt I would be alienating people if I continued. I self censored to not damage my standing on discord ~ so why am I ruining it with this post: to say that asking people to meet you on your ground to discuss problems is not going to work (general statement)
People with nuanced opinion will often shut up when the discussion hits up.
When points are not understood, the tension rises and the quality of argumentation reduces very quickly.
My view, and feel free to disagree, is that the V community has been burned out and does not welcome criticism anymore, trust in other developers is broken, from here no constructive discussion can happen anymore and for some participants of this thread the same can be said the other way round.
Yes, technically you can do that but it makes no sense from a design point of view to have a language that cares so much about safety it adds a borrowing system but then says "fuck it" to type safety.
You have to have type safety to have memory safety and that was the whole point of Rust.
If the US gov decides to project its will on your software project, an ISO standard is not going to help you at all. They will sabotage the ISO process, or force your hosting provider (GitHub) to remove your project or apply changes to it, or just kidnap your maintainers and beat them with wrenches until they comply[0].
If your threat model legitimately considers the US gov to be a hostile actor, you need far more than a piece of paper that claims what the behavior of your compiler is.
strong disagree, C is a very poor language that does not provide a proper stdlib to reuse, collections/containers/functors. No OOP means no efficient code reuse, zero syntax sugars, manual memory noise, etc etc
C toy programs can be short though.
Disagree all you like. The rust port apparently didn't hear you, because the line count grew by nearly 50%, and I can post other similar comparisons with some other codebases and languages too.
I see about 1k lines of new tests, probably 500-600 lines of build system integration across various files, nearly 1k lines of cargo lock file information for dev dependencies and the Rust code appears to be more highly commented than the C code was.
Sounds to me like you already decided what your conclusion was and are just looking for data to back it up without actually analyzing it.
But this Rust port isn't idiomatic Rust, so it doesn't take much advantage of the improved idiom. Its authors call that out early.
Example: In C you're obliged to write a lot of counter loops, because the language does not have iterators, the idiomatic Rust is both smaller and easier to read because the counters weren't really for anything, they're just implementation details:
for (k=0; k< size(geese); ++k) // We need this k counter in C to index geese
for goose in geese // In Rust we can just have the geese themselves
But if you do a non idiomatic port, you carry across that loop as it was written, plus you gain the extra conversion noise. So this is a much less useful metric.
Fair, it was the first example of a verbose C idiom that came to mind, and it will spill onto multiple lines for complex cases easily (depending on your style rules) but it isn't a good example for this purpose.
I did also think about switch versus match, but in that case you're more or less obliged to do the extra lifting when translating to Rust and so I expect the breaks (which are extraneous in match) would be elided rather than translated.
It's one thing to like V but it's another to constantly repeat misleading information in an attempt to give it more credence than it has.
Even V's own changelog only contains 28 releases (mostly from the 0.1 era in 2019 - early 2020) not "hundreds" like you've claimed.
https://github.com/vlang/v/blob/master/CHANGELOG.md