back
159 comments
Author of the language here.

Very excited about this release.

This is the first major release after 0.1.

The focus has been on stability and compile-time memory management. The demo of that was posted here recently [0].

7600 commits, 4110 handled pull requests, 340 contributors, 20k GitHub stars. What a journey!

[0]: https://www.youtube.com/watch?v=gmB8ea8uLsM

Congrats on releasing V v0.2! It's a great language and the compile times are amazing. My only issue is keeping up with the constantly changing vlib.

Do you have any plans to resume working on Volt (the original V app)? I thought the idea behind it was great, but there hasn't been an update in 1.5 years.

Have you given any thought to choosing a longer name for the lang? I really hate single letter identifiers. By going to 2 symbols you reduce term overloading by ~35x on average, ~3 you get 1,000x less namespace conflicts.

Though I guess "VLang" works.

Hi. How is cyclic references handled? One of the maintainers said it would be removed and made not possible.

Also garbage collection. What are you doing for that? ARC?

Congratulations on the release! It looks very interesting. Does the GUI library embed a web-view, or does it use native controls? What's you estimate of when it will be available for Android and iOS?
It definitely looks like good progress. You mentioned that DirectX and Metal support have been added; I'm curious why platform-specific APIs were prioritized over Vulkan. Were they actively prioritized for some reason, or did contributors just work on those first?
What is v’s take on inheritance / traits / mixin
Поздравляю, отличная работа! Не думали написать статью на habr.com ?
Amazing stuff! And if you really have managed to solve compile-time memory management, that's super impressive stuff.
The controversy around V is not without reason.

For some context here’s the last of a series of posts examining some of Vs claims https://christine.website/blog/vlang-update-2020-06-17

The way I'd describe what I see from V's author from his two projects (V and Volt/eul) is a continual over-promising and underdelivering - as well as misleading statements (for example, a claim that V is the "fastest on Tech Empower's web framework", which is actually fastest in only plain text (it does not do enough to be qualified on the full leaderboards) on an unofficial run (it is currently 2nd I believe), where it is simply a wrapper around a C server [1][2][3] - which I believe is misleading, even if the C interop is neat). That is not to say he cannot eventually deliver on his promises, but they frequently take years beyond his initial predictions, and sometimes come watered down.

My personal conclusion from my reading was - if you wish to go use V, go ahead, but I'd exercise caution when relying on anything about it.

[1]: https://twitter.com/v_language/status/1234586123424456705

[2]: https://github.com/vlang/v/blob/bc288019932c35cc09dcf7b438bc...

[3]: https://github.com/vlang/v/tree/bc288019932c35cc09dcf7b438bc...

This is a set of very biased articles, I mean just look at this for example:

> Git is a dependency, which means perl is a dependency, which means a shell is a dependency, which means glibc is a dependency, which means that a lot of other things (including posix threads) are also dependencies. Pedantically, you could even go as far as saying that you could count the Linux kernel, the processor being used and the like as dependencies, but that's a bit out of scope for this.

What's the point of such nitpicking? You don't need git to use V, and the point of the no dependency claim is that bootstrapping V is as simple as `cc v.c` and the V compiler produces single file binaries, that are easy to deploy, without any dependencies on an interpreter/environment/libs etc.

I'm actually going to write a post debunking all of the claims in these articles, since I see them mentioned quite often (including measuring the compilation speed by using an unoptimized debug build + running vfmt + rebuilding the standard library with each compilation + using a 2x slower backend).

Ok, V creator may have an huge ego. Evan Czaplicki (Elm creator) may have an even larger ego. The list goes on. Does it worth to do everything to castrate their ambition? They like to put the bar high. Higher than they can jump most likely but in the meanwhile they build something. Probably not exactly what they proposed to but way more than the ones that criticise them. Criticise with work not with nitpicking, from the outside it resembles envy. Time will certainly judge them and us also.

Disclaimer: I don't know V authors nor I'm part of V community.

Some other claims from the author:

> Good question. I haven't mentioned memory management because it's not done yet. I know for sure there won't be a GC or reference counting. [0]

> What I mean is `a = sort(a)` will be optimized to `sort(&a)` which can mutate internally. [1]

Do look at the entire threads - I don't think the claims are too out of context as quoted.

[0] - https://news.ycombinator.com/item?id=19102318

[1] - https://news.ycombinator.com/item?id=19102573

> The controversy around V is not without reason.

There is no controversy but the one you are trying to build up. This language is obvious quite young in development, isn't backed by mega corp Z with billions of $ at its disposal, yet it is trying to manage to find a solution to multiple issues Go couldn't even resolve in 10+ years. cut it some slacks.

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.

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.

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 actually is a take that “gets things right”?

[1] https://en.m.wikipedia.org/wiki/EC_(programming_language)

[2] https://ec-lang.org/overview/

> 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

I think the reason is something else: It's not the demand that's amazing, it's the supply.

A lot of people like making languages, and full working environments to go with them. It's fun! If you're into that sort of thing, it might be the most attractive kind of project, with a kind of geek gravity that draws you in when you've got the bug.

A new language and its environment is an interesting exercise, even if it takes years. It's something to do to hone your craft. It's not particularly difficult, if you go for it, it just takes time. You can add all those ideas you wish other languages had but never do. Probably if you're into making languages you have a lot of ideas like that.

