5 ms·

V 0.3

25 points by pro100den228 4y ago

catchclose8919 4y ago
this looks too good to be true! ...what gives? what compromises have you made to achieve so much so fast? (or who's throwing $$$ at you?)
lausek 4y ago
> Programs built with the V compiler no longer leak memory by default. What?
- steeleduncan 4y ago
  I think it refers to the memory leak section of this https://xeiaso.net/blog/v-vaporware-2019-06-23 https://xeiaso.net/blog/v-vaporware-2019-06-23
- AlbertoGP 4y ago
  In addition to steeleduncan’s sibling comment, you can find more details in this bug report from 2021-03-16 that was closed as a wontfix: https://github.com/vlang/v/issues/9327 https://github.com/vlang/v/issues/9327 At the end of the thread, medvednikov wrote this just before closing the issue: > “Zero leaks when using autofree which will become the default in 0.3:” I guess they did make autofree enabled by default in this release. If they did not fix that issue it means that you still can not get leak-free programs with manual memory management, which contradicts my understanding of their claim: > “For developers willing to have more low level control, autofree can be disabled with -manualfree, or by adding a [manualfree] on each function that wants manage its memory manually.” > https://github.com/vlang/v/blob/master/doc/docs.md#control https://github.com/vlang/v/blob/master/doc/docs.md#control You can disable autofree, but then you can not have a leak-free program no matter what you do. Now, that leak is at the end of its execution so it’s not a problem when using the program, but it is when developing it as those leaks will obscure any other that you might be trying to remove, or even notice.
  - amedvednikov 4y ago
    Not sure what you mean. There are no leaks by default now. If you want manual memory management, you can do that. What's the problem? And hello world hasn't been leaking for a while now, it was just an unfreed global const. The issue you referenced, wasn't closed as a wontfix. It was closed because it was fixed.
    - AlbertoGP 4y ago
      I mean what it would be nice to have no forced leaks also when using the -manualfree command line option. However, I just checked, and the 0.3 release does leak even without -manualfree! lxc launch images:debian/bullseye test-v lxc exec test-v bash # Inside the container: apt install build-essential git valgrind git clone https://github.com/vlang/v cd v git rev-parse HEAD # 74bb5ae17a4a0af8dda913ddb1ca9d8d4a590136 make # ... # Your `tcc` is working. Good - it is much faster at compiling C source code. # V has been successfully built # V 0.3.0 74bb5ae ./v examples/hello_world.v valgrind --leak-check=yes examples/hello_world # ... report about invalid read of size 1. # ... reports about uninitialized values. # ==5750== LEAK SUMMARY: # ==5750== definitely lost: 0 bytes in 0 blocks # ==5750== indirectly lost: 0 bytes in 0 blocks # ==5750== possibly lost: 1,360 bytes in 5 blocks # ==5750== still reachable: 0 bytes in 0 blocks # ==5750== suppressed: 0 bytes in 0 blocks # ... # ==5750== ERROR SUMMARY: 144 errors from 17 contexts (suppressed: 0 from 0) I checked also with the 0.3 release: https://github.com/vlang/v/releases/tag/0.3 https://github.com/vlang/v/releases/tag/0.3 apt install wget unzip rm v -r wget https://github.com/vlang/v/releases/download/0.3/v_linux.zip sha1sum v_linux.zip # bb6f81630fe2ae4e7e283360f507be99f88f32bd v_linux.zip unzip v_linux.zip cd v ./v examples/hello_world.v valgrind --leak-check=yes examples/hello_world # Exact same result as above, just a different PID of course. Am I missing something?
      - amedvednikov 4y ago
        I can't reproduce this. No leaks in valgrind for me.
      - 4y ago
nudpiedo 4y ago
The list of features looks incredible, I would say it's everything RUST wanted to be but never could... however Rust hot Linus Torvalds' support and made it into the kernel. I have yet to check whether function completeness is mandatory for V's match on sum types.
davidatbu 4y ago
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.

25 points by pro100den228 4y ago

this looks too good to be true! ...what gives? what compromises have you made to achieve so much so fast? (or who's throwing $$$ at you?)

lausek 4y ago

> Programs built with the V compiler no longer leak memory by default. What?

steeleduncan 4y ago
I think it refers to the memory leak section of this https://xeiaso.net/blog/v-vaporware-2019-06-23 https://xeiaso.net/blog/v-vaporware-2019-06-23
AlbertoGP 4y ago
In addition to steeleduncan’s sibling comment, you can find more details in this bug report from 2021-03-16 that was closed as a wontfix: https://github.com/vlang/v/issues/9327 https://github.com/vlang/v/issues/9327 At the end of the thread, medvednikov wrote this just before closing the issue: > “Zero leaks when using autofree which will become the default in 0.3:” I guess they did make autofree enabled by default in this release. If they did not fix that issue it means that you still can not get leak-free programs with manual memory management, which contradicts my understanding of their claim: > “For developers willing to have more low level control, autofree can be disabled with -manualfree, or by adding a [manualfree] on each function that wants manage its memory manually.” > https://github.com/vlang/v/blob/master/doc/docs.md#control https://github.com/vlang/v/blob/master/doc/docs.md#control You can disable autofree, but then you can not have a leak-free program no matter what you do. Now, that leak is at the end of its execution so it’s not a problem when using the program, but it is when developing it as those leaks will obscure any other that you might be trying to remove, or even notice.
- amedvednikov 4y ago
  Not sure what you mean. There are no leaks by default now. If you want manual memory management, you can do that. What's the problem? And hello world hasn't been leaking for a while now, it was just an unfreed global const. The issue you referenced, wasn't closed as a wontfix. It was closed because it was fixed.
  - AlbertoGP 4y ago
    I mean what it would be nice to have no forced leaks also when using the -manualfree command line option. However, I just checked, and the 0.3 release does leak even without -manualfree! lxc launch images:debian/bullseye test-v lxc exec test-v bash # Inside the container: apt install build-essential git valgrind git clone https://github.com/vlang/v cd v git rev-parse HEAD # 74bb5ae17a4a0af8dda913ddb1ca9d8d4a590136 make # ... # Your `tcc` is working. Good - it is much faster at compiling C source code. # V has been successfully built # V 0.3.0 74bb5ae ./v examples/hello_world.v valgrind --leak-check=yes examples/hello_world # ... report about invalid read of size 1. # ... reports about uninitialized values. # ==5750== LEAK SUMMARY: # ==5750== definitely lost: 0 bytes in 0 blocks # ==5750== indirectly lost: 0 bytes in 0 blocks # ==5750== possibly lost: 1,360 bytes in 5 blocks # ==5750== still reachable: 0 bytes in 0 blocks # ==5750== suppressed: 0 bytes in 0 blocks # ... # ==5750== ERROR SUMMARY: 144 errors from 17 contexts (suppressed: 0 from 0) I checked also with the 0.3 release: https://github.com/vlang/v/releases/tag/0.3 https://github.com/vlang/v/releases/tag/0.3 apt install wget unzip rm v -r wget https://github.com/vlang/v/releases/download/0.3/v_linux.zip sha1sum v_linux.zip # bb6f81630fe2ae4e7e283360f507be99f88f32bd v_linux.zip unzip v_linux.zip cd v ./v examples/hello_world.v valgrind --leak-check=yes examples/hello_world # Exact same result as above, just a different PID of course. Am I missing something?
    - amedvednikov 4y ago
      I can't reproduce this. No leaks in valgrind for me.
    - 4y ago

nudpiedo 4y ago

The list of features looks incredible, I would say it's everything RUST wanted to be but never could... however Rust hot Linus Torvalds' support and made it into the kernel. I have yet to check whether function completeness is mandatory for V's match on sum types.

davidatbu 4y ago

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.