[mawfig]

Thanks for linking Xe's blog here! It's a few years old and I've seen a lot of comments on HN that suggest V has improved significantly since 2019 so I thought it might be worth looking into for myself and writing down a review of what I found.

[prirun]

I'm always interested in new languages and loved your write-up & evaluation of V.

I really don't get the purpose of someone exaggerating the capabilities of their language, to the point of outright lies.

[dkjaudyeqooe]

I think people think that's "marketing".

[rurban]

Unfortunately that's needed nowadays to succeed. Java, Rust and many other would not be successful without standing on the shoulders of its big lies

[creata]

What lies did the Rust developers make?

(Also, "nowadays" must stretch out to many decades if you're including Java!)

[rurban]

The three securities they guarantee and cannot hold.

Fearless concurrency.

Java also promised memory safety. I still get Null pointer segfaults in Java code.

[agluszak]

> The three securities they guarantee and cannot hold. Could you elaborate?

> null pointer segfaults They are not segfaults and are not related to memory safety. Segfault stands for "segmentation fault", not "runtime exception". https://en.m.wikipedia.org/wiki/Segmentation_fault

[thayne]

If you know of a case where rust code violates memory safety without the use of an unsafe block, file a bug and it will probably be fixed within a release or two.

"Fearless concurrency" is more subjective, but rust code (again with the caveat that there isn't unsafe code, or unsafe cose upholds all unvariants) dows eliminate certain classes of concurrency bugs. Although, dreadlocks are definitely possible, and certain kinds of race conditions could potentially exist. But I don't know of any claims that concurrency bugs are impossible in rust.

[rurban]

do you your self a favor and search their ticket system for stack overflow. the list gets longer, not smaller.

and looking at their compiler it's clear why. stack-allocation of vars is fine and dandy, but comparable to vlang's famous unbounded autofree system. alloca() is dangerous for a reason.

unsafe vec, really?? mutexes in threads, really?? concurrent blocking IO in this decade??

also read their docs about their unsafeties, and concurrency deficiencies. compare that to the docs of real safe languages. you won't find such chapters, because safe languages are safe, not just almost-safe.

[seebs]

Someone pointed out an obvious one: You can open the file "/dev/mem" or equivalent on many Unix systems and break things horribly, and rust can't tell that you're doing it or stop you. Someone used this to write an unsafe-free transmute, which is probably at least two different war crimes.

I doubt the rust team will try to "fix" that.

[rad_gruchalski]

You most likely get NPEs, not segfaults. I have never seen a segfault in Java and the first Java version I used was 1.5.

[davidkunz]

The marketing sentence "A language empowering everyone to build reliable and efficient software." is not true.