Author of the language here.<p>Very excited about this release.<p>This is the first major release after 0.1.<p>The focus has been on stability and compile-time memory management. The demo of that was posted here recently [0].<p>7600 commits, 4110 handled pull requests, 340 contributors, 20k GitHub stars. What a journey!<p>[0]: <a href="https://www.youtube.com/watch?v=gmB8ea8uLsM" rel="nofollow">https://www.youtube.com/watch?v=gmB8ea8uLsM</a>
The controversy around V is not without reason.<p>For some context here’s the last of a series of posts examining some of Vs claims <a href="https://christine.website/blog/vlang-update-2020-06-17" rel="nofollow">https://christine.website/blog/vlang-update-2020-06-17</a>
I mean this without snideness, but I’m constantly amazed at the demand for C-like languages that continue to arrive with every possible combination of features. When I look at V code, it looks barely different than the plethora of options syntactically and semantically. To be sure, it is different, and I get that a lot of programmers find the “no BS minimalism” aspect appealing. (A lot if programmers in fact start a rewrite project with “no BS minimalism”, only to asymptotically recreate the ‘BS’ and destroy the ‘minimalism’.) But I can’t imagine anything being vastly different than any of the other C-likes once your project is big enough, except that V is currently nascent and changing.<p>I remember eC [1, 2] from Ecere being one such example of an “exciting new C”: it had traditional class-based OO, no header files (!), cross platform, reflection, etc etc etc. It came with a huge runtime library with tons of demos. It started 16 years ago (!!). There’s of course D as well (which is more often pitched as a C++ replacement), and its own Walter Bright frequently seen around here, and some companies use it, but it hasn’t truly exploded into mainstream use.<p>Can interested folks (or the author) comment? Are you bored and want a fun new take on programming? Or are you truly, in practice, extremely dissatisfied with the current marketplace of C alternatives and V <i>actually</i> is a take that “gets things right”?<p>[1] <a href="https://en.m.wikipedia.org/wiki/EC_(programming_language)" rel="nofollow">https://en.m.wikipedia.org/wiki/EC_(programming_language)</a><p>[2] <a href="https://ec-lang.org/overview/" rel="nofollow">https://ec-lang.org/overview/</a>
Congrats to V on implementing the compile time memory management technique from <a href="http://aardappel.github.io/lobster/memory_management.html" rel="nofollow">http://aardappel.github.io/lobster/memory_management.html</a>, like you mentioned on Discord.<p>Would be nice if you would credit it, though.
From: <a href="https://vlang.io/compare#go" rel="nofollow">https://vlang.io/compare#go</a><p>- No null<p>- No err != nil checks (replaced by option types)<p>- Immutability by default<p>- Generics<p>- Sum types (type Expr = IfExpr | StringLiteral | IntLiteral )<p>- If and match expressions (including sum type matches)<p>This might be my personal project goto language for 2021.
I remember from first publications about V lang that felt like a hoax: reams of exciting promises and basically nothing to show for them.'<p>It's great to see that it's not s hoax, and it starts to somehow flesh out.
The language is a fantastic one. I can understand the author putting every library/language/package-manager/examples in V together and trying to bring out a wonderful experience out of a language, but wouldn't it be better if the memory manager is fixed first and foremost.<p>At the moment its still incomplete. And this is the most interesting part of the whole language. ARC, weak refs, autofree also working together needs to be done, only then will this language be of weight. Garbage collection is a difficult problem to be fair and it definitely determines the performance of many languages. Not to mention multi-threaded GC is difficult. I am excited to see how the author pulls this one through. See you again with V 0.3. Till then best of luck!
Code sample on the landing page would be nice.<p>Here is Tetris in V:<p><a href="https://github.com/vlang/v/blob/master/examples/tetris/tetris.v" rel="nofollow">https://github.com/vlang/v/blob/master/examples/tetris/tetri...</a>
They claim:<p>> Pure functions by default<p>but all this means by their definition is: no global mutable variables, sort of, because you can enable them per compiler flag.
Thank you for creating V, you're amazing. There's not many people that could do what you did - both from a technical perspective and from a mental perspective. I feel like you get a lot of hate from jealous haters that can't even fathom having the required mental energy to keep going at such a hard problem, for such a long time, keeping the flame alive. Fuck'em, keep rocking!
Very interesting release. The autorelease is especially noteworthy... also I worry how hard it would be to have more finegrained control over allocations, releasing the memory instantly is not always the most perfomant way. In games for example big (temporary) allocations are often performed in some kind of arena buffer that gets cleared at the end of a frame (NativeArray in Unity does this) and thereby circumvents alot of unnecessary deallocating. How feasible would it be to implement such an allocator in V without losing the autorelease for the other cases?
This language looks very nice, I have been keeping an eye on it. From what I remember there were some issues around memory management without gc, specifically because there were mutable, reference types and multithreading. How does it manage memory? Does it use something like ref counting? Is there any documentation around it?
You can say what you want about this project, but reality is that this is an active open source project. Look at those GitHub stats ... more than 300 contributors, 4000 pull requests.<p>Maybe this project had a rough start, but right now anyone claiming this is not real should probably re-evaluate those feelings.
So this is a safer alternative to Golang with smaller binaries, generics and no GC?<p>[edit] Sorry, edited before there was a reply. You're very fast!
built-in ORM is really compelling actually<p>it implies the presence of other nice-to-haves, like ergonomic struct iteration and linting against schema<p>and it gracefully enables low-code API frameworks if you can annotate RBAC + visibility rules
One thing V gets right is not requiring a keyword (e.g. “let”) for initializing an immutable variable. This is such a common operation that it should be as compact and non-visual-noisy as possible (Huffman coding). (Personally I’d go for “=“ instead of “:=“ though, for ease of typing.)