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 unsaf

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.