5 ms·

I can't understand criticising a brand new, v0.0.12 language built entirely by one person of being too small...

estebank 7y ago
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..
deleted 7y ago
[deleted]
reikonomusha 7y ago
A lot of people have been finding the development of the project on a monthly basis. The work that has actually been done might be unsettling to the patrons.
- ylluminate 7y ago
  As a patron of his work, I'm thrilled with what he's doing.
  - amedvednikov 7y ago
    Thanks for your support!
- ScottFree 7y ago
  As a patron myself, I can confidently say you're way off base. The language has only existed for 3 months. It's going to take at least 2-5 years to get anywhere close to feature complete and another 5-10 years to get traction. Languages are a marathon, not a sprint.
deleted 7y ago
[deleted]
agumonkey 7y ago
It was presented as extraordinary. See the tables comparing V to GCC, Clang and others.. somehow the author managed to make a compiled that weighs nothing, requires no time and makes faster binaries ... As parent, I did look at the code to see, but I don't see anything. I'm under the impression that it's a thin transpiler, hence the 100x compile time increase. Correct me if I'm wrong. ps: also, about the personal/social implication of these threads. I wish no harm to v author, I find it admirable that he managed to produce the whole thing on his own. But it was seriously misleading.

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..

deleted 7y ago

[deleted]

reikonomusha 7y ago

A lot of people have been finding the development of the project on a monthly basis. The work that has actually been done might be unsettling to the patrons.

ylluminate 7y ago
As a patron of his work, I'm thrilled with what he's doing.
- amedvednikov 7y ago
  Thanks for your support!
ScottFree 7y ago
As a patron myself, I can confidently say you're way off base. The language has only existed for 3 months. It's going to take at least 2-5 years to get anywhere close to feature complete and another 5-10 years to get traction. Languages are a marathon, not a sprint.

deleted 7y ago

[deleted]

agumonkey 7y ago

It was presented as extraordinary. See the tables comparing V to GCC, Clang and others.. somehow the author managed to make a compiled that weighs nothing, requires no time and makes faster binaries ... As parent, I did look at the code to see, but I don't see anything. I'm under the impression that it's a thin transpiler, hence the 100x compile time increase. Correct me if I'm wrong. ps: also, about the personal/social implication of these threads. I wish no harm to v author, I find it admirable that he managed to produce the whole thing on his own. But it was seriously misleading.