There's lots of interesting things to learn, lots of puzzles to solve, and then you have an artifact at the end which other people can appreciate. They might even find it useful, which is another reward, another bit of satisfaction.

If that's a major reason for new languages, why C-like?

I think C-like hits a design sweet-spot that is easy to understand and easy to branch out from. But it's also something you know other people are likely to understand and appreciate. It's not too exotic, at least at first glance. With so much supply and a lot less demand, you want your language to be noticed, to be useful and seen as useful. Being C-like boosts chances of acceptance as a language to take that bit more seriously.

I company I worked for a very long time ago wrote a hardware compiler, with a front-end language for hardware called Handel which was a DSL in Standard ML (great language. ML. by the way).

It was used, but it got more popular when they wrote a C-like front end and called it Handel-C. There was no real difference to the language, and Handel-C was in many ways less powerful (because there was no ML with which to manipulate the syntax tree), but the C-like syntax made it a look familiar, and therefore marketable.

I currently work with Zig, which is one of the C-like languages. C has a ton of footguns, and is not easy to parse (due to a lexical macro system). Because of these (and other) properties, I made Zigler (https://www.youtube.com/watch?v=fIxNEILcNGM), which is an automatically recompiling inline FFI system for the Elixir language, it's arguably easier to write correct C FFI functions with Zig as an intermediate than in C itself.
Whenever I hear a new language announced here I ask "what does it offer over OCaml?" Disappointingly often the answer seems to be nothing. At least in the post-Rust world most of the ML featureset is now part of the baseline for people who think they need non-GC or "as fast as possible".
It's normal, people want C like performances, with zero cost abstractions, with memory safety, without the ugliness, unsafe behavior of C. C is a language thought out for 1970 constraints and developers can do better.

Developers won't stop creating languages until something that really succeed in replacing C is created.

> Are you bored and want a fun new take on programming?

Nothing wrong with that.

And here I thought that I had all of these languages already bookmarked but I never heard of eC before. Thanks for mentioning. It looks very interesting.
Can I ask you to send me an email? I'd like to follow up on this comment in private. I can be reached at sir@cmpwn.com
Congrats to V on implementing the compile time memory management technique from http://aardappel.github.io/lobster/memory_management.html, like you mentioned on Discord.

Would be nice if you would credit it, though.

Nim has merged first class view types and their lifetime tracking:

- https://github.com/nim-lang/RFCs/issues/178

- https://nim-lang.org/docs/manual_experimental.html#view-type...

From: https://vlang.io/compare#go

- No null

- No err != nil checks (replaced by option types)

- Immutability by default

- Generics

- Sum types (type Expr = IfExpr | StringLiteral | IntLiteral )

- If and match expressions (including sum type matches)

This might be my personal project goto language for 2021.

> goto language

As in ‘considered harmful’?

I’m staying away from any language with vulnerabilities like these: https://christine.website/blog/OVE-20190623-0001

I remember from first publications about V lang that felt like a hoax: reams of exciting promises and basically nothing to show for them.'

It's great to see that it's not s hoax, and it starts to somehow flesh out.

Thanks.

Would disagree with "nothing to show for them" though.

The V compiler was written in V from the start at the time of the release, which already shows the maturity of the language, and it did compile itself in less than a second. Bootstrapping it has always been as simple as `cc v.c`. It had a graphics library from the start with a working Tetris game example, hot code reloading, etc

It was definitely rough around the edges due to being a one man project, so it's good that it received help from hundreds of contributors. It's much more stable now.

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.

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.

Here is Tetris in V:

https://github.com/vlang/v/blob/master/examples/tetris/tetri...

They claim:

> Pure functions by default

but all this means by their definition is: no global mutable variables, sort of, because you can enable them per compiler flag.

     darkstar$ ../../v run tetris.v
    
     Compilation with tcc failed. Retrying with cc ...

 ATTENTION: default value of option vblank_mode overridden by environment.

    gg error: GLX: failed to create GL context

    Terminated by signal  6 (SIGABRT)

    Graphics:

      Device-1: AMD RS690M [Radeon Xpress 1200/1250/1270] driver: radeon

      v: kernel
      Display: server: X.Org 1.18.3 driver: radeon resolution: 1680x1050~61Hz
      OpenGL: renderer: Gallium 0.4 on ATI RS690 v: 2.1 Mesa 13.0.6
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?
I learn Go by Learn-go-with-tests. Maybe you guys should do it too.
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.

Maybe this project had a rough start, but right now anyone claiming this is not real should probably re-evaluate those feelings.

I just heard about and starting looking into V last night. This is perfect timing!
A tcc backend is mentioned—can someone point me to that?

P.S. This language looks amazing

So this is a safer alternative to Golang with smaller binaries, generics and no GC?

[edit] Sorry, edited before there was a reply. You're very fast!

Never heard of V before, now I'm super excited. Congratulations on the 0.2 release!
built-in ORM is really compelling actually

it implies the presence of other nice-to-haves, like ergonomic struct iteration and linting against schema

and it gracefully enables low-code API frameworks if you can annotate RBAC + visibility rules

On my bucket list to check out. Still stuck on trying out Zig.
Does this language have a package management tool?
What parts of this are closed source again?
I'm actually amazed by the progress. Wow. Seems like it's worth keeping an eye on. Curious if anyone is running it in production yet?
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.)