[Rochus]

Thanks for the link; that's going in the direction I was looking for. So could one say that V is essentially the Go the author would have wanted, and the new language is justified by the "~20%" difference, and an independent development is necessary due to the slow pace at which Go is evolving? So that would be a similar motivation as Nim versus Python, or Oberon+ versus Oberon.

The feature differences in list form are helpful; but the priorities and motivation for individual features would also be interesting; e.g. why is "variable shadowing" bad and why is the V approach better, and how can smaller runtime and binaries smaller by a factor of 100 be achieved with a feature set that is at least 80% the same as Go? Does this really have to do with the language definition, or rather with the implementation?

[amedvednikov]

I created V because Go didn't work nicely with C for my project.

So just that would be enough for me to use V.

Variable shadowing makes code more bug prone and confusing.

As for the size: V uses system's official API (libc), including networking. Go has their own libs that have to be statically linked in to the binary.