This blog post showcases V in a positive light. I suppose it is good that people can have productive experiences with it now, although I don't see from this post why it is a significant improvement on Go.

The problems discussed (performance, compiler fragility) are somewhat worrying though. My impression is still that V is not particularly robust and focuses on flashy things instead of getting the basics right. I must admit that it is however still hard to look at V objectively, given the near-fradulent presentation it had when it was first announced.

    x := []&int { len: 10, cap: 0 }; println(x[4])

When comparing V and Golang, I feel like V serves as a warning for why the Go maintainers say "No" so often. You can see the author being weirdly confused both by bugs and ambiguity in the language.

> This is a double-edged sword, with Go, you get what you got. With V, I got what I got but I wonder if what I got can be gotten differently.

I have used both Go (extensively) and V (not so much). Go's cross compilation, concurrency support, GC & stability are much better than V's. V compiles much much faster in spite of generating C (unless you use clang), plays better with C, its syntax choices seem better (default to const, less onerous error handling, sum types, option type, not relying on Capitalization for exporting etc.), optional GC (though far from perfect), etc. I can see writing an OS in V (but not in Go). I am in two minds about whether it should try to simulate concurrency like Go does (goroutines are coroutines, mapped to system threads only for blocking syscalls) as that might not be the right choice for kernel level code.

V hasn't had the resources or backing that Go continues getting. Most of its work is done by volunteers. AFAIK it hasn't had the benefit of the experience of multiple world class programmers like Go's designers. Good language design also involves leaving out features and that involves discussing or experimenting with such features. IMHO V can use more of that. But so far I like a lot of what I see in V.

This is interesting. It's good to read up-to-date impressions of V, considering its shaky beginnings. This describes a more positive experience from mine about a year ago, which is a good sign. I remember running into similar weird errors and undefined behavior, which really put me off from the language.

The problems that V is trying to solve aren't something I find to be dealbreakers with Go. I'm fine with Go's syntax, error handling, lack of bells and whistles, enums, and so on. In fact, I've learned to appreciate the brutalist simplicity of its design. What I do need is a language that is robust, well defined according to its specification, and performs well at most tasks. Go excels at these, while V fumbles at all of them.

How much longer can we excuse these issues on account of it being a young language? V is 6 years old now, yet these issues still exist. The authors and community seem to prioritize writing text editors, kernels, and operating systems over addressing these core issues. And, frankly, I don't trust that things will improve with the current leadership, so I'll continue to stay away and write boring Go code.

I am of two minds on V

On one hand, I think there needs to be an applications programming language that's both fast, statically typed, and minimalistic (like C). C# and Java are unwieldy and carry too much baggage. I hoped Go would be that language. Unfortunately Go's weird choice to use green threads and channels made it very difficult and slow to interop with native code, especially desktop frameworks, which usually rely on a pumped message loop. V was supposed to be that language, that keeps the excellent syntax, but replaces much of the weirdness with much more convenient stuff, while adding a few extra features.

I first learned of V after reading the hit piece someone wrote on it, which has formed the majority of people's opinion's on the language. Back then I though most of the criticisms were unnecessarily harsh and belligerent, most of it boiling down to the compiler/stdlib having bugs, and one asserting that it's 'autofree' implementation leaked memory, based on an incorrect understanding of how valgrind and C memory management works.

I decided to get the truth for myself, and delve into the V language source code (after all, it's up on github). Oh boy.

- The 'compiler' itself doesn't seem to have a a codegen backend, it just produces C code, with every code generation call essentially becoming a stringbuilder concat pushing C code into a buffer. So it's more of a transpiler than a compiler.

- The compiler's code is very worrying - commented out snippets of code, TODOs like 'TODO: this isn't supposed to be null here' over a stray if statement

- The vaunted 'autofree' which (to be fair never claimed to be 100% effective, relying on GC for cases it can't figure out) is just checking objects allocated in the function scope, and frees them at the end of scope. (to be fair, autofree seems to have been deprioritised)

https://github.com/vlang/v/blob/master/vlib/v/gen/c/autofree...

While it works in some cases (including the original critical post where it claimed to fail), and I don't pretend to understand all the nuances of the compiler, I feel like the engineering behind this project is somewhat unsound.

It's super impressive just how much stuff they managed to do over the past few years, and I think a simple and pragmatic desktop language (that produces small binaries, has few dependencies and is easy to write and read) is still needed, I'm kinda reluctant to give V that role until the engineering behind it becomes more solid.

The author's github activity shows far fewer contributions compared to previous years, looks like a bad sign, anyone know what's happing?

I am actually more interested in removing/reducing even more features from Go than adding more features.

In my opinion (!) vlang is one of the most terrible language experiments ever. Everyone, and definitely the Go team, should say ; yeah let's not.

(!) it is my opinion, I am going from robust principles and foundations; that's not everyone

I fail to understand why every single new language tries to be "funny". Lets take a look at this example:

module main

struct Language { pub mut: score int = -1 name string @[required] }

fn (lr []Language) total() int { mut total := 0 for l in lr { if l.score > 0 { total += l.score } }

return total }

fn (lr []Language) average() int { return lr.total() / lr.len }

fn main() { racket := Language{98, 'racket'} // Simple arrays too! langs_arr := [racket, Language{102, 'ocaml'}] println(langs_arr) println(langs_arr.total()) println(langs_arr.average()) }

Remove

1. Whatever this is "fn (lr []Language) total() int {", why is there an ability to define a special function to an array? How do I know what overload is being used? If I change something from map to vector, how do I know there's nothing else that changes? Member function is just a sugar over regular functions? Great, remove member functions.

2. Why allow this? "racket := Language{98, 'racket'}" ? Why implicitly depend on ordering of parameter? Just use Language { .score = 98, .name = "racket", } Confusing order of evaluation? Great, just force it to be assigned exactly the same as the definition and force ordering that way.

3. Why remove the parenthesises " if l.score > 0 {"? In fact, I would even reject code that assumes any integer != 0 is True. Nope, you have to do the exact check every time. No more if (x) { }

4. Why allow default parameter? Why needing special syntax for @required?

I just want a very limited C with GC, pattern matching and algebraic data types. I don't even need generics.

[flagged]

[flagged]