4 ms·

Extraordinary claims require extraordinary evidence. If the information presented on https://vlang.io/ https://vlang.io/ had any hint of being aspirational as o

Extraordinary claims require extraordinary evidence. If the information presented on https://vlang.io/ https://vlang.io/ had any hint of being aspirational as opposed to comparing it directly with existing languages, and the author had less confrontational interactions with skeptical people online, the reaction to this language would be different. Of course, without the extraordinary claims this code dump would also not receive the attention it has.

bscphil 7y ago
It's worth noting that the website now has "WIP" annotations on many of the claims. I'm not sure how recently these were added as this thread is my introduction to the language. My assessment (not a language designer) is that this is something that shows some promise as a transpiled language for people who want a Go-like language without some of the common pain points and are OK with having no GC. I would add that people who do design languages seem to think it's going to be considerably harder to deliver on the WIP elements than the designer of V thinks. In particular, I note that "direct machine code generation" is a planned item (which would be required for the faster compile time that V promises), but doesn't (as of this source code release) seem to be started - could be wrong about that. Obviously you can promise whatever you want, but writing an entire machine code compiler that will run faster than GCC and equal it in performance is a difficult task. The goals of the project remind me a lot of Nim, and I'd have preferred to see a comparison with it rather than Rust. While I don't have a use for it myself, the designer does seem sincere about their efforts. (My "ideal" language would be something closer to a lightweight version of Rust that was simpler to use, even if it slightly ate in to what you could do with it.)
- amedvednikov 7y ago
  Thanks! Work on x64 generation started back in August. I'll publish it very soon. I haven't touched it in a while, and it simply doesn't compile at the moment.
- dom96 7y ago
  > It's worth noting that the website now has "WIP" annotations on many of the claims. I'm not sure how recently these were added as this thread is my introduction to the language. Indeed, many of these have been added just today. But even with the WIP tags many of these claims still seem false, for example, the author asserts that "V compiles ≈1.2 million lines of code per second per CPU core." but below that notes that "direct machine code generation" is still a work in progress. For this particular case it sounds a lot like the author wrote a very bare bones code generator that was over-optimized for that benchmark to produce these numbers. And indeed, as you mention, writing a machine code compiler is no easy task. > The goals of the project remind me a lot of Nim, and I'd have preferred to see a comparison with it rather than Rust. It reminds me a lot of Nim as well. As a core dev of Nim I find the hype surrounding it very interesting (and perhaps a little disheartening). For what it's worth, there used to be a comparison, and in fact we discussed it in our forum[1]. Sadly it didn't seem particularly fair and it seems that V's author has decided to remove it after our debunking. 1 - https://forum.nim-lang.org/t/4758 https://forum.nim-lang.org/t/4758
  - reikonomusha 7y ago
    I read in one of the issues that he compiled some thousands of calls to print, one per line, and that was the benchmark.
  - amedvednikov 7y ago
    > Indeed, many of these have been added just today. 2 days ago, but yes, very recently. Something I should have done from the start. > Sadly it didn't seem particularly fair and it seems that V's author has decided to remove it after our debunking. Araq's rude response didn't debunk anything. All points still stand. I removed the comparison because it's useless, and only encourages flame wars.
- renox 7y ago
  > writing an entire machine code compiler that will run faster than GCC and equal it in performance is a difficult task Except that AFAIK he didn't claim that the native generated code will be as optimised as what gcc or clang produce.. I expect that this native code generator is useful for the debug build where code compilation speed matters more than optimised code generated. Sure in some cases you need the performance even for debug build then you'll need to spend more time compiling..

bscphil 7y ago

It's worth noting that the website now has "WIP" annotations on many of the claims. I'm not sure how recently these were added as this thread is my introduction to the language. My assessment (not a language designer) is that this is something that shows some promise as a transpiled language for people who want a Go-like language without some of the common pain points and are OK with having no GC. I would add that people who do design languages seem to think it's going to be considerably harder to deliver on the WIP elements than the designer of V thinks. In particular, I note that "direct machine code generation" is a planned item (which would be required for the faster compile time that V promises), but doesn't (as of this source code release) seem to be started - could be wrong about that. Obviously you can promise whatever you want, but writing an entire machine code compiler that will run faster than GCC and equal it in performance is a difficult task. The goals of the project remind me a lot of Nim, and I'd have preferred to see a comparison with it rather than Rust. While I don't have a use for it myself, the designer does seem sincere about their efforts. (My "ideal" language would be something closer to a lightweight version of Rust that was simpler to use, even if it slightly ate in to what you could do with it.)

amedvednikov 7y ago
Thanks! Work on x64 generation started back in August. I'll publish it very soon. I haven't touched it in a while, and it simply doesn't compile at the moment.
dom96 7y ago
> It's worth noting that the website now has "WIP" annotations on many of the claims. I'm not sure how recently these were added as this thread is my introduction to the language. Indeed, many of these have been added just today. But even with the WIP tags many of these claims still seem false, for example, the author asserts that "V compiles ≈1.2 million lines of code per second per CPU core." but below that notes that "direct machine code generation" is still a work in progress. For this particular case it sounds a lot like the author wrote a very bare bones code generator that was over-optimized for that benchmark to produce these numbers. And indeed, as you mention, writing a machine code compiler is no easy task. > The goals of the project remind me a lot of Nim, and I'd have preferred to see a comparison with it rather than Rust. It reminds me a lot of Nim as well. As a core dev of Nim I find the hype surrounding it very interesting (and perhaps a little disheartening). For what it's worth, there used to be a comparison, and in fact we discussed it in our forum[1]. Sadly it didn't seem particularly fair and it seems that V's author has decided to remove it after our debunking. 1 - https://forum.nim-lang.org/t/4758 https://forum.nim-lang.org/t/4758
- reikonomusha 7y ago
  I read in one of the issues that he compiled some thousands of calls to print, one per line, and that was the benchmark.
- amedvednikov 7y ago
  > Indeed, many of these have been added just today. 2 days ago, but yes, very recently. Something I should have done from the start. > Sadly it didn't seem particularly fair and it seems that V's author has decided to remove it after our debunking. Araq's rude response didn't debunk anything. All points still stand. I removed the comparison because it's useless, and only encourages flame wars.
renox 7y ago
> writing an entire machine code compiler that will run faster than GCC and equal it in performance is a difficult task Except that AFAIK he didn't claim that the native generated code will be as optimised as what gcc or clang produce.. I expect that this native code generator is useful for the debug build where code compilation speed matters more than optimised code generated. Sure in some cases you need the performance even for debug build then you'll need to spend more time compiling..