4 ms·

Do the referenced compile times also include the time to compile from C to machine code (IIUC, V compiles to C)? If so, it's incredible to me that this set of

Do the referenced compile times also include the time to compile from C to machine code (IIUC, V compiles to C)? If so, it's incredible to me that this set of tradeoffs (which appear almost as ergonomic as Rust at first glance) can be had while keeping compile times this small! At first glance, the thing I see as "missing" when comparing this to Rust is traits (or some form of inheritance). The memory management uses a combo of compile-time checking and reference counting by default, so that may take some of the predictability away. But I mean, this looks like something I'd at least consider for everything except for incredibly perf-sensitive code, (ignoring the network effect of an active dev community, in ML or, frontend ..etc). EDIT: I recommend you, reader, look at my convo with a maintainer of V below, because I revise my attitude to Vlang due to (IMO) its too-immature nature.

theamk 4y ago
That language looks so good because some of the claims are exaggerated, a lot.. Here is a review of previous version: https://news.ycombinator.com/item?id=31793554 https://news.ycombinator.com/item?id=31793554
- gompertz 4y ago
  Keyword: previous version. If you scroll down in thread, it's stated that all issues raised in the blog have been fixed. Side note: Github has an issues section on every project which is a better medium.
  - theamk 4y ago
    I don't think so? let's do the first claim in that blog, "No null" First, does V still claims no nulls? Yep, the release notes say: "Null can be used in unsafe only (for example, for C interop)." let's test it: \ \ / / | Welcome to the V REPL (for help with V itself, type exit , then run v help ). \ \/ / | Note: the REPL is highly experimental. For best V experience, use a text editor, \ / | save your code in a main.v file and execute: v run main.v \ / | V 0.3.0 ec75860 . Use list to see the accumulated program so far. \__/ | Use Ctrl-C or exit to exit, or help to see other available commands. >>> a := []&int { len: 1 } >>> println(a) [nil] >>> c := a[0] >>> c &nil Yep, here is the null (called "nil" here). And no "unsafe" blocks anywhere. Let's do another one.. how about "undefined behavior"? Let's try dangling pointer... root@7e7c471e6225:/v# cat >> test2.v struct Something { val int } fn main() { x := voidptr(123) y := &Something(x) println(y) } root@7e7c471e6225:/v# ./v run test2.v signal 11: segmentation fault /tmp/v_0/test2.14581707097346933317.tmp.c:7071: at print_backtrace: Backtrace /tmp/v_0/test2.14581707097346933317.tmp.c:7142: by v_segmentation_fault_handler 7fbb67436090 : by ??? /tmp/v_0/test2.14581707097346933317.tmp.c:12468: by main nope, not all issues have been fixed. My random sample showed some of them are still there.
amedvednikov 4y ago
> Do the referenced compile times also include the time to compile from C to machine code Of course.
- davidatbu 4y ago
  I believe you're either the creator or a maintainer of V. Thank you for your open source efforts! This is my first time running across V, and it looks like the HN community generally considers Vlang's claims misleading. I found a factual (IMO) evaluation of Vlang's claims here: https://mawfig.github.io/2022/06/18/v-lang-in-2022.html#summary https://mawfig.github.io/2022/06/18/v-lang-in-2022.html#summ... . I've tried looking at your replies on the HN thread that discusses it, and what I gathered is that almost all of the deficiencies in that analysis are factually correct, but will be corrected in future, non-alpha, versions of Vlang. Is that impression correct? If not, is there a centralized place where you debunk the claims? (I understand you're an open source contributor and might not have the time, but I'm just letting you know that I won't engage with the language further without seeing something like that). If my impression was correct, I would like to say that I concur with the general HN sentiment that the state of the language is so immature/alpha as to really cast doubt on whether the list of claimed features will actually be achieved at some point in the future.
  - amedvednikov 4y ago
    All issues mentioned in this anonymous attack blog have already been fixed. It'd be much faster for the author to submit a couple of github issues, they are fixed very quickly. The state of the language is anything but immature, all claimed features on the website are very carefully worded, and are all achieved already.
    - davidatbu 4y ago
      I'll be honest: my decision is that I will come back to Vlang after (at least) six months, and hope that someone does a similar analysis, or do that analysis myself, and then reconsider. Basically, if the author of that blog posts found (IMO) straightforward ways to invalidate Vlang's claims in ~1 month with the language, I suspect that I will also find _other_ ways to also invalidate Vlang's claims in a straightforward manner. While that's fine for an alpha stage language that I would contribute to, I currently don't have the interest/ability/bandwidth to contribute to a compiler project. Also, I would like to recommend that you add language to the home page and the Github to the effect of: "Vlang is currently in alpha, and you might discover bugs that contradict some of the claims below. Since this is a WIP project, please contribute!" I literally couldn't Ctrl-F and find the word alpha. Again, thank you very much for your open source efforts! Btw, Volt's MacOS app doesn't work (neither the M1 version, nor the Intel). It just displays a blank white page.
nudpiedo 4y ago
you should check the video where they translate doom source to V and compile it[1], almost flawless... the C2V is just a few days old feature, and it is incredible how well works. The more I read about V the more I cannot believe it. [1] https://www.youtube.com/watch?v=6oXrz3oRoEg https://www.youtube.com/watch?v=6oXrz3oRoEg
- amedvednikov 4y ago
  Thanks! Glad you like it :) We're really proud of C2V and DOOM.v.
