7 ms·

Last time I checked V-Lang looked amazing on paper but on closer evaluation many of the claimed features were only planned, crashed the compiler on trivial inpu

by kgeist 5y ago

Last time I checked V-Lang looked amazing on paper but on closer evaluation many of the claimed features were only planned, crashed the compiler on trivial inputs, or simply were half-baked and didn't deliver on the promises (things like syntax errors from the underlying C backend, memory leaks etc. because transpilation was straightforward and lacked proper checks, hence the fast compilation speed). A few months ago I superficially skimmed through their GitHub repo and it left an impression that it's still a toy language with same problems as back in 2020, although with some improvements (but it's just my impression), many ideas being borrowed from Go and Rust. From what I also found odd is that the author is overly fixated on their transpilation speed for some reason (i.e. IIRC citing V -> C translation only, without the C -> binary part), they have a few repos written in V and one of the main selling points there is compilation speed as well - probably at the expense of other features, because they don't do deep analysis (hence C compiler errors on trivial inputs). It struck me as something odd because I find memory safety, thread safety and overall stability more important than a few saved seconds of compilation. I will be more than happy to learn that I am wrong and the situation has considerably improved, but other than that infamous GitHub issue "The language is not what is promised", I haven't seen a more recent (as of 2022) objective, skeptical analysis of the language by someone from outside their community. Maybe someone has links?

amedvednikov 5y ago
> citing V -> C translation only, without the C -> binary part Not really, here's a benchmark of V compiling itself in 0.3 seconds that includes all steps (including the C -> binary part) and results in the compiler binary: https://www.youtube.com/watch?v=pvP6wmcl_Sc https://www.youtube.com/watch?v=pvP6wmcl_Sc This video is linked on the home page. > crashed the compiler on trivial inputs We have thousands of tests, lots of big projects written in V (V itself is 220k loc, Vinix OS, Ved editor, Gitly, vsql etc), and they all work fine, no compiler errors. Can you give an example of a trivial input resulting in a crash/C error? The infamous "The language is not what is promised" you referenced has claims like "there's no way V is written in V", and "there's no way to do json serialization without an AST". These things are simply not true.
- kaba0 5y ago
  Could you explain clearly what is the memory model of the language? Because I haven’t seen it anywhere outside of the ridiculous old claims.
- kgeist 5y ago
  As I said, I may be wrong. I think I will try V some day to see it for myself (maybe I'll write an article about my findings). As you are the author of the language, can you comment on what is the state of the auto-free system? How is memory management implemented?
  - amedvednikov 5y ago
    I don't think it's correct making claims like "it's a toy language" and "crashes on trivial input" without actually trying it out. You don't need an article to clone the repo, build the language in <1s and play with it. Autofree works: https://www.youtube.com/watch?v=gmB8ea8uLsM https://www.youtube.com/watch?v=gmB8ea8uLsM But it's not finished yet. We saw a better performance with a GC (due to all the extra copying autofree has to do), and made it the default. I've always been anti-GC, but V is so minimal and doesn't result in many allocations in the first place, GC works really well with it. In the end the user will have full control over how they want to do memory management: manual, autofree, gc.
    - kgeist 5y ago
      >But it's not finished yet. We saw a better performance with a GC (due to all the extra copying autofree has to do), and made it the default On vlang.io I can find this: >Most objects (~90-100%) are freed by V's autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via GC. So it's been 2 years and it's still unfinished, and you just use Boehm GC instead (from what I understood). Isn't your landing page a little misleading? This is the problem with V: a lot of grandiose claims but at the end of the day you use a GC used in every other toy language.
      - 5y ago
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]

by kgeist 5y ago

amedvednikov 5y ago

> citing V -> C translation only, without the C -> binary part Not really, here's a benchmark of V compiling itself in 0.3 seconds that includes all steps (including the C -> binary part) and results in the compiler binary: https://www.youtube.com/watch?v=pvP6wmcl_Sc https://www.youtube.com/watch?v=pvP6wmcl_Sc This video is linked on the home page. > crashed the compiler on trivial inputs We have thousands of tests, lots of big projects written in V (V itself is 220k loc, Vinix OS, Ved editor, Gitly, vsql etc), and they all work fine, no compiler errors. Can you give an example of a trivial input resulting in a crash/C error? The infamous "The language is not what is promised" you referenced has claims like "there's no way V is written in V", and "there's no way to do json serialization without an AST". These things are simply not true.

kaba0 5y ago
Could you explain clearly what is the memory model of the language? Because I haven’t seen it anywhere outside of the ridiculous old claims.
kgeist 5y ago
As I said, I may be wrong. I think I will try V some day to see it for myself (maybe I'll write an article about my findings). As you are the author of the language, can you comment on what is the state of the auto-free system? How is memory management implemented?
- amedvednikov 5y ago
  I don't think it's correct making claims like "it's a toy language" and "crashes on trivial input" without actually trying it out. You don't need an article to clone the repo, build the language in <1s and play with it. Autofree works: https://www.youtube.com/watch?v=gmB8ea8uLsM https://www.youtube.com/watch?v=gmB8ea8uLsM But it's not finished yet. We saw a better performance with a GC (due to all the extra copying autofree has to do), and made it the default. I've always been anti-GC, but V is so minimal and doesn't result in many allocations in the first place, GC works really well with it. In the end the user will have full control over how they want to do memory management: manual, autofree, gc.
  - kgeist 5y ago
    >But it's not finished yet. We saw a better performance with a GC (due to all the extra copying autofree has to do), and made it the default On vlang.io I can find this: >Most objects (~90-100%) are freed by V's autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via GC. So it's been 2 years and it's still unfinished, and you just use Boehm GC instead (from what I understood). Isn't your landing page a little misleading? This is the problem with V: a lot of grandiose claims but at the end of the day you use a GC used in every other toy language.
    - 5y ago

deleted 5y ago

[deleted]

deleted 5y ago

[deleted]