The V language now compiles itself in 0.09 seconds(github.com)
github.com
The V language now compiles itself in 0.09 seconds
https://github.com/vlang/v/wiki/The-V-language-now-compiles-itself-in-0.09-seconds
93 comments
Soon I'll actually make a post covering all these "vaporware"/scam posts and articles.
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:
https://twitter.com/i/status/1137537130887077890
https://twitter.com/i/status/1153363259715702784
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:
https://twitter.com/i/status/1137537130887077890
https://twitter.com/i/status/1153363259715702784
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.
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.
What do you mean no source code?
I think 0.09s compilation is pretty cool, I worked a lot to make it happen, and I'm excited to share it.
I think 0.09s compilation is pretty cool, I worked a lot to make it happen, and I'm excited to share it.
What I mean is that when it was announced that "V Programming Language is Released", it was just binaries and no source code: https://news.ycombinator.com/item?id=20229632
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.
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.
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.
That is fair.
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
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
Thanks!
It's really cool! People seem to be ranting just to rant.
It got my attention. And I'm VERY picky.
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).
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).
Thanks!
By the way, it's actually a warning now in debug builds :)
By the way, it's actually a warning now in debug builds :)
OMG absolutely perfect!
I was afraid I'd have to do another https://github.com/kstenerud/go
I was afraid I'd have to do another https://github.com/kstenerud/go
I've updated the docs :)
Thanks for pointing this out.
Thanks for pointing this out.
> 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.
[1] https://github.com/vlang/v
[a] depending on what 1.0 means, I guess
[2] https://news.ycombinator.com/item?id=21296992
[3] https://news.ycombinator.com/item?id=21297051
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
[2] https://news.ycombinator.com/item?id=21296992
[3] https://news.ycombinator.com/item?id=21297051
Yes, so many empty promises I never delivered.
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.
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'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 can’t tell if you’re trying to sarcastic or not, but accurate estimates for software releases are notoriously difficult.
...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
...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
macOS and Windows were supported from day 1
/shrug
/shrug
whatever.
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 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!
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!
How many of Dodrill's problems have they solved so far?
https://christine.website/blog/v-vaporware-2019-06-23
https://christine.website/blog/v-vaporware-2019-06-23
Wow... talk about a mean-spirited article!
os.system2('curl -s -L -o "$out" "$url"')
is not an acceptable thing to do.
is not an acceptable thing to do.
Putting temporary code in a WIP project is perfectly acceptable.
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.
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 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.
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.
> The complaints were that all the claims were WIPs, and none of them were implemented
Completely false.
Only a small part of the features was WIP.
Completely false.
Only a small part of the features was WIP.
Very nicely said, all true.
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.
The name-calling is what makes me uneasy.
The name-calling is what makes me uneasy.
Which was fixed almost right away. In fact there's no libcurl dependency at all right now. OpenSSL/SChannel are used directly.
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.
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.
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 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.
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.
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.
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.
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? :)
Any valid criticism?
> 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?
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! 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.
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.
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.
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.
> People love tearing down other people and their things on the internet.
Indeed.
These [wip] labels were there before this vaporware article :)
Indeed.
These [wip] labels were there before this vaporware article :)
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].
[1] https://web.archive.org/web/20190621013937/https://vlang.io/
[2] https://web.archive.org/web/20190624052507/https://vlang.io/
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/
Which still means that the article was released after the WIP tags were added, and was complaining that WIP features don't work.
Only some people love to do that. Many others hate it when it happens.
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.
[1] https://bellard.org/quickjs/quickjs.html#std-module.
[1] https://bellard.org/quickjs/quickjs.html#std-module.
Yeah basically complaining that WIP features explicitly marked as WIP are not ready and that the first public alpha release is not stable.
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!
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!
> 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.
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.
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.
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.
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.
`p_enemy.c translated to p_enemy.v which can be compiled and replace p_enemy.o` <- that's extremely impressive, good on you! :)
Thanks.
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.
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.
[deleted]
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.
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.
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.
I'm very curious about this.
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 :)
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 :)
Pioneering is nearly always harder, and takes more time than later developments.
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.
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 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?
There will be no GC, see my reply above.
You did pick a (very) pre 1.0 language to play with. Constant change is to be expected.
I wonder (and hope!) V lives up to the hype. It's a lot.
I wonder (and hope!) V lives up to the hype. It's a lot.
That Go code on this page [0] isn't particularly idomatic (or even functional), consider something like this [1] perhaps.
[0] https://vlang.io/compare
[1] https://pastebin.com/raw/FsjAQvGt
[0] https://vlang.io/compare
[1] https://pastebin.com/raw/FsjAQvGt
That return err from the goroutine looks wrong, I don't think the error is ever used. log.Fatalln(err) would keep the behavior of the V 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.
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.
[1] https://play.golang.org/p/wwiq1bYjwVH
[2] https://play.golang.org/p/MpzafFlBSfx
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.
[1] https://play.golang.org/p/wwiq1bYjwVH
[2] https://play.golang.org/p/MpzafFlBSfx
Agreed, that is much more idiomatic.
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 v2It's built with GCC and -O2.
Maybe it's UPX compressed?
Wow, on my old i3:
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 $
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.
Well I wouldn't say the language itself has many features.
Its goal is to be minimalistic, simple, readable, maintainable.
Its goal is to be minimalistic, simple, readable, maintainable.
Pleased to read that hot reloading is a central feature!
Yes, really excited about it.
Hot reloading UI:
https://cdn.discordapp.com/attachments/592118040179507207/63...
Hot reloading a graphical application:
https://twitter.com/i/status/1153363259715702784
Hot reloading UI:
https://cdn.discordapp.com/attachments/592118040179507207/63...
Hot reloading a graphical application:
https://twitter.com/i/status/1153363259715702784
V seems pretty similar to Zig in that it tries to compete directly with C. Has anyone here used both? Which do you prefer and why?
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.
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.
Scripting is one of V's main features[0]. Just a couple days ago, it was incorporated into the 'master' branch[1] so you can now use it.
0 - https://vlang.io/docs#bash
1 - https://github.com/vlang/v/commit/5cd38ec91bc1919aca9f63432e...
0 - https://vlang.io/docs#bash
1 - https://github.com/vlang/v/commit/5cd38ec91bc1919aca9f63432e...
I meant compiling and executing V from C++, calling V functions from C++, and C++ function from V.
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)
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)
Congratulations!
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
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
[deleted]
Can I use live reload on functions that use imported c libs?
Hmm, this gif (linked elsewhere in the thread) seems to indicate that C libs can be used in `live` code.
https://cdn.discordapp.com/attachments/592118040179507207/63...
https://cdn.discordapp.com/attachments/592118040179507207/63...
Wow! Amazing!!!
Many features were stolen from Golang
In the context of programming language design, "stealing" sounds like the wrong term. Every programming language is inspired by others, isn't it?
Golang got many things right (and many things wrong). Why wouldn't you make use of the parts that work? That makes no sense.
You might as well say that "C++ stole from C" or "Linux stole all ideas from *NIX" which is nonsense. I would say V was influenced by Golang.
What features are you thinking off? At least for me golang is a pretty boring language in the sense it does not bring much new design.
Many words in your comment were stolen from the dictionary.
Amazing ... That would make https://www.xkcd.com/303/ obsolete ;-) !
Yeah, as someone noted, it'll soon be possible to re-compile V in every frame of a video game :)
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