- vlang1dot0 4y ago
  They've been working on C2V for a long time now and even still it falls over quickly for anything other than the exact version of doom they are using. Multiline comments crash the tool for instance.
  - amedvednikov 4y ago
    Complete lies. DOOM is full of multiline comments. And we have a bunch of non DOOM tests.
  - dang 4y ago
    I don't know what the story behind your account is, but it looks like you've been posting mostly in threads on this one topic for a couple years now. That's not cool on HN, regardless of how good or bad you feel a programming language is. (I noticed that you've also posted a few comments about other languages, like Rust and C++, but they're a minority of your posts, and unfortunately quite a few have been flamewar comments too - which is not what this site is for.) HN is for intellectually curious, respectful conversation on topics that interest you. Since agenda-driven or single-purpose accounts aren't compatible with that, we don't allow them here. We also don't allow trollish usernames (see https://hn.algolia.com/?sort=byDate&dateRange=all&type=comment&storyText=false&prefix=true&page=0&query=by:dang%20trollish%20username https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...), which given the account history, this looks like. I've banned the account for that reason, but if you want to pick a different username, we'd be happy to rename it and unban it. hn@ycombinator.com is the best place to let us know what username you'd prefer. It would be good to review https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and make sure you're down with using HN as intended, too.
kaba0 4y ago
> But I mean, this looks like something I'd at least consider for everything except for incredibly perf-sensitive code, Which is true of nowadays of the majority of languages very much including managed languages in the pack.

theamk 4y ago

That language looks so good because some of the claims are exaggerated, a lot.. Here is a review of previous version: https://news.ycombinator.com/item?id=31793554 https://news.ycombinator.com/item?id=31793554

gompertz 4y ago
Keyword: previous version. If you scroll down in thread, it's stated that all issues raised in the blog have been fixed. Side note: Github has an issues section on every project which is a better medium.
- theamk 4y ago
  I don't think so? let's do the first claim in that blog, "No null" First, does V still claims no nulls? Yep, the release notes say: "Null can be used in unsafe only (for example, for C interop)." let's test it: \ \ / / | Welcome to the V REPL (for help with V itself, type exit , then run v help ). \ \/ / | Note: the REPL is highly experimental. For best V experience, use a text editor, \ / | save your code in a main.v file and execute: v run main.v \ / | V 0.3.0 ec75860 . Use list to see the accumulated program so far. \__/ | Use Ctrl-C or exit to exit, or help to see other available commands. >>> a := []&int { len: 1 } >>> println(a) [nil] >>> c := a[0] >>> c &nil Yep, here is the null (called "nil" here). And no "unsafe" blocks anywhere. Let's do another one.. how about "undefined behavior"? Let's try dangling pointer... root@7e7c471e6225:/v# cat >> test2.v struct Something { val int } fn main() { x := voidptr(123) y := &Something(x) println(y) } root@7e7c471e6225:/v# ./v run test2.v signal 11: segmentation fault /tmp/v_0/test2.14581707097346933317.tmp.c:7071: at print_backtrace: Backtrace /tmp/v_0/test2.14581707097346933317.tmp.c:7142: by v_segmentation_fault_handler 7fbb67436090 : by ??? /tmp/v_0/test2.14581707097346933317.tmp.c:12468: by main nope, not all issues have been fixed. My random sample showed some of them are still there.

amedvednikov 4y ago

> Do the referenced compile times also include the time to compile from C to machine code Of course.

davidatbu 4y ago
I believe you're either the creator or a maintainer of V. Thank you for your open source efforts! This is my first time running across V, and it looks like the HN community generally considers Vlang's claims misleading. I found a factual (IMO) evaluation of Vlang's claims here: https://mawfig.github.io/2022/06/18/v-lang-in-2022.html#summary https://mawfig.github.io/2022/06/18/v-lang-in-2022.html#summ... . I've tried looking at your replies on the HN thread that discusses it, and what I gathered is that almost all of the deficiencies in that analysis are factually correct, but will be corrected in future, non-alpha, versions of Vlang. Is that impression correct? If not, is there a centralized place where you debunk the claims? (I understand you're an open source contributor and might not have the time, but I'm just letting you know that I won't engage with the language further without seeing something like that). If my impression was correct, I would like to say that I concur with the general HN sentiment that the state of the language is so immature/alpha as to really cast doubt on whether the list of claimed features will actually be achieved at some point in the future.
- amedvednikov 4y ago
  All issues mentioned in this anonymous attack blog have already been fixed. It'd be much faster for the author to submit a couple of github issues, they are fixed very quickly. The state of the language is anything but immature, all claimed features on the website are very carefully worded, and are all achieved already.
  - davidatbu 4y ago
    I'll be honest: my decision is that I will come back to Vlang after (at least) six months, and hope that someone does a similar analysis, or do that analysis myself, and then reconsider. Basically, if the author of that blog posts found (IMO) straightforward ways to invalidate Vlang's claims in ~1 month with the language, I suspect that I will also find _other_ ways to also invalidate Vlang's claims in a straightforward manner. While that's fine for an alpha stage language that I would contribute to, I currently don't have the interest/ability/bandwidth to contribute to a compiler project. Also, I would like to recommend that you add language to the home page and the Github to the effect of: "Vlang is currently in alpha, and you might discover bugs that contradict some of the claims below. Since this is a WIP project, please contribute!" I literally couldn't Ctrl-F and find the word alpha. Again, thank you very much for your open source efforts! Btw, Volt's MacOS app doesn't work (neither the M1 version, nor the Intel). It just displays a blank white page.

nudpiedo 4y ago

you should check the video where they translate doom source to V and compile it[1], almost flawless... the C2V is just a few days old feature, and it is incredible how well works. The more I read about V the more I cannot believe it. [1] https://www.youtube.com/watch?v=6oXrz3oRoEg https://www.youtube.com/watch?v=6oXrz3oRoEg

amedvednikov 4y ago
Thanks! Glad you like it :) We're really proud of C2V and DOOM.v.
vlang1dot0 4y ago
They've been working on C2V for a long time now and even still it falls over quickly for anything other than the exact version of doom they are using. Multiline comments crash the tool for instance.
- amedvednikov 4y ago
  Complete lies. DOOM is full of multiline comments. And we have a bunch of non DOOM tests.
- dang 4y ago
  I don't know what the story behind your account is, but it looks like you've been posting mostly in threads on this one topic for a couple years now. That's not cool on HN, regardless of how good or bad you feel a programming language is. (I noticed that you've also posted a few comments about other languages, like Rust and C++, but they're a minority of your posts, and unfortunately quite a few have been flamewar comments too - which is not what this site is for.) HN is for intellectually curious, respectful conversation on topics that interest you. Since agenda-driven or single-purpose accounts aren't compatible with that, we don't allow them here. We also don't allow trollish usernames (see https://hn.algolia.com/?sort=byDate&dateRange=all&type=comment&storyText=false&prefix=true&page=0&query=by:dang%20trollish%20username https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...), which given the account history, this looks like. I've banned the account for that reason, but if you want to pick a different username, we'd be happy to rename it and unban it. hn@ycombinator.com is the best place to let us know what username you'd prefer. It would be good to review https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and make sure you're down with using HN as intended, too.

kaba0 4y ago

> But I mean, this looks like something I'd at least consider for everything except for incredibly perf-sensitive code, Which is true of nowadays of the majority of languages very much including managed languages in the pack.