The V language now compiles itself in 0.09 seconds
github.com
github.com
I want to know from V's critic, where do they feel the language is right now, now that it has had some more months behind it? Do you still feel that its a lot of snake oil or do you think it is going along a good path? Not trying to push an agenda but I am genuinely curious because I have never seen such definitive opinions against a language before in HN.
I am yet to use V (waiting for the Doom demo which would be the proof of the pudding for me), but i do check its chat and github every now and then; and things seem to be going along much better now. lots of contributions, better project management and timely fixes.
Here are some of the older threads on V;
https://news.ycombinator.com/item?id=19403271
Zig's author's criticism is hard to respond to, since he claims things like "the V compiler has freetype and glfw dependencies", which is absurd:
https://news.ycombinator.com/item?id=20230351
Also he claimed there was no REPL, cross compiling or hot code reloading, when all these things were there:
Clickbaity rhetoric like "V Language Released" with no source code and many missing features, and now "compiles itself in stunning 0.09 seconds" without a rigorous dataset or accompanying list of features that said compiler supports are likely the source of the backlash.
My outsider advice, as someone who has never made a language (so, props to you for that) is to lower the hype level, and instead focus on posting news like deep-dives into design decisions and implementation stories, which people in the PL community are more likely to appreciate.
I think 0.09s compilation is pretty cool, I worked a lot to make it happen, and I'm excited to share it.
There's nothing wrong with releasing the binaries, but a more genuine headline might've been like "V Language: Alpha Compiler Binary Preview".
And the 0.09 second compilation is really cool! But a more genuine headline would've been "I got V to compile itself in 0.09 on my computer".
If you think I'm ranting or nit-picking, so be it. But my experience in software development is that exaggeration leaves a bad taste in people's mouths, and could harm the reputation of your otherwise really interesting language project.
The binaries were released 2 days before the source code, which was a weird decision. I never realized literally tens of thousands were following my every move. I'd be more careful then.
You've piqued a lot of interest, and now a lot of people are following your every statement. I can imagine that managing those people's expectations isn't trivial.
Best of luck! Looking forward to 1.0
I read through the documentation, and I can't find anything that triggers my bullshitoemeter, or that I disagree with (with the exception of throwing compilation errors for unused things, but that's just a nitpick).
By the way, it's actually a warning now in debug builds :)
I was afraid I'd have to do another https://github.com/kstenerud/go
Thanks for pointing this out.
Seems like this trend will probably continue with regards to the "1.0 release in December 2019" claim advertised in the Github description[1][a], since things like memory management are not implemented yet[2] and the December 2019 deadline would mean going from "first public alpha"[3] to 1.0 in less than a year.
[1] https://github.com/vlang/v
[a] depending on what 1.0 means, I guess
No judgement here on the project, just an observation. I'm excited to see where the project ends up.
I've gotten better at this but it's taken a couple decades and I've still not mastered it. I figure I'm in good company. Steve Jobs developed this ability between his stints at Apple and Elon Musk is still working on it.
...it seems completely unremarkable to think the 1.0 date is too ambitious.
I mean, you can tag 1.0.0 today and say you’ve made it, but that doesn’t actually achieve anything meaningful.
Are you actually confident about your roadmap to 1.0?
It seems very ambitious to me to have these done by December:
- V can translate your entire C++ (wip) project and offer you the safety, simplicity, and up to 400x compilation speed-up.
- Loading complex 3D objects with textures (wip)
- Camera (moving, looking around) (wip)
- Skeletal animation (wip)
- Translating DOOM from C to V and building it in 0.7 seconds (x25 speed-up) (wip)
What about macOS and windows support?
/shrug
/shrug
I guess I’ll just leave this comment here so I can link you back to it explicitly in december when you ask for exact details on what you promise vs. deliver next time.
Last time I did not write, but I also was kind of confused by some of the claims.
This time I'm actually quite blown away. The author seems to have managed to write a quite cool PL incl. an ecosystem of libraries, package manager, community, ... - great stuff!
Focusing on the fact that the language is written 100% in itself from the start? Nope!
Mention that it builds itself in <1 second? Nah
Graphics library, DOOM's p_enemy.c translated to p_enemy.v which can be compiled and replace p_enemy.o, safety features? No.
The language can be bootstrapped with "cc v.c" without any dependencies? Who cares!
There's a temporary one-line os.system() hack? VAPORWARE!
As far as I know, several of these features were not marked as WIP when this article was posted. Additionally, no features were marked at all close to the article's posting. From the article:
> This article was posted on 2019-06-23. Facts and circumstances may have changed since publication. Please contact me before jumping to conclusions if something seems wrong or unclear.
One if its criticisms is the claim on memory management. Here's an snapshot of it on 2019-06-25: https://web.archive.org/web/20190625172349/https://vlang.io/.... Here's the page now, marked as WIP: https://vlang.io/docs#memory.
You could argue that you simply forgot to mark these. I'm not going to go into discussion about that, but I just want to say that the author's claims seem legitimate at the time of posting.
> ... and that the first public alpha release is not stable.
Another quote from the article:
> Thanks for reading this far. I hope this feedback can help make V a productive tool for programming. It’s a shame it seems to have been hyped so much for comparatively so little as a result. The developer has been hyping and selling this language like it’s the new sliced bread. It is not. This is a very alpha product. I bet you could use it for productive development as is if you really stuck your head into it, but as it stands I recommend against using it for anything.
> The language can be bootstrapped with "cc v.c" without any dependencies? Who cares!
One of the article's criticisms is that that claim isn't (wasn't?) true.
Overly emotional attachment to one’s technical ideas and works is only a recipe for eventual mental stagnation. To be clear though, I’m not claiming this is necessarily an issue for the parent.
Here's how it looks like, although it doesn't compile at the moment:
https://github.com/vlang/doom/blob/master/p_enemy.v
I have to finish this project asap.
is not an acceptable thing to do.
Nitpicking one liners like that from a huge one man project that has just been released is ridiculous.
Luckily the language continues to grow at a rapid pace despite all clickbait vaporware articles.
I never understood that mentality without having some personal connection to the topic or a deep understanding of the topic.
I see the [wip] progress labels all over the site now, I guess some people need it to be explicitly labeled before the give a full break down of what you've made!
A lot of the criticism of V takes aim at how the language was advertised which strikes a lot of people as rightfully annoying in the "C++ killer" space, something that a lot of people have put a lot of hard work already into which should not be entirely out of hand (this space is becoming very crowded for attention). If V's code remained the same at launch with its author choosing to be a little more conservative and thoughtful with its announcement, this type of response would not have happened. Its author did not make the status of the language entirely clear. When Odin came out a year ago, Lobster half a year ago, Zig three years ago, or Mun a month ago (of whom its authors were considerably modest: see https://news.ycombinator.com/item?id=21173822), sure, they were critiqued, but they were not met with the specific kind of response V had for a reason.
Keep in mind languages (that don't aim to be toys) should rightfully be subject to a greater degree of criticism as their goals are primarily to upend a domain in such a way that if they fail, it renders the efforts of a lot of other people writing code in that language as something for naught. People take gambles when they adopt new technologies in general, but languages (maybe operating systems by extension) are of a significantly different scope.
https://github.com/vlang/v/issues/35
I don't want to discount all of the work people have put into V. It is clear that they have made considerable progress since earlier this year and I commend them for pushing the language into a more usable state. Nevertheless, I still retain a considerable degree of skepticism.
> Claims to "being able to now compile itself in 0.09 seconds" whilst pushing the need for an AST to the side represents a serious problem in the language's general direction
Critique for focusing on fast compilation times? :)
Any valid criticism?
Using codegen to handle the JSON stuff is clever, sure, but it certainly makes me uneasy! It gives a very Jenga Tower impression of the state of the project...
Why? That thread seems to talk about this in the context of serialization and the way your parent poster is proposing is pretty common in the microprocessing world since dynamic parsing would be wasteful and, given fixed data structure, can be unnecessary in some cases.
Honestly, the most interesting thing to me as an outsider in that whole github issue you posted is how much mudslinging and animosity seems to be going around in the PL development community. It's not like people are forced to use alpha releases of random programming languages popping up on github.
Fwiw, I'm not sure what you mean by AST in the context, but if you're talking about an actual in-memory AST, there's (once again) research in getting rid of it for compilation.
Not even on the internet. Have an idea, people reflexively shit on it.
When I see an idea unless it's utterly broken I try to figure out how you make it work. Not pat oneself on the back for coming up with some trite reason why it won't.
Indeed.
These [wip] labels were there before this vaporware article :)
Only a day or two at most according to archive.org. No WIP labels on 2019-06-21 (the closest snapshot available before the article was published)[1]. WIP labels exist on 2019-06-24 (the closest snapshot to the articles date)[2].
[1] https://web.archive.org/web/20190621013937/https://vlang.io/
[2] https://web.archive.org/web/20190624052507/https://vlang.io/
Ripping on a WIP project is not an acceptable thing to do.
Even the title "V is for Vaporware" is just oozing bias and condescension, and makes me lose any respect for the author.
The complaints were that all the claims were WIPs, and none of them were implemented and working to a level that can be relied on and used. Yet the project had already gotten more donations than other similar projects that are way further into their development.
Then, a lot of language programmers with credentials behind them came out and basically tried to warn people that going from WIP to Production with all those claimed features is very hard and the chances of failure for V are high. That there was a reason no language currently existed that had all those claimed features together. Doing so is very challenging.
So at that point, the outrage was that some people are potentially being fooled into donating for something that will never meet its claims, a.k.a, Vaporware. Or that it's unfair to donate to V, where it could be similarly donated to other languages that's been at it for longer which could make it all happen sooner.
Now, here's my take. I think the criticism is fair. I think the odds of V being a better language than all the other existing ones once it's ready and done are slim. But, I also think that it having had better marketing, bold claims, and clear ambitions, might be the only chance it has at making it. The funding it's getting, the support from other contributors that showed up after all the marketing push, that could pay off. Look at the commit history pre/post all the marketing. I've never seen an open source project that's so early in development having so many contributors beyond the ones that are made by a company hiring a team.
Basically, I feel tech people underestimate the value of marketing and a good sales man. These things are needed to build a good product as well. You can't build anything without resources. Steve Jobs couldn't have built the iPhone from a technical angle, but the engineers couldn't have built the iPhone without Steve Jobs enabling its focused development.
All the luck to V, and all the other languages to be honest. I don't care how it happens, through overblown marketing, clickbait articles, or through academic rhetoric, or from pure passion, or through someone working in a cave somewhere disconnected and coming out of it all of a sudden, etc. I just would like for it to happen.
Completely false.
Only a small part of the features was WIP.
The name-calling is what makes me uneasy.
The big missing item so far is GC (memory management is manual). Another thing is that the language evolves constantly, so you keep having to change your own code every week or so to stay valid.
The memory model is going to be similar to Rust. No GC or manual management. I'm actually working on it right now. Should have done it sooner, but it took me lots of time to do the research and chose the right model.
Getting the Rust compiler to handle memory correctly took years one complete refactoring of the type system, and a number of less major changes before Rust reached version 1.0. Even after that, the borrowing system has regularly been refined to become gradually more intuitive and more powerful.
Do you have precise plans for this feature? If they're written somewhere, I'm quite interested :)
Good luck in the future. You clearly have a lot going for you.
It really isn't. That's the one thing that would make me immediately lose interest in the language. Are there not enough options out there for non-realtime critical code?
I wonder (and hope!) V lives up to the hype. It's a lot.
You can insert a `defer log.Println(err)` if you want to handle that particular error but I didn't bother.
log.Println(err) would be better than returning err, because returning err makes people wrongly think the error is being handled somewhere, when in reality nothing is looking at the return value. Using defer for that seems a bit strange though.
$ size v
text data bss dec hex filename
445817 1032 688 447537 6d431 v
$ ./v -o v2 v.v && size v2
text data bss dec hex filename
651086 51000 1000 703086 aba6e v2 0[08:48:16] /v/v $ time ./v v.v
real 0m0.219s
user 0m0.153s
sys 0m0.064s
0[08:48:25] /v/v $
Its goal is to be minimalistic, simple, readable, maintainable.
Hot reloading UI:
https://cdn.discordapp.com/attachments/592118040179507207/63...
Hot reloading a graphical application:
I'm also interesting in C++ interop...
This language looks pretty great. Simple, fast, nicer and lean syntax.
I'm still curious why I often see "name string" intead of "string name". I guess it's easier to parse? pythonic indent would make this language perfect.
0 - https://vlang.io/docs#bash
1 - https://github.com/vlang/v/commit/5cd38ec91bc1919aca9f63432e...
Interfacing v code into a C++ app, is like interfacing with any other C library, with the addition, that you may have to write the C headers yourself (or you can cut/paste them from the produced C file).
If you want to call a C++ function from V, you have to export it from the C++ side, like you would do for a C app: extern "C" { int your_function(int x) } ... and then call it from the V side like any other C function. (https://vlang.io/docs#calling_c)
On reading the docs, I wonder if immutable variables and const globals can be merged as a concept?
I realize the consts can be fun complex 'structs', and have features that maybe immutable variables can't? -- No mutable globals is good. But still, is there a deeper reason to not merge const/immutable
https://cdn.discordapp.com/attachments/592118040179507207/63...
I remember having to wait days or even weeks for something to train while I either sit back and relax or work on the next thing to train.