4 ms·

Going through their docs, I'm having hard time identifying the 'silver bullet' that makes this all possible. This is m first time seeing this language 'V'. So

Going through their docs, I'm having hard time identifying the 'silver bullet' that makes this all possible. This is m first time seeing this language 'V'. So no pre-baggage. The splash page is making extraordinary claims. But a lot of languages have the same features, but not the big claims like size and speed. So what is this group doing different that couldn't be done in Rust or Go or dozen others. Do we need another language? Or if there is just 'one simple trick', then just update the others. If it is 80% GO, then why wouldn't the GO team just incorporate this 'whatever it is'. or- Can someone explain it to me like i'm 5 what is the big idea under the hood here.

mapcars 3y ago
We need new languages and ideas to keep developing, obviously if someone is willing to put a lots of time and effort they found existing ones lack in something. Even if the difference is only 20%. Talking specifically about Go, how much time did it take for Go team to acknowledge and make some workarounds to support generics? And this is not a new concept it exists for more than 30 years. I can not imaging Go actually developing and incorporating new things, it is a simple and "completed" language.
- kaba0 3y ago
  So what are the new ideas around V? It literally does the same thing as Go, and as you correctly recognize, Go was already thoroughly uninteresting when it came out from a PL perspective, the only remotely interesting part is its goroutines (though not even that is unique). V doesn’t even have that, so there are like 10 languages just like that with slightly different syntax.
  - amedvednikov 3y ago
    It improves on Go a lot: https://vlang.io/compare#go https://vlang.io/compare#go
    - deleted 3y ago
      [deleted]
  - mapcars 3y ago
    I don't know much about V, I was answering why new languages are a good thing in general, even if they seem very similar to another. And I don't think every new language has to have some unique feature too. You can compare almost any modern "scripting" language for example to Common Lisp and ask why they exist, but they do and they enable lots of developers just fine.
    - kaba0 3y ago
      They don’t need a unique feature, but they do need at least a unique combination of existing features — languages are as much determined by what features they have as what they don’t. But V fails to make me interested on this count as well.
agumonkey 3y ago
I stopped looking long ago but to my limited understanding, when V says it does X in 1s, it means they delegated the job to gcc faster than others doing the whole work. Either that or V author is up for a few ACM turing awards.
- delian66 3y ago
  The main claim, about V doing something in 1s, is about V compiling itself from source, on a modestly modern machine. That is mainly because of how it is organized. tcc also compiles itself fast, because of how it works, and how it is organised. That other compilers, like rustc, gcc or clang can not do it, because they have other priorities/tradeoffs, is their problem.
  - agumonkey 3y ago
    Each line is a different compiler building itself ?
    - delian66 3y ago
      Sorry, I do not understand. Each line of what?
      - agumonkey 3y ago
        In the benchmark listed on their website are they comparing how long it takes for each platform P to compile v sources or P sources ?
        delian66 3y ago
        If you mean the table under "For comparison, space and time required to build each compiler", I think, that it is about what each compiler took in time and disk space to compile itself, on the same hardware, so it is about P compiling P sources. V can not compile C or Go, Go can not compile C, and C compilers can not compile V or Go, so it can not be otherwise.
oblio 3y ago
Maybe something's changed, but, a slightly older review: https://mawfig.github.io/2022/06/18/v-lang-in-2022.html https://mawfig.github.io/2022/06/18/v-lang-in-2022.html Many of the claims were false at the start. Some were fixed, some are in the "extraordinary research needed" category.
- amedvednikov 3y ago
  None of the claims in this article are relevant now, you can try them yourself.
  - oblio 3y ago
    At this point I can run the ultimate test of new programming languages. I can test the claims in the article in 5 years. I have a 90% chance that V will no longer be active, i.e. no active development happening. I'd love to be proven wrong though, but I'll only find out in 2028.
    - amedvednikov 3y ago
      You can test them today, those are simple checker bugs that were fixed right away. We're not going anywhere :) You can check the number of commits over the last 4 years.
      - oblio 3y ago
        > We're not going anywhere :) That's what everyone says (https://ourincrediblejourney.tumblr.com/ https://ourincrediblejourney.tumblr.com/). Only time will tell. I'm not in a rush to use a new language, so as I said above, I can run the ultimate test. I can check back on V in 5 years from now, if it's still around. Good luck!
  - zamberzand 3y ago
    This is not quite true. The claims about autofree made in the article are still extremely relevant. For example, the following code from the article still leaks with autofree: [heap] struct MyHeapValue { value i64 } fn draw_text(value MyHeapValue) { } fn main() { // ... arg1 := MyHeapValue { 42 } arg2 := MyHeapValue { 100 } draw_text(arg1) draw_text(arg2) // ... } What's more, it leaks even if we completely remove the calls to draw_text and the function definition for draw_text.

mapcars 3y ago

We need new languages and ideas to keep developing, obviously if someone is willing to put a lots of time and effort they found existing ones lack in something. Even if the difference is only 20%. Talking specifically about Go, how much time did it take for Go team to acknowledge and make some workarounds to support generics? And this is not a new concept it exists for more than 30 years. I can not imaging Go actually developing and incorporating new things, it is a simple and "completed" language.

kaba0 3y ago
So what are the new ideas around V? It literally does the same thing as Go, and as you correctly recognize, Go was already thoroughly uninteresting when it came out from a PL perspective, the only remotely interesting part is its goroutines (though not even that is unique). V doesn’t even have that, so there are like 10 languages just like that with slightly different syntax.
- amedvednikov 3y ago
  It improves on Go a lot: https://vlang.io/compare#go https://vlang.io/compare#go
  - deleted 3y ago
    [deleted]
- mapcars 3y ago
  I don't know much about V, I was answering why new languages are a good thing in general, even if they seem very similar to another. And I don't think every new language has to have some unique feature too. You can compare almost any modern "scripting" language for example to Common Lisp and ask why they exist, but they do and they enable lots of developers just fine.
  - kaba0 3y ago
    They don’t need a unique feature, but they do need at least a unique combination of existing features — languages are as much determined by what features they have as what they don’t. But V fails to make me interested on this count as well.

agumonkey 3y ago

I stopped looking long ago but to my limited understanding, when V says it does X in 1s, it means they delegated the job to gcc faster than others doing the whole work. Either that or V author is up for a few ACM turing awards.

delian66 3y ago
The main claim, about V doing something in 1s, is about V compiling itself from source, on a modestly modern machine. That is mainly because of how it is organized. tcc also compiles itself fast, because of how it works, and how it is organised. That other compilers, like rustc, gcc or clang can not do it, because they have other priorities/tradeoffs, is their problem.
- agumonkey 3y ago
  Each line is a different compiler building itself ?
  - delian66 3y ago
    Sorry, I do not understand. Each line of what?
    - agumonkey 3y ago
      In the benchmark listed on their website are they comparing how long it takes for each platform P to compile v sources or P sources ?
      - delian66 3y ago
        If you mean the table under "For comparison, space and time required to build each compiler", I think, that it is about what each compiler took in time and disk space to compile itself, on the same hardware, so it is about P compiling P sources. V can not compile C or Go, Go can not compile C, and C compilers can not compile V or Go, so it can not be otherwise.

oblio 3y ago

Maybe something's changed, but, a slightly older review: https://mawfig.github.io/2022/06/18/v-lang-in-2022.html https://mawfig.github.io/2022/06/18/v-lang-in-2022.html Many of the claims were false at the start. Some were fixed, some are in the "extraordinary research needed" category.

amedvednikov 3y ago
None of the claims in this article are relevant now, you can try them yourself.
- oblio 3y ago
  At this point I can run the ultimate test of new programming languages. I can test the claims in the article in 5 years. I have a 90% chance that V will no longer be active, i.e. no active development happening. I'd love to be proven wrong though, but I'll only find out in 2028.
  - amedvednikov 3y ago
    You can test them today, those are simple checker bugs that were fixed right away. We're not going anywhere :) You can check the number of commits over the last 4 years.
    - oblio 3y ago
      > We're not going anywhere :) That's what everyone says (https://ourincrediblejourney.tumblr.com/ https://ourincrediblejourney.tumblr.com/). Only time will tell. I'm not in a rush to use a new language, so as I said above, I can run the ultimate test. I can check back on V in 5 years from now, if it's still around. Good luck!
- zamberzand 3y ago
  This is not quite true. The claims about autofree made in the article are still extremely relevant. For example, the following code from the article still leaks with autofree: [heap] struct MyHeapValue { value i64 } fn draw_text(value MyHeapValue) { } fn main() { // ... arg1 := MyHeapValue { 42 } arg2 := MyHeapValue { 100 } draw_text(arg1) draw_text(arg2) // ... } What's more, it leaks even if we completely remove the calls to draw_text and the function definition for draw_text.