If OCaml, Rust doesn't have weirdly sized number types and has a decent library ecosystem.

If Haskell, you don't need to understand monads to write hello world.

If Scala, you don't need to deploy a JVM with your app.

If F#, you have traits which are super useful and you aren't fighting against MS's refusal to invest in the nicest language in the .Net ecosystem.

Even without "lifetime tracking" and liberal use of Clone, you can still outperform most programs written in any of the above languages.

The V project should feel free to pull any bug reports they want out of my blog post (I see they've already done so multiple times). From the votes on the comment section here, I can it's obvious to everyone how dysfunctional the V community is which explains a lot about the state of the project. I will not be interacting with you again.

Alex, all of these are still open right not and are not fixed:

- "No mut m := x mutability check" https://github.com/vlang/v/issues/14803

- "closure capture names are not checked for uniqueness with the closure parameter names" https://github.com/vlang/v/issues/14787

- "segfault in auto string method generated for []&int{len:1} (does not check for 0 pointers)" https://github.com/vlang/v/issues/14786

> using -prod for measuring compiler speed

My article does not do that. I included all the steps used and the 1,000,000 line tests use tcc and not -prod.

> And nonsense like setting array length on creation is a terrible idea. Go with its `make([]int, 5)` must be a terrible scam language as well.

V allows the user to override length field which is used in bounds-checking with no validation. That's the problem.

Please stop lying and just be honest about the state of V.

Given the behavior of you, Tozen and ylluminate on this thread, I have zero interest in interacting with the V "community" again.

https://ocaml.org/docs/functional-programming

"V functions are pure by default, meaning that their return values are a function of their arguments only, and their evaluation has no side effects (besides I/O)."

https://github.com/vlang/v/blob/master/doc/docs.md#pure-func...

It sure sounds to me like V is trying to claim that functions can be pure while still performing I/O.

> Features indicated to be incomplete/work in progress/unimplemented will be mentioned as such.

Indicating on the vlang.io homepage how much of the language has yet to be realized would go a long way in my opinion.

Instead of insinuating I'm some kind of competitor or have a personal agenda, I would encourage you to respond to the actual points raised in my post.

Would you mind expanding on your later comment? While I'm not a Go programmer, it's pretty easy for me to see why it has the features it has based on their commitment to fast compile times and being easy to learn. V on the other hand feels like an incoherent list of the biggest buzzwords in the industry right now with no clear overall design.

Comments URL: https://news.ycombinator.com/item?id=31793554

Points: 297

# Comments: 298