Hello V-Lang
blog.hackersreboot.techHere are the summarized V features for anyone who dislikes salestalk:
- small binaries and fast compilation
- cross-platform support
- cross-compilation
- cross-platform drawing library (GDI+/Cocoa Drawing, OpenGL)
- native GUI toolkits (V-UI)
- value types
- auto-free engine that adds necessary free() commands
- C transpilation (both ways, allegedly emits human-readable C)
- C foreign function interface ("V can call C Code and any language with C-interop can call V Code")
- hot-code reloading (not mentioned how, but probably dynamic library hot swapping)
- package manager
- autoformatter
- profiler
- documentation-from-source generator
- V-to-JavaScript/WASM transpilation
- built-in testing framework
- built-in web framework (vweb)
- ORM ("you can just write V instead of SQL while interacting with databases")
Vinix - An open-source Operating System that can already run GCC, Bash, V etc.
Volt - A 300Kb native desktop client for Slack, Discord, Skype, Gmail, Twitter, Facebook, and more. (only supports MacOS at the moment)
VSQL - A single-file SQL database written in pure V with no dependencies.
Gitly - Open-source light and fast alternative to GitHub/GitLab, written entirely in V.
Vorum - Right now it's a very basic forum/blogging software, but in the future, it will be a full-featured light alternative to Discourse. The V forum runs on Vorum.
Vgram - A bot library for Telegram Bot API.i'm pretty sure that half of these features don't work.
Such as the famous "autofree" where everyone doubted it could work and the solution now was.... to drop in boehm-gc.
for anyone unfamiliar with v, take everything on that list with a giant spoon full of salt.
The solution V seems to apply here is a bit more nuanced than that. They’re going in roughly the similar direction as Nim did with the new ORC, which is essentially keeping the GC but try to do some compiler analysis to insert free() calls at compile time as much as it can using scope-based memory management and move semantics. The confusing thing about V is that these design decisions aren’t written properly on the docs, so the author’s claims might feel like “selling snake oil” although it’s already implemented in another language with great success. It would have been much better if the creator of V had acknowledged any previous work done on the topic. Also, the choice of Boehm GC is a little bit disappointing, but understandable since it’s basically the easiest garbage collector you can stick it into a language (without designing your own GC). Maybe this will change later on.
Though I’m still not confident enough on the usability and stability of the language. Almost all claims of the usability/stability of the language seems to come from the main creator himself, I would like to hear some takes from people other than him who have used the language in any serious form.
> keeping the GC but try to do some compiler analysis to insert free() calls at compile time as much as it can
This is correct.
> Also, the choice of Boehm GC is a little bit disappointing
Which one would you recommend?
> Almost all claims of the usability/stability of the language seems to come from the main creator himself
The creators of Vinix and vsql don't have any issues with the usability/stability.
>> Also, the choice of Boehm GC is a little bit disappointing >Which one would you recommend?
boehm is conservative. this is a costly and very unnecessary implementation for a language which already has a compiler and knows explicitly which values are pointers.
Thanks, will investigate.
We'll have our own GC in the future anyway.
> i'm pretty sure that half of these features don't work.
That's just bashing. It's one thing to actually use something and criticize, its another to not even use the language and assume things.
> Such as the famous "autofree" where everyone doubted it could work and the solution now was.... to drop in boehm-gc.
Autofree is still part of Vlang. Also, many other languages have multiple methods of memory management. Which many argue is a good thing. Take for example, Nim, which has several (see below). Yet, I have never seen anybody at HN lose their minds over it and bash Nim about it.
Nim has: gc:refc, gc:markAndSweep, gc:boehm, gc:go, gc:arc, etc...
So exactly why can't Vlang have both AutoFree and GC? Yeah, the correct answer is that it should not be a problem. And as a newer developing language, they should be allowed to experiment to find what works best, as the other languages before it.
I assumed that there was a English language barrier from the original author that made the mistake of present versus future tense for the feature list. When combined with a lack of feature tracking that looked to people like big claims were made without substance, but to me it always felt like everything in V was "work in progress."
They definitely have a hacker mindset to get the minimum working examples through and keep on developing, which is admirable in some ways. The downside is I don't think there's a lot of development experience hanging around that project, so things stick to minimal implementations.
I've never been able to quite understand what was going on with V (and the associated messenger client Volt written in it), but it seems to be something a bit more complicated than just a language barrier. I made a habit of checking the Volt website for a while out of interest in using the project, and it was somewhat surreal how fast the documented timeline would change. There was a super specific timeline in terms of what month features would land out as far as 2-3 years (e.g. "support for $os in $current_year + 2, open source in $current_year + 3), and but then as the months went by, the items on the timeline would not land, and the timeline would get revised pushing things out with no announcement of any sort. The platforms that were supported seemed to be constantly changing; one month there would be a Windows binary with Mac and Linux listed as "coming soon", and then the next month, there would be a Mac one but the Windows one was gone with no explanation. Charitably, I think the developer had fairly unrealistic expectations for how future work would progress and probably a lack of focus on following the plan they had publicly stated. I don't _think_ there was any malicious intent, but ultimately I felt like I wouldn't be able to trust that the products would be reliable if/when they did end up releasing and lost interest in following the timeline.
> There was a super specific timeline in terms of what month features would land out as far as 2-3 years (e.g. "support for $os in $current_year + 2, open source in $current_year + 3), and but then as the months went by, the items on the timeline would not land, and the timeline would get revised pushing things out with no announcement of any sort.
That just strikes me as youth and inexperience
This has very much been the case for me when trying out V. It advertises some great features that just barely works in the right circumstances.
Can you give an example of features that barely work for you?
autofree demo:
V's compile time memory management demo. Running the Ved editor on an 8 MB file with 0 leaks.
Yes, we know, this is always your reply. We also know that boehm-gc is just temporary until you fixed the issues with autofree. Do let me know when that happens.
Well you said it doesn't work, which is not true. You also claimed this about half of the features on the list, which is also not true.
Regarding autofree/gc, here's a good summary from another comment here:
There isn't any reason why Vlang can't have both autofree and boehm-gc. I don't understand the "must be this or that only" logic being applied to it. Other popular programming languages also have multiple memory management options, and so can Vlang.
I am still wondering why Volt, the native desktop client for Slack/Discord et al only supports MacOS when V boasts about cross-platform support and cross-compilation.
The reason V is so controversial is that it separates nearly everyone who looks at it into two diametrically opposed groups: those who have some experience or knowledge of programming language design and implementation and those who do not. The first group are generally the "detractors" and view every concession made to the impossible set of features as a reinforcement of their belief that the language cannot work as advertised. The second group sees every concession as a step closer to the eventual goals, sure that it's simply a matter of time and one more bug fix until the promised result is achieved.
Because of this dichotomy, there cannot be completely objective discussion about the language. I would strongly urge anyone thinking of spending time on V to first examine it closely and see if it holds up to detailed scrutiny. In my opinion, V does not and the author knows this but deliberately pretends otherwise for his own personal gain. Of course, you should not solely take my word for this any more than you should take Alex's to the contrary. Consider, if it really was so easy to build a language with the speed of C, the ease of use of Python and the simplicity of Go, why haven't those languages with orders of magnitude more funding simply done so? There are fundamental tradeoffs to language design and it's clear the author does not understand this.
The core problem with V is that while many language implementations tread a middle ground between the "just get an MVP out so users can give feedback; ship fast, ship often; as long as it works" engineering mindset and the "ivory tower" academic mindset, V picks the former while giving the finger to a burning pile of compiler books. The author appears willfully ignorant of the basic tecnhiques used to build compilers even going so far as to state that V won't use an abstract syntax tree because "AST is going to require lots of extra CPU power and RAM" [1]. The author later discovered that implementing an AST was actually necessary to make developing the compiler easier and made the compiler faster not slower as he originally proclaimed [2].
A few notes on the advertised feature list:
- cross-compilation
Cross compilation in V depends on having a C compiler toolchain present for the given target. That is to say, V's cross-compilation story is exactly the same at present as C's is. I'm sure some one will mention the "native backend" which has recently started to be able to build "hello world" without miscompilations. Until such time as it is able to build even slightly complex programs, this is a complete non-sequitur.
- native GUI toolkits
Native in this context means "compiled code", not that it uses the platform's native UI toolkit. V-UI draws it's own components to the screen and does not use native platform libraries at all other than to open a drawing surface.
- auto-free engine that adds necessary free() commands
Autofree does not work anywhere close to as well as advertised. Autofree will both leak memory in trivial programs [3] [4] [5] [6] as well as introduce use-after-free and double-free Undefined Behaviors [7] [8] [9] [10]. The autofree Ved demo required changes to Ved to work around autofree's broken state [11].
Autofree cannot work as well as advertised (90%+ of variables handled automatically, down from 100% orignally) without extensive inter-procedural analysis which doesn't exist [12] and would destroy V's compiler performance claims if it did. For anyone who still thinks there might be something to autofree, please explain how this logic for inserting a call to free could possibly be sound [13]:
- profilermut af := g.is_autofree && !g.is_builtin_mod && node.op == .assign && node.left_types.len == 1 && (node.left[0] is ast.Ident || node.left[0] is ast.SelectorExpr)The profiler works by adding instrumentation calls to every function generated in your binary [14]. This can completely change the performance of your program and invalidates the results produced. No mention of this problem exists anywhere in the documentation.
In conclusion, people need to stop treating this as some kind of serious up-and-coming language and instead see it as the massive pile of poorly implemented hacks it is.
[1]: https://github.com/vlang/v/issues/1255#issuecomment-51356505...
[2]: https://github.com/vlang/v/issues/4128
[3]: https://github.com/vlang/v/issues/14033
[4]: https://github.com/vlang/v/issues/13821
[5]: https://github.com/vlang/v/issues/13539
[6]: https://github.com/vlang/v/issues/12201
[7]: https://github.com/vlang/v/issues/13554
[8]: https://github.com/vlang/v/issues/13398
[9]: https://github.com/vlang/v/issues/12455
[10]: https://github.com/vlang/v/issues/12453
[11]: https://github.com/vlang/ved/commits?author=medvednikov&befo...
[12]: https://github.com/vlang/v/search?q=is_autofree
[13]: https://github.com/vlang/v/blob/704e3c6e7275336b5b4f8da27438...
[14]: https://github.com/vlang/v/blob/3fa9128716cdc8a794b2ec0be4fb...
Thanks for taking time and explaining things around v's state of affairs.
Also I'd like to add that V's first feature, "no null" is a myth. V supports initializing a reference with 0, which is null/nil or whatever you call it.
I'm pretty sure v's author will not bother responding to a well laid out facts.
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.
First, nobody should take what you have posted as an honest assessment, because your username is for the explicit purpose of trolling. Running around with the name "vlang1dot0", demonstrates a commitment to being a hardcore troll and spreading misinformation.
As with any attempt at propaganda and misinformation, you are taking elements of truth and then greatly distorting it to fit your agenda. Which is possibly to hurt your competition, because of developing or being heavily invested in a competing language. It would be much more honest to come out and say what your preferred language is and what your involvement with it is, than to put on a troll costume and do hit posts.
> ...Because of this dichotomy, there cannot be completely objective discussion about the language.
No, you have created a false dichotomy. You can not be objective, because of your bias and possible investment in other languages.
> Consider, if it really was so easy to build a language with the speed of C, the ease of use of Python and the simplicity of Go, why haven't those languages with orders of magnitude more funding simply done so?
This is a straw man argument. It would be like someone saying, "If the car was really such a good idea, why wasn't it invented by the Egyptians back in 1000 BC? They had plenty of gold and engineers."
Programming languages are built upon and borrow from each other. It is the prior existence of C, Python, and Go that something new which is blended from various elements of each, with various new concepts added, can be created. Thus we can have Vlang and various other newer languages.
-Cross compilation
You didn't refute that Vlang can do it, but rather it doesn't meet your preferences. So damn what it makes use of C compilers, for now or as an option in the future? So have other languages. Not to mention, Vlang has very strong interop with C, to begin with.
And they are working on the native backend, which is producing results, and will only get better. It must also be kept in mind how young Vlang is as a language, which started from 2019. So its level of progress and popularity is arguably amazing, and has surpassed a number of its rivals. It is asinine to compare a language of such young age to those from say 2008 or the 1990s, who at the same comparative stages were less advanced.
- native GUI toolkits
Again, you are spouting out your preferences. Furthermore, Vlang has a number of GUI wrapper libraries. Such as: vsdl/vsdl2, vig (ImGui), vnk (nuklear), viup (IUP), etc... If a person doesn't want to use the VUI (written in V), they can hop over to a bunch of others.
- Autofree
The developers have repeatedly said that it wouldn't be ready until 0.3 of the language. It exists and functions, but they are working on improving it, which is not anything unusual at this stage. People can disable it with -noautofree, and do manual memory management. There is -prealloc too. There is also GC (-gc boehm).
The developers have stated there would be a few memory management options, of which there will be at least -autofree and -gc boehm. Not sure why certain people are getting their panties all twisted, when a number of other programming languages also have multiple memory management options, to include those languages having had all kinds of development problems and they still have issues.
- GitHub Issues
This is probably the more ludicrous part of your post. All popular programming languages on GitHub will have a long list of issues. The more popular, the more you will see. For example, Rust has nearly 8,000 OPEN issues. If someone listed them all on HN, would they win any points?
The true point is that issues submitted, are those that contributors and developers work on to resolve. Using an open issue as a reference to attempt to prove a language is somehow deficient is very, very deceptive. That's a problem they are fixing and will usually fix (sooner or later), or discover it's not really an issue as user error. More importantly, is how useful those users, supporters, and contributors feel the language is. That's why Vlang is constantly gaining in popularity, despite angry detractors and competitors.
Troll hit jobs will simply not stop Vlang, and just reflects an odd desperation in wishing it would. Whatever programming language that you prefer or are developing, it should be able to stand on its own merits, without the need for trolling others.
What a piss-poor excuse for an article! Reads like a press release; all puff and no down sides.
Anyone with any familiarity with the V project will know it's been mired in controversy from day 1, thanks to the [often hyperbolic] claims of its inventor. All of which seems to have passed the author of this article by, as he just gushingly repeats them unquestioningly.
Mind you, he does describe V as "all new", so maybe he missed all that previous discussion.
The article seems to have been written by:
> a 15 year old student who likes to code and blog
for some perspective :)
It is a new generation: sales, hype and marketing first.
We all could learn from this.
I think we were all more susceptible to hype when we were 15
Maybe, but I can tell you when I was 15 I didn't have instant worldwide reach and the on-the-Internet-nobody-knows-you're-a-dog effect at my disposal, and neither did my readers.
I grew up with if you build people will come.
I don’t think it is like that anymore …
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.
HN is usually an incredibly welcoming and encouraging community. Any criticisms are honest, sometimes harsh and maybe on the overly sceptical side, but mostly decent and civilised ... Unless Vlang comes up.
> What a piss-poor excuse for an article!
The article is no different from many new-sexy-js-framework blog posts I see here, but these never get that amount of hate. Why is that?
Good point. It's odd how certain people get so fired up to bash and troll Vlang, then also state they never use it or refer to some controversy from 3 years ago that has lost its relevancy.
Additionally, somehow other newer languages like Odin, Crystal, and Zig seem to escape their wraith and trolling despite having some similar developmental issues. Very selective "hate".
>Unless Vlang comes up
Yes that is why I am surprised it is still on the front page. Normally anything to do with Vlang get flagged within a few hours on HN.
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?
Well, Zig hasn't been numerous. If you do a search on Rust and Zig you will see Rust submission is something like 10-20:1 ratio with headline going at 3-5:1 within one month period. But yes zig is getting some traction on HN. (I have been tracking it ever since Rust people complain about the number of Zig submissions. )
And HN has a hatred for Vlang because arguably it start off in the wrong foot with too many over promising features. I thought we should give Vlang some benefits of doubt. Instead HN simply shoot down all Vlang submission. And it only takes a few people flagging it for it to disappeared from the front page. Yes I dont think it is fair. I wish we can all submit some obscure, unknown programming language to the front page. Unfortunately I am not sure what the solution to that would be, may be email @dang about it?
Yeah some jealous "communities" poisoned the water. It's really sad.
Because nobody wants to deal with another PHP in the unlikely case V takes off.
It's hard to find a language farther away from V than PHP.
I dunno, the design philosophy seems ripped out of their (former, to their credit!) playbook.
Lol. You're not speaking the same English bub.
V's design is completely opposite.
Early PHP lack of any design is the same of V.
Can you explain what you mean by "lack of design in V"?
You'd probably enjoy this one better from a major magazine then: https://linuxformat.com/ - see page 94 in the May 2022 volume. Screenshot of ToC: https://cdn.discordapp.com/attachments/592106336838352923/96...
Can you list the hyperbolic claims here please?
Well, for a start there's the "Translating DOOM from C to V and building it in 0.7 seconds" which is still on your front page. In spite of being a 'WIP' for as long as I can remember.
Then there's; vweb, vorum, volt and ved [all of which feature prominently on the front page too] which have been little more than alpha quality proofs of concept for a similarly long time.
Don't get me wrong; I was actually interested in V when I first heard about it a few years back. And I was prepared for there to be a lot of 'WIP' since the language was so new. But I lost interest as the years passed and nothing more polished ever seemed to emerge.
In fact the whole ethos of the V community seems to be to take the maxim "Move fast and break stuff" and stretch it to breaking point. Instead of anything actually being worked on, polished and finished, you just keep throwing out new headline grabbing 'projects' which, as per the examples above are barely functional and seem to be abandoned almost as soon as they are announced. One week it'll be a new game engine [naturally, because it's V, better, stronger faster than anything already out there], the next week a web framework [better, stronger, faster...etc], the week after that it'll be a new 3D engine [better, stronger, faster...]
I even remember a while back someone[s] in the V community announced they were building an OS in V. [presumably better, stronger, faster than Linux, OSX, Windows, etc]
That's why you get so much negative press. It's not because people want to hate V. A hell of a lot of people [especially in the HN demographic] were genuinely interested in the project. But the endless hyperbole just ends up making you sound like a snake oil salesman and your crowd loses interest and drifts away.
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
OK. In the interests of fairness, I'll take another look at V. Because I did like the look of it when I dabbled a few years back. I found it a bit like Go but without the annoying boiler-plate `if err != nil...` everywhere, it did seem to compile and run quickly and I did remark at the time that it had some of the most helpful error messages I'd found in any programming language.
I'm not a professional coder though. I only knock together hacky stuff for my own purposes. So I have to bow to the superior collective opinion on HN when it comes to the more esoteric qualities of any language, such as its memory handling, efficiency, etc.
So I am a long way from being the 'Hater' half the comments seem to suggest. Although the younger generation are hypersensitive these days that just disagreeing with someone else's opinion is enough to have you accused of 'hate crime'.
PS: I've also been dabbling with Crystal, which has for me the nicest syntax out of the Go / V / Crystal triumvirate that I keep drifting between, in my quest for the "One True Language to Rule Them All" that I can learn relatively easily and use for my personal hacking needs. Unfortunately Crystal suffers from a lack of tooling and some of the most unhelpful error messaging I've come across.
So there you go. That was some love for V.... or was it a 'hate crime' against Crystal? It's so hard to not cause offence, these days.
> So I have to bow to the superior collective opinion on HN
You shouldn't do that. There's a lot of misinformation regarding V on this site.
Always best to try things yourself, with V it's very fast and simple.
Here's an article from around the time, "V is for Vaporware": https://christine.website/blog/v-vaporware-2019-06-23 (and discussion of that on HN: https://news.ycombinator.com/item?id=20258485)
I imagine things have improved since 2019, though.
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.
> an author who openly claimed that "V should die".
Citation needed. Or is the source for that claim the same as that for V benchmarks?
https://news.ycombinator.com/item?id=27442724
> I think it is something that should be ignored until it dies into obscurity
> thanks to the [often hyperbolic] claims of its inventor
To be fair.. I always see this in HN comments about V, and at this point it sounds just as a non-objective and prejudiced evaluation as the article is.
I agree that the article should have presented some downsides. But to start a discussion, how about presenting some valid criticisms?
Clearly people have worked on this project for a while. Have they completely failed to implement the “hyperbolic” claims? Or are they doing something good?
I’ve been intrigued about V for a while, i haven’t had the time to look into it yet.
I wish we had an objective discussion about it..
Quite a bit of work has indeed gone into the language, and what has been accomplished is no mean feat, but the myriad open bugs [1] around core features of the compiler do not inspire confidence.
It'd be better if the documentation reflected that the language was in an alpha state rather than touting stability guarantees etc.
[1] https://github.com/vlang/v/issues?q=is%3Aissue+is%3Aopen+lab...
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.
Ok, I'll try it out once more. Last I tried it a simple program I wrote using the ui toolkit was crashing for some issue I couldn't quite figure out. Maybe things have substantially improved since.
I had the same experience. Tried out V a couple of weeks ago because I needed a really simple GUI application. Compiling example code resulted in errors I couldn't understand nor google. I enjoyed playing around with V until that point, but went back to Go and built my stuff with some giant UI library into a 10mb binary that at least worked how it should. I like V though so I will try it out again sometime
That's strange. All examples are compiled via CI on all systems.
Maybe that was an error on my end then, early in the morning lying in bed stuff. And iirc the UI library did say it was in an early stage or something like that.
(I think you are the author, or at least involved in the language? I don't want to come off as simply bashing your language. Most people here seem to do enough of that... Definitely didn't try it out enough to have any opinion on the advanced features mentioned. I enjoyed the Go-like syntax with different ideas though. So definitely keep going)
Yes, I'm the author, and indeed the UI is at a very early stage.
We'll make it stable this year.
Best recourse is usually pop into Discord chan into #v-ui-chat or #help and ask about your issue, unless it's a clear bug and then filing an issue first and then referencing it in Discord might be best.
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.
Definitely real and definitely awesome. Give it a try - it's very quick to compile from source (git clone; make - all in roughly under a few seconds).
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.
There's people that have what it takes to build something like V, and then there's the rest of us, that spend our time ranting online.
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.
Doers can of course criticize, but serious devs won't bash a new and unfinished language, just because the author of the project had the audacity to promise something "so unrealistic".
Healthy people saw V, maybe read about it, saw the great promises, and thought "Ha, that sounds unlikely, but it's not a bad idea, it would be insane if this worked! Shoot for the stars, aim for the moon.".
For others, the promises were outrageous and anything remotely close to them "impossible". I don't get why it got personal for some of us, and it's stupid how involved people were over the years (hey Xe, you're so skilled, why waste your energy) into bashing this random project.
Have seen Linus giving the finger to Nvidia, but not ranting on a forum about a new language.
Here you go: http://harmful.cat-v.org/software/c++/linus
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 ...
I have seen Joe Armstrong, Alan Kay, Paul Graham, and many others ranting about other languages in many ocassions...
Lol this right here. This is it. "all skepticism is equally valid". A crock of nonsense. One side has pointed out, repeatedly, how that statement is true. If you don't know better, that's on you. This whole "aww my subjectivity" completely ignores the wisdom of the crowd of "no, really, this is snake oil, can we fucking not".
But as usual, people are looking to have an opinion spoonfed and are upset when it's not the narrative they wanted.
Delivering. Fantastic community and contributions. Love them.
If you'd like to check out more about V, here's the GitHub repo:
Very thorough documentation: https://github.com/vlang/v/blob/master/doc/docs.md
One of the coolest latest projects is the Vinix OS, written fully in V:
https://github.com/vlang/vinix
It's a POSIX OS that already runs libc, bash, GCC, g++, and Doom.
For anyone not aware, this is the creator of V.
It would be nice if you were upfront about this in your posts or profile, especially when you jump in to dismiss people's complaints about your project. https://news.ycombinator.com/item?id=25512003
Yes, Alex is awesome - sincerely. I hate it with jackarses run around spewing crap about people without chatting or getting to know people by spending some time in the community.
I actually did. I analysed as much as I could with major exams over my head. I am planning to try the os later. Also I would love if you could contact me at arpan@hackersreboot.tech for some talk.
Interesting definition of 'pure functions':
Pure functions by default
V functions are pure by default, meaning that their return values are a
function of their arguments only, and their evaluation has no side effects
(besides I/O).
You mean the "besides I/O" part?
Yes. A 'system language' with pure functions would be, well, unusual.
Last time I checked V-Lang looked amazing on paper but on closer evaluation many of the claimed features were only planned, crashed the compiler on trivial inputs, or simply were half-baked and didn't deliver on the promises (things like syntax errors from the underlying C backend, memory leaks etc. because transpilation was straightforward and lacked proper checks, hence the fast compilation speed). A few months ago I superficially skimmed through their GitHub repo and it left an impression that it's still a toy language with same problems as back in 2020, although with some improvements (but it's just my impression), many ideas being borrowed from Go and Rust. From what I also found odd is that the author is overly fixated on their transpilation speed for some reason (i.e. IIRC citing V -> C translation only, without the C -> binary part), they have a few repos written in V and one of the main selling points there is compilation speed as well - probably at the expense of other features, because they don't do deep analysis (hence C compiler errors on trivial inputs). It struck me as something odd because I find memory safety, thread safety and overall stability more important than a few saved seconds of compilation.
I will be more than happy to learn that I am wrong and the situation has considerably improved, but other than that infamous GitHub issue "The language is not what is promised", I haven't seen a more recent (as of 2022) objective, skeptical analysis of the language by someone from outside their community. Maybe someone has links?
> citing V -> C translation only, without the C -> binary part
Not really, here's a benchmark of V compiling itself in 0.3 seconds that includes all steps (including the C -> binary part) and results in the compiler binary:
https://www.youtube.com/watch?v=pvP6wmcl_Sc
This video is linked on the home page.
> crashed the compiler on trivial inputs
We have thousands of tests, lots of big projects written in V (V itself is 220k loc, Vinix OS, Ved editor, Gitly, vsql etc), and they all work fine, no compiler errors.
Can you give an example of a trivial input resulting in a crash/C error?
The infamous "The language is not what is promised" you referenced has claims like "there's no way V is written in V", and "there's no way to do json serialization without an AST". These things are simply not true.
>Can you give an example of a trivial input resulting in a crash/C error?
Here:
https://github.com/vlang/v/issues/14023
I've seen quite a few such issues in the GitHub repo.
>We have thousands of tests, lots of big projects written in V (V itself is 220k loc, Vinix OS, Ved editor, Gitly, vsql etc), and they all work fine, no compiler errors.
Do these projects have large userbases (actual users, not just as a toy project)? How many contributors? I wrote a transpiler myself and I know that if you write in a safe subset (avoiding known gotchas) a project no one uses, then there's going to be zero problems with the project :)
I'm skeptical but I'm open to learn that I'm wrong.
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.
FWIW bro I enjoy that you are building something so ambitious and making progress despite the unwarranted hate. I have no idea why you bring out so many visceral trolls.
Can someone share why this guy and vlang are so hated? It seems like he is ironing out the kinks even years after the hate keeps piling on.
He keeps this up he's going to win.
I applaud Alexander's efforts, but the hate is somewhat warranted, because they make misleading claims such as having "innovative memory management" when in fact they merely use Boehm GC. All the hate could be entirely avoided if their "marketing material" was a little more honest and humble.
no, we don't "merely use Boehm GC"
What else do you use besides it?
autofree (compile time frees)
it's on the website and in the video I referenced here
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
gc is also behind the flag
so why do you pick one over the other?
the language is still at 0.2
Are you arguing it's fairer to say V's default is to ignore managing memory at all?
>so why do you pick one over the other?
Because the documentation recommends to use GC instead of auto-free which is "WIP".
It's a communication problem.
Looking at the homepage and the projects it feels like everything is ready and, if the claims were true, it would be the most ground breaking language of the last decades. When you go to look at the code or try to run something you find out: - some things are still closed source - some are broken - some are wins from C
It's a great strategy for collecting a check from VCs and I wish the author the best of luck, but it won't fly with developers.
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.
That was before the public release and only lasted for a week.
So saying now 2.5 years later some things are closed source is ridiculous.
Could you point to the C2V source?
So, you're saying C2V is closed source then? Which is exactly what Alex said isn't true.
There is a difference between not releasing the source yet versus closed source. Often, closed source refers to not ever going to open the source, including commercial interests. In regards to not yet releasing the source, things can be in the process of being worked on, made ready for public review, or being organized where other programmers can more sensibly contribute to the source.
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
Note that, in most cases, you can't respond to a comment because it's been posted too recently. I think it's a mechanism to prevent flaming.
No things are closed source. Never have been.
What things are broken for you?
What claims are not true?
It is very impressive that the creator of Vlang can come here to face the critics, trolls, and bashers. That tells you something positive about his character and fortitude.
What is also very interesting, is that when various trolls make their derogatory claims or bash on his creation, he responds to them with facts and references. Many of them never respond back and run away.
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 :)
> Not really, here's a benchmark of V compiling itself in 0.3 seconds that includes all steps (including the C -> binary part) and results in the compiler binary
From what I've seen, you've used tcc for the benchmark, right? If so, that's kinda cheating, since tcc is written to be a simple as possible (and therefore as fast as possible), so the compilation time is essentially zero. Benchmarking with gcc with optimization turned on should give you a more realistic result.
> We have thousands of tests, lots of big projects written in V (V itself is 220k loc, Vinix OS, Ved editor, Gitly, vsql etc), and they all work fine, no compiler errors.
To quote Djikstra:
Program testing can be used to show the presence of bugs, but never to show their absence.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.
> 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"
It would be absurd for someone to write a frontend to LLVM then claim that their compiler is as fast as LLVM. V uses TCC - TCC is fast at compilation, not V. V is fast at transpilation, but that's not what the author has claimed.
> that you included the Dijkstra quotation in this context is honestly quite humorous
Proving compiler correctness with tests only is like proving that your regex parses html correctly with tests. It's never gonna work.
Does Rust not make claims about performance, even though a large proportion of that comes from LLVM's work? Do Rust or GCC or Clang (or probably even Haskell) use tests as the primary way to ensure/approach correctness? The number of compilers for any language that actually prove correctness and that are used for some practical purpose can probably be counted on one hand (e.g., CompCert), so I'm not going to use that as an appropriate bar.
The tcc backend is just a smart choice, and in TFA it is mentioned up front:
> V compiles ≈110k (Clang backend) and ≈1 million (x64 and tcc backends) lines of code per second per CPU core. (Intel i5-7500, SM0256L SSD, no optimization)
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.
It may be easier to have a C backend that is compiled via tcc, but if it's a smart choice (for the tradeoffs of a debug build), and hardly anybody else is doing it, then it's positive and noteworthy. The fact that it may not be particularly difficult is irrelevant.
I can't assess the quality of V in general, and it may be lacking for my needs, but I know a lot of early stage language projects with a lot of trivial bug reports (I've filed a few), that are still engineering accomplishments capable of real usage. V seems to be in that league. Maybe it's near the bottom of that league, but you can just state that and leave it at that.
Maybe V has a bit of a "dirty main branch" approach, where other languages you're used to tend to instead have long-lasting branches for the work-in-progress stuff. I can see how that would be annoying, being able to use half-finished functionality, and I might not like it myself. Maybe the author claims features are further ahead than they really are -- that would be even more frustrating. But your criticisms are hyperbolic (denigrating the work as at the level of a CS homework assignment, and comparing it to almost entirely non-existent languages that are mathematically provably correct) and often seem vindictive (unlikely to be leveled at other highly analogous early days language projects). Any legitimate criticisms you have are lost in the vitriol.
Can you link to those trivial examples demonstrated in other comments?
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.
Alright, you cheeky bastard. It's on.
You can expect a deep (and public) analysis of everything you've done with V in a couple of months. We'll see who's right.
> I don't think it's reasonable to say this is a wholesale illegitimate/cheating approach.
Thank you for a voice of reason :)
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.
What is the performance delta between debug and prod? What is the performance delta between tcc and GCC -O0 if you’ve had a chance to compare?
I also disagree with others that using a different compiler is somehow cheating. Engineering is about winning and choosing the right tradeoffs. Being able to choose a faster backend for debug is one that all compilers offer. Most people spend most of the time living with -O0 builds because they need to debug the code. Heck, 90% of complaints about Rust compile times are about its performance making a debug build and it’s where that dev team spends its efforts. This criticism seems misplaced although it’s not clear to me why there’s this much pushback that most other languages don’t see.
No difference between tcc and gcc -O0, despite tcc compiling it 10 times faster.
20%-100% difference between gcc -O0 and -O2.
It's a dishonest benchmark. You're basically saying that "V compiles fast if you use a fast C compiler after the transpilation step", and wrapping it up as "V compiles fast". Those two are not exactly the same.
It's absolutely not a dishonest benchmark. This backend comes bundled with V, it's what it uses by default. That's how you get the end result binaries when you use V.
To the end user it doesn't matter how the binary was generated. Via LLVM or via a bundled C compiler.
The only thing that matters: getting that binary after compilation and getting it fast.
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 not a justification. It's how it works. People download the language, they use it to compile a binary, it's produced quickly.
I'm not sure how you can argue about that.
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.
Runtime speed is as fast as it gets, because it's C.
Writing an interpreter is a huge task. It works well without it. Actually I'd say it's quicker, because interpreters have startup costs.
No, "it's fast because it's C" doesn't hold. You can write slow code in any language.
As I said, I may be wrong. I think I will try V some day to see it for myself (maybe I'll write an article about my findings). As you are the author of the language, can you comment on what is the state of the auto-free system? How is memory management implemented?
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.
Is all the extra copying that autofree has to do related to the lack of move semantics in the language? Nim had to introduce a bunch of new language constructs/semantics to support their ORC backend, which is the solution that’s similar to yours. (See https://nim-lang.org/docs/destructors.html.) I expected V to move in the same direction but hadn’t found any discussion of move semantics in the docs so I found it strange.
V will never have move semantics. Complicates the language too much.
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?
>But it's not finished yet. We saw a better performance with a GC (due to all the extra copying autofree has to do), and made it the default
On vlang.io I can find this:
>Most objects (~90-100%) are freed by V's autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via GC.
So it's been 2 years and it's still unfinished, and you just use Boehm GC instead (from what I understood). Isn't your landing page a little misleading? This is the problem with V: a lot of grandiose claims but at the end of the day you use a GC used in every other toy language.
But it says right there:
Note: right now autofree is hidden behind the -autofree flag. It will be enabled by default in V 0.3.
Using gc means it's a toy language? Got you.
>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.
Then by this definition and by example of what has been done with V so far, it's definitely no "toy language."
I don't think V has proven its robustness or completeness. One thing that could change my mind is if one of the applications got completed and was actually usable.
For example, I'm really interested in the Volt thingy - a lightweight, multiprotocol chat application:
But if you open the website, you can see that there is no Linux or Windows support, and most protocols are not yet implemented. I've searched for other projects written in V, and haven't found a single completed project.https://volt-app.com/
Could you explain clearly what is the memory model of the language? Because I haven’t seen it anywhere outside of the ridiculous old claims.
Hey Guys, So I am the author of the article and it is about time I address the comments here. I just want to say that I just got to know about it, I used it and it felt good. I tested a lot of the features but ofc couldn't get them all. I know nothing of any controversies surrounding the language. Also, I am just starting out in writing so I might've not included some details or it might've looked like a "sales talk" but in all honesty I had written a section in the draft versions but forgot to include it. I am planning to write another post to address the issues of the language and my writing about it.
Thanks for reading and commenting. I appreciate it and hope to use these comments to improve myself as both a researcher and a writer. Thanks again!
If I may offer a suggestion:
Focus on what information you're trying to convey and try to say it in the minimum amount of words. Prefer sentences that convey information ("V is has a 10MB compiler" - we learned the size of V compiler) to sentences that don't ("V-lang is an extraordinarily powerful language that can help you create a variety of applications" - we learned nothing, since "powerful" is subjective, and all languages can be used to write applications). That will help you focus on communicating your ideas clearly and tersely, which will make your articles much more attractive to technical readers.
Good luck with your research and writing!
Thanks for the tip! Will use it.
Great. We rewrote our backend into D, then Arc, then into Go, and most recently into Rust. If V-lang is as good as it sounds, we'll need to ditch thousands of lines of pristine Rust code. HN-driven development methodology really has no mercy. /s
I personally think Rust is one of the best and the most unique language in its form and will grow to play a far greater role in the dev world. I am just beginning to learn it and am most fascinated by it. Just published about "V" because new and independent ones like it also need our love and support to grow and mature as others have.
Previous discussons:
https://news.ycombinator.com/item?id=24481883 (144 points, 191 comments)
https://news.ycombinator.com/item?id=19403271 (191 points, 182 comments)
https://news.ycombinator.com/item?id=19526924 (61 points, 101 comments)
https://news.ycombinator.com/item?id=20229632 (146 points, 137 comments)
https://news.ycombinator.com/item?id=21296855 (123 points, 91 comments)
https://news.ycombinator.com/item?id=20250990 (180 points, 155 comments)
https://news.ycombinator.com/item?id=20258485 (63 points, 33 comments)
You chose threads primarily from 2019. We are now in 2022. So threads and comments from 3 years ago are mostly not relevant. Some threads are even prior to Vlang ever being released (March 2019 comments versus release date of language in June 2019). To include persistently claiming Vlang is vaporware, despite it now having over 90 releases (at nearly a new one per week pace) and being well documented in terms of language and modules.
https://github.com/vlang/v/releases (releases) https://modules.vlang.io/ (modules) https://github.com/vlang/v/blob/master/doc/docs.md (documentation)
An interesting language that’s worth a look
It is indeed very astonishing why many people here have such a negative attitude towards this language.
Because author kinda twisted terms to make it seems he achieved the impossible. Felt like he did better than rust+ada+haskell, all without using memory and faster than an eyeblink.
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.
> sets high goals
The problem is that in the initial releases the "high goals" were listed as "features" of the language, not as planed improvements of the initial implementation. So even now when I read a list like in the article, I'm not sure which are already implemented and which are just wishes, but after the initial bad impression I'm not bother to check.
Problem? Is the communication not up to the author? And shouldn't people rather help out than just make demands on an open source project?
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".
Nice to see he's kept his word and following through as is the community. Really great and lovable group of folks. Sometimes there are cultural differentials, but everyone is really great and with a primary and essentially only rule of "be nice" - I think it's a breath of fresh air in this screwed up time.
It's not uncommon and no bad practice at all to fully specify a language before it is fully implemented. There were a couple of languages where the compiler took even many years to come into existence after the language was published, or was never finished. Other people - like e.g. me - develop the language specification and compiler in parallel. Just different ways to look at it.
How is it related to spec'ing the language. It's just fuzzy use of terms to appear extraordinary. That's all. Btw he still didn't answer my simple question, meanwhile everybody is commenting saying how nice the community is, how people should help instead of criticizing and deflecting the actual issue people had with the project.
> 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.
I'd like to see the ALGOL group writing "we're faster and leaner than fortran" while writing their spec and no compiler to run tests against. I struggle to follow.
Something like this actually happened when they had to decide between Wirth's and Hoare's practice-oriented proposal and Wijngaarden's rather academic proposal. There was quite a bit of controversy about this, not based on true implementations. Big egos exist everywhere and in all times.
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.
Apparently you don't ignore it.
All claims on the website are valid with latest V.
Really?
- No null
Then what is `voidptr(0)`?
- No global variables
https://github.com/vlang/v/blob/master/doc/docs.md#global-va...
At least add "by default" to the web site.
- No undefined values
Which is done by initializing all values to 0. Probably not a good idea to do that for references though. (See also "no null values")
- No undefined behavior
`*voidptr(0)` is accepted by the compiler. Unsigned integer overflow is accepted by the compiler and UB in the generated C. How can V generate C code free of UB when it can't even generate C code that compiles all the time?
- Pure functions by default
Excluding I/O, one of the biggest sources of impurity, from your definition of pure is useless.
- Generics
You don't actually have generics, you have templates. Kind of ironic since Go has actually added generics before V has managed to get a 0.3 release out. The distinction is this: with generics the compiler is able to validate that the generic code type checks prior to substitution/monomorphization. With templated code, it's not possible to perform type checking until the concrete types have been instantiated. V implements templates with all the drawbacks including code bloat and inflated compile times that comes with it.
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.
So no actual response to objective criticism just "my interpretation is things are going well so they can claim anything they want"? Wow, what a compelling argument you make!
If you want to look at GitHub, sure let's do that. I see perhaps 5 regularly active contributors, many more who seem to have left the community, and a downward slope of commit activity starting in April 2020. Hardly some vast hub of activity like your comment would suggest.
Given autofree has been practically untouched in 6 months with no major bug fixes to speak of, reality would seem to be that V is on the slow road to nowhere. At the current rate of progress, I doubt we'll see 0.3 before mid 2023 and 1.0 perhaps sometime in the 2030s. It's been 6 months since anything was completed on the 0.3 checklist: https://github.com/vlang/v/commits/master/ROADMAP.md
Probably, it would be good to do other things than trying to troll or presenting distorted information. It is very easy to go to GitHub and check Insights (https://github.com/vlang/v/pulse). Vlang's commits and additions are comparable and on pace with other languages in a similar category such as Odin, Crystal, Zig, Nim... Check the GitHub Insights for those other languages, and have the truth revealed.
Maybe it's an impatient rival developer thing, but I'm not quite sure what your laser focused fixation with autofree is about. Its the V developers and contributors prerogative to work on it as they see fit. If you don't use Vlang, then why in the world are you so desperately worried about it?
> Given autofree has been practically untouched in 6 months...
A search on Vlang's GitHub for issues both open and closed shows contributor and developer activity regarding autofree within the last 6 months, to include the last week. Sample- https://github.com/vlang/v/pull/13823
> At the current rate of progress...
Can you show us the HN troll accounts and incessant badgering of the Nim developers, who started in 2008 and didn't achieve 1.0 until 2019 (11 years later)?
Where are the HN troll posts under zig1dot0 about Zig not being 1.0, despite starting in 2016 (3 years before Vlang)?
How about with Odin? Surely there are HN posts by odin1dot0, who is incessantly complaining to Odin developers and fans about slow progress? Since they starting in 2016, but have yet to reach 1.0 either.
Right, not trolling them, but have a vendetta against Vlang for whatever mischievous reasons. Is it jealousy over supporters, funding, or publicity? Who knows. The problem is the trolling is very obvious and excessive. Just give it a rest and allow the fans and supporters of Vlang their peace. Enjoy whatever programming language you are using or developing and don't sweat Vlang so much.
> what is not clear to me at the moment is what are the specific innovations over the other already established languages.
I'll make it more clear on the website.
There's already a comparison to Go, the language V is most similar to:
Quite a lot of improvements.
V is basically about having the performance of C, the ease of use of Python, the simplicity of Go.
Thanks for the link; that's going in the direction I was looking for. So could one say that V is essentially the Go the author would have wanted, and the new language is justified by the "~20%" difference, and an independent development is necessary due to the slow pace at which Go is evolving? So that would be a similar motivation as Nim versus Python, or Oberon+ versus Oberon.
The feature differences in list form are helpful; but the priorities and motivation for individual features would also be interesting; e.g. why is "variable shadowing" bad and why is the V approach better, and how can smaller runtime and binaries smaller by a factor of 100 be achieved with a feature set that is at least 80% the same as Go? Does this really have to do with the language definition, or rather with the implementation?
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.
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:
Are you the V designer ? is V compiled to native code or transpiled to C (then an actual compiler will make the work to emit native) ?
There is a lot of competition among the newer programming languages. A lot of criticism and trolling is to disguise their invested interest and advocacy for their preferred language. That Vlang rose up so quickly and has done so well for itself in comparison to their language, is a cause of resentment and anger for some.
I took it for a spin recently and enjoyed the experience. The Postgres driver was woefully slow, compared to Golang (50 queries per second for a trivial query vs over 10k), which is the only reason my side project isn’t in V.
It’s a great language, though. Looking forward to using it in the future.
Wow that shouldn't be the case!
Can you link to the pg benchmark you did? We need to fix this asap.
Sure. I’ll open an issue tomorrow when I’m back at that machine.
Thank you. The db drivers do need some love and are going to get it soon, but it's been a relatively lower priority considering other areas of focus by community members.
That is a weird site. It's as if they're about to try to charge you for the actual info. on VLang. A real air of scamminess pervades - even though AFAIK it's entirely legit, of course.
Will give a try once more ... Last time wasn't so great though.
Why was this misspelled? Shouldn't it be Vlang (https://vlang.io/), not V-Lang?
Ok, so I am the author of the article and I wanted to put it as "V" but wasn't differentiating for example in search and "Vlang" just didn't feel good.
I kind of get what you mean, but the common practice is to spell it as Vlang, which other languages that are referred to by short names do too. Like Go, becomes Golang as oppose to Go-lang. But, we all have our preferences. Who knows, it might catch on to refer to it as V-Lang. It's your prerogative to do as you like, and it was great that you created the article and are into programming.
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.