Last time when V was presented in HN, it got completely ripped apart by most posters. This was probably due to the many empty promises by the creator which V simply wasn't able to deliver on.
There were also hard criticisms posted by creators of other languages like Zig, wren etc.
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.
TBH the main criticism seems not to be of the language itself, which seems like a cool and worthwhile project, but of its "marketing".
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.
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.
This was posted by someone else, I never announced it. Never saw this post.
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.
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).
> many empty promises by the creator which V simply wasn't able to deliver on.
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.
The world is full of projects which are late, never fulfill the original plan, disappear with people's money, pivot direction or funding source, put arbitrary restrictions on use, etc. If someone publishes an ambitious plan, the disbelief is likely not personal. It's: "that almost never happens, we need some serious proof". Especially if the timing is more ambitious than seen elsewhere.
No judgement here on the project, just an observation. I'm excited to see where the project ends up.
Hey, don't take such criticism personally. It's just internet spout. It's awesome how far you've come. Things that are worthwhile often take longer than expected. The key is for creators to limit or pad public-facing estimates as their projects grow toward completion. It's not easy to temper the innate ambition and passion that drives projects into existence as they mature.
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.
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.
I feel exactly the same (thanks for compiling the links for reference).
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!
> Yeah basically complaining that WIP features explicitly marked as WIP are not ready ...
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.
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.
I wouldn’t take things so personally, and instead let your work stand for itself.
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.
People love tearing down other people and their things on the internet.
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!
I don't really get what point you're trying to make here. Yes, people should not be mean-spirited, but the opposite (i.e. the internet should be a hugbox) is just contrarian; and, for the record, I don't think the article is very mean-spirited at all when you take in consideration what percisely it was responding to.
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.
So what's the actual criticism? So far it's only been things like "it has a freetype dependecy", "it has no AST, so json decoding is not possible", "it's a joke language, no way V is written in V" etc.
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 (and I mean general in an aggregated way). Of course shelling-out to curl for your download function is a bodge to be fixed, but the language's issues are not merely one specific problem. The author's misrepresentation of the language, of course, hangs overhead upon all of this.
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.
And you link to the very same thread by another language author that claimed there's no way V could be built in V and JSON decoding is impossible without an AST.
> 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? :)
Are you advocating for implementing langauges in an AST-less way or are you working towards maturing your language? You don't sound diametrically opposed to ASTs (which are evident in essentially any modern language), so I have to ask why V was not originally implemented with one and why you don't consider it a more important problem.
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...
> Using codegen to handle the JSON stuff is clever, sure, but it certainly makes me uneasy!
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.
> You don't sound diametrically opposed to ASTs (which are evident in essentially any modern language)
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.
> People love tearing down other people and their things on the internet.
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.
Here's one thing my pastor (who was somewhat high-profile and had his fair share of 'haters') said a few times: You simply have to outlast your critics. Maybe all you need to do is keep at it, and ship an awesome v1 when ready. Best of luck :)
> 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].
The original issue people had involved money. Money always taints a project.
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.
I mean you can get all negative and skeptic, and I would respect that. Some developers, including me, have a negative attitude towards (or even spooked by) marketing, and that's okay. There are many others who like it.
I don't think it is not an acceptable thing by itself (I did have other issues with it at the time V source code had released, but this one is not). For example, QuickJS `std` module does the same [1]. To be fair to QuickJS though, it documents that fact correctly and it has never claimed to work in non-Unixy platforms.
V is a pretty interesting language. I've been playing with it for the last few months, it takes a lot of the good stuff from Go with saner syntax and defaults. And compilation speed is amazing.
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.
Indeed, the language changes very quickly. Things will stabilize by 0.2.
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 :)
You need to stop making up deadlines for yourself when things will be ready. Similarly with your IM people lose confidence in you if you are not delivering what you say you will. Just say you are working towards something until it is ready, to avoid this.
Good luck in the future. You clearly have a lot going for you.
> The big missing item so far is GC (memory management is manual).
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?
It'd just cause a panic and stop that particular goroutine. To properly handle it, it needs to be passed back into a results channel or something. Generally we don't intentionally cause panics in go code as a matter of style.
You can insert a `defer log.Println(err)` if you want to handle that particular error but I didn't bother.
log.Fatalln() does an os.Exit(1), it doesn't just cause that particular goroutine to stop[1]. log.Panicln() will also cause the entire program to exit unless there's a recover[2].
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.
V looks like a promising language. You know you have made it when there is an "awesome v" page on github. One question, why is the original `v` much smaller than the `v` compiles using itself?
$ 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
I think I might have to try v for scripting. I've been wanting a non-dynamic language for that purpose, and v having few dependencies and fast compile times might actually make it usable for that purpose.
Like a contributor I can say that @amedvednikov make a big effort to make such compilation speed possible. Also I can say that language is still easy to learn while having so many features.
How can I use V as a scripting language? I managed to use TinyCC as a scripting language but V seems to make more sense.
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.
V produces .c files, which are then compiled to .o files, like C.
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
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
https://news.ycombinator.com/item?id=20250990
https://news.ycombinator.com/item?id=20229632