V (Vlang) 0.2 | Hacker News Reader

V (Vlang) 0.2

github.com

247 points0xedb159 comments

Open articleView on HN

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

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?

No webview, that's not our way :) Although we do have a webview module for embedding the system's webview component.

The GUI library renders everything, and the result looks very similar to the native widgets:

https://raw.githubusercontent.com/vlang/ui/c2f802a137b5171da...

We are going to support native widgets, for example TextBox will be native due to accessibility and support for Chinese/Japanese/Korean/R2L input.

However things like text rendering will always be handled by the V graphics library, since GDI+ is just way too slow (calculating text bounds is ~10 times slower than in V), and Apple's drawing API is not very nice to use, and it's also 2-3 times slower at rendering text.

It's great to see accessibility/compatibility taken into account here, but are you only doing that for the text input or going further? E.g. can I copy text or use a screen reader?

We will do this for the text rendered via V's graphics library as well, by using system accessibility APIs directly.

> GDI+ is just way too slow (calculating text bounds is ~10 times slower than in V), and Apple's drawing API is not very nice to use, and it's also 2-3 times slower at rendering text.

Does V's text library support the kinds of shaping and nested bidirectional layout needed to render Arabic text? I've heard that's a cause of a lot of complexity and slowness in text rendering, so stripping it out would be an easy performance win for people like me who can't read Arabic anyway.

As for Android/iOS, V itself has been running on phones for quite a while:

https://www.youtube.com/watch?v=fIijYm1MfmI&feature=youtu.be

The UI library will support mobile asap, since it'll receive lots of attention now that 0.2 is out, and we now have 2 people contributing to it.

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?

From the home page:

V avoids doing unnecessary allocations in the first place by using value types, string buffers, promoting a simple abstraction-free code style.

Most objects (~90-100%) are freed by V's autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via reference counting.

The developer doesn't need to change anything in their code. "It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything or expensive RC for each object.

For developers willing to have more low level control, autofree can be disabled with -noautofree.

Note: right now autofree is hidden behind the -autofree flag. It will be enabled by default in V 0.3.

---

So yes, for the ~0-10% of objects not freed by V's autofree, ARC will be used. We will implement weak references and probably have a simple cycle detector, so pretty much a minimal GC.

Unlike in Go or Swift, it won't be used on all objects, but only on the small percentage that couldn't be handled by autofree.

In the YouTube demo I posted, 100% of all allocations in the text editor is handled by autofree.

How exactly does V know when/where to release memory?

See my reply to the sibling comment.

This sounds interesting. I would love to understand how autofree decides what it can handle, and when ARC comes in.

Check this test out:

https://github.com/vlang/v/blob/master/vlib/v/tests/valgrind...

It has lots of comments and will give you a good picture.

I think having actual documentation about how the memory system is supposed to work would do a lot more to answer questions than linking to the tests.

For example:

x = [1, 2, 3] // is this stack or heap allocated?

foo(&x) // how does the compiler know if x needs to be ref counted or not?

return &x // is this valid or UB or a compilation error?

It looks similar to nim's ARC/ORC gc approach... Just curious, have you ever compared them?

> Unlike in Go or Swift, it won't be used on all objects, but only on the small percentage that couldn't be handled by autofree.

Swift also has value types, and optimization passes to promote heap-allocated objects and closures to the stack where possible using escape analysis.

Similar in Go as well: Many things are by value, and it does escape analysis too, allowing a lot of things to not require the GC.

How does V deal with cycles?

Sorry but again this is one of those "V can do X (except when it doesn't and i get to define what that means)".

I don't want to be a hater and I'm genuinely impressed by the project. But it's honestly very hard to trust anything about this when all kinds of claims pop up, always with a big caveat at the end, usually after being questioned in forums and not in the official documentation.

What happens today if i don't pass in -autofree? If it was working it would be enabled right? And if it's not working, then how do i code without it? Sure, the language has a 0.x-version number but it's not exactly being advertised as something that is incomplete unless i dig very deep into documentation or twitter-threads. Some kind of roadmap of promised/planned/delivered features would greatly improve the confidence in this being not vaporware.

> Remaining small percentage of objects is freed via reference counting.

That should free most objects in a simple scenario, but how do you free objects in a cycle without a garbage collector?

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.

Thanks!

Yes, it has been blocked by the memory management work and the 0.2 release, both of which took a while, especially since most of the compiler had to be re-written from scratch (using an AST). The UI library was also re-written several times as we tried different approaches (native vs custom rendering).

The good news is that Volt was always being updated and made compilable, and a public beta is also coming this month.

I'm already using Volt as my primary Discord client (and my 8 GB RAM laptop thanks me for that, since I've freed 2 GB of RAM).

Here's a sneak peek:

https://media.discordapp.net/attachments/731265552395534357/...

Some layout issues, and Chinese/Japanese/emoji not being rendered correctly, but the latter has been fixed on a branch.

The moral of the story is: if you want to deliver a software application quickly, don't write a new language/stdlib/ui lib for it from scratch.

At least I got to create a cool language and share it with the world :)

Did you ever release the code of the original Go version of Eul/Volt?

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?

Vulkan is too complex and is not supported by Apple and older hardware.

We use Sokol, an amazing wrapper library, and it only supports the big 3.

https://github.com/floooh/sokol

Makes sense, though I'd dispute that Vulkan is "too complex". It's definitely not simple, but that's because it's a complex problem. The driver guesswork that something like OpenGL uses comes with costs, too.

Vulkan is supported pretty well on Apple through MoltenVK: https://github.com/KhronosGroup/MoltenVK

Mesa does software implementation of Vulkan, too: https://en.wikipedia.org/wiki/Mesa_(computer_graphics)

Yes, I wanted to mention MoltenVK. That's another dependency and another layer of abstraction, which is not our way.

We'll see how it goes, maybe at some point Vulkan will be supported by Sokol, this library is growing very quickly.

Amazing stuff! And if you really have managed to solve compile-time memory management, that's super impressive stuff.

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.

What is v’s take on inheritance / traits / mixin

Поздравляю, отличная работа! Не думали написать статью на habr.com ?

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

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).

How about refuting the memory leaks claim? Or the others in previous posts as well, that were calling out impossible features of the lang (that sounded like some ad)

Nitpicking nitpicks is still nitpicking.

A memory leak that even the author admits is one line of code fix away? (free() on a global const)

See the YouTube demo I posted which shows how V removes 100% of leaks in a complex graphical application (text editor).

Well, I will believe it when I see it, as well as the other hard to believe claims like I don’t know how many lines of code/second compilation speed, perfect C-to-V compiler, etc. I’m not sure how many of it is still up on the website, because some were called out and were taken down.

Why won't you see it? It's public:

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

You can also download it and try it yourself.

As for compilation speed, here's V compiling itself in 0.2 seconds:

https://pbs.twimg.com/media/EoAx9fsWMAE2M4U?format=jpg&name=...

The nearly 1 second compilation is impressive, but why claim it has 0.2 second compile time when using a cache? It doesn’t represent the real-world time it would take to compile v or another program from fresh in order to install it.

I often compile projects before the cache expires...

-usecache here means that vlib is cached. It will be the default in 0.2.1.

The entire V compiler is built from scratch.

All memory leaks in C are one line of code away as well (calling free() in some place).

Just FYI: on Hacker News, it's customary to add a little disclaimer to comments like these. Something like:

  (Disclaimer: I'm the creator and main developer of V.)

All right, makes sense. Added it to my top level most upvoted comment here.

Lol, unless this person was ridiculously well informed on V, that was basically the only option I saw :)

Diving straight in to attack the critic (again) rather than discussing things usefully made it pretty obvious it must be the original developer. You don't generally see two people who behave like that managing to co-exist in the same project.

> without any dependencies on an interpreter/environment/libs etc.

no stake on either side, but the post specifically mentions this (though that was on vlang 0.1)

> I claim that the V compiler has dependencies because it requires other libraries or programs in order to function. For an example, see the output of ldd (a program that lists the dynamically linked dependencies of other programs) on the V compiler and a hello world program:

  $ ldd ./v
          linux-vdso.so.1 (0x00007fff2d044000)
          libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2fb3e4c000)
          libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2fb3a5b000)
          /lib64/ld-linux-x86-64.so.2 (0x00007f2fb4345000)

  $ ldd ./hello
          linux-vdso.so.1 (0x00007ffdfdff2000)
          libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fed25771000)
          /lib64/ld-linux-x86-64.so.2 (0x00007fed25d88000)

> If these binaries were really as dependency-free as the V website claims, the output of ldd would look something like this:

  $ ldd $HOME/bin/dhall
          not a dynamic executable

libc is the only stable system api, on non Linux system you don't have a choice to use anything else.

Go tried, and went back to linking to libc, because of constant syscall changes.

So I don't view having libc a dependency, it'd be like saying that macOS is a dependency.

You can also use musl on Linux with V for 100% static binaries.

libc is not stable, glibc breaks plenty of times (try running some real old software without relinking glibc).

The only stable system API is the linux kernel syscalls. Those basically don't break.

That’s true for Linux and why Go thought they could do this everywhere. It turns out that libc is the only stable interface for a lot of platforms (notably MacOS and many other BSDs if not all).

Correct, on Windows there is no stable syscall interface, same for BSD. Hence you're supposed to link things. But Linux syscall interface is stable and libc is definitely not stable.

What has glibc broken?

Here is a tracker for backwards-incompatible changes to glibc:

https://abi-laboratory.pro/?view=timeline&l=glibc

didn't mean to argue, just providing context for people scrolling through the comments :) i agree that it's a bit nitpicky. (but "depends only on libc" would probably be a better phrasing)

Sure is nitpicky. When I see some open source software I certainly never see libc mentioned as a dependency. It's just assumed that it is there as part of the OS which it basically is.

"I don't view this dependency as a dependency" is ... ok, you can redefine things if you're clear about that, but given you've also argued that "printing to stdout doesn't make a function impure" I think perhaps a glossary of terms that V uses differently would be helpful to understand your claims.

I'd also note that given you then banned her from the issue tracker after that post went up rather than discussing it, your claims of bias on her part seem a trifle strange.

But the example was run on Linux.

FreePascal works without libc

I liked the design of V and gave it a try. I quit paying attention when I realized almost nothing worked like it was supposed to. Even hello world was difficult due to needing to configure all sorts of stuff to get tcc and configure it to compile correctly.

That shouldn't be happening. We have lots of tests to make sure it works.

Are you on Windows? Can you create a GitHub issue with `v doctor` so that it can be resolved asap.

Sorry, I already went down the road of broken promises and moved on. Make something that works out of the box. Package tcc with it.

It already is...

> > Git is a dependency, which means perl is a dependency, which means a shell is a dependency, [...]

Indeed, this is a silly matter. In both sides.

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...

Just for reference in Techemppwer Benchmark, the same guy who utilizes H2O HTTP source code for benchmarking, wrote h2o.cr for Crystal language and pico.v for V language. It’s isn’t mean for general use in any projects.

> 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.

It’s fair to try to solve issues. But these are hard issues, and it is at best overconfident to outright say they will do X, when they didn’t even started working on it, and at worse it may be a scam making money from donations, but I am hoping that it is the first case.

> at worse it may be a scam making money from donations

Before making such a rude conjecture, at least check the dev's github page [1] first. Most of his git commits are related to V and he has been actively working on it for a couple of years, even over weekends. V may fail like many new languages, but at least the dev has paid the efforts. He has my respect.

[1]: https://github.com/medvednikov

At the start of the project, the source code was not available and I deliberately wrote that I really hope and want to believe that the first option is the correct. Nonetheless, this project did start controversially with absolutely bold claims, other, similarly small languages like zig interestingly doesn’t have bad connotations associated with it. Hopefully V will be able to shed these and will grow successful.

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

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.

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.

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

Nothing wrong with that.

Absolutely not! Programming doesn’t need to be stuffy with only “old timer” languages. Maybe 8 years into programming I myself got very much into language and compiler design. I started as most would by making languages which just had different keywords. Then at some point truly ventured off the deep end with languages that include (for example) built-in abstract algebra and symbolic computation. None of my creations would have ever been passed off as being “practical” for any sort of industrial use. The point was that it was fun, and I learned an enormous amount from my own and others’ languages.

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

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".

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.

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.

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.

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...

There are actually quite a lot of languages that do something in the realm of owning/borrowing, see my link above for a partial list (which includes Nim).

Nim's views (and also their ORC system) is closer to Rust/Swift/C++ than it is to Lobster, in the sense that it is all very explicitly programmer driven with explicit type annotations.

Lobster's system is fully automatic and almost entirely transparent to the user.

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

That looks like a vulnerability in a V playground, not a vulnerability in the V language itself.

It came from the same developer. The mere fact that he was that sloppy in securing a publicly-facing service to leave a vulnerability so severe and so easily discovered should have you asking: why should I believe that anything else in this project is any more robust and secure (and will be in the future)?

So what do you think about Linux after the kernel.org hack?

Not sure what the "considered harmful" implies here. It's clear what Djikstra meant, and it's not about removing goto altogether. Goto is still used as a best practice in many situations (e.g. error cleanup in the Linux kernel), and is very useful in other domains too (e.g. generated code for parsing, state machines, etc).

As for the vulnerability, while it is real, it's not related to the language.

And not even sure what "I’m staying away from any language with vulnerabilities like these" even means. As if other languages/compilers/etc, even established ones like C/Clang-GCC, Java, Javascript, etc don't have any?

https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.p...

Yeah, I know of the paper, I even referenced it in my comment :-)

The vulnerability was acknowledged and fixed in 1 day. If that's indicative of the type of response the project's authors have, color me impressed. Also, this post is for version 0.2. I ain't scurred for personal projects.

Author of that secvuln report here. It was fixed by the playground server being decommissioned. I do not know the exact timeframe of any fix that was made to that playground service. Pedantically, I guess the server being permanently decommissioned could count as a fix. However it does not bode well.

The V playground seems to be up and running.

Nope, all issues were fixed, and it ran without any hacks for 6 months, until it was replaced by a WASM playground.

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.

I wonder if vlang may be the No Man's Sky of languages: initial launch over-committed and under-delivered, but steady progress helped build it into a good product. V definitely isn't there yet, and every time I go try it again it seems janky, but I'm glad to see it's making progress.

I think that’s a very apt comparison. It’s good too, since it means we’ll eventually get to quite a nice place.

That would bei Jai :D

I'd say Jai is a bit different. No plans to release soon, but will probably be fairly mature when it is, since Jon is writing a real game in it first. I'm seriously excited for it after watching some of his streams.

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.

Bootstrapping the compiler isn't a sign of language maturity. V has changed pretty significantly both in terms of syntax as well as semantics since that release.

Regarding compile times, why do you claim less than one second when your own tracking shows 2.5 seconds and trending upwards? (fast.vlang.io) Aren't you concerned that as the compiler and language are actually implemented, compile times will continue to worsen? Have you considered that perhaps that's why there are so few languages that claim that kind of bootstrap time?

I saw a quote recently along the lines of "a scientist is someone working on something they know nothing about; an engineer is someone working on something they know everything about." I think the project started out as a science project and is moving the direction of an engineering project. A totally outside perspective—I haven't checked it out in a while.

> an engineer is someone working on something they know everything about.

That seems completely contrary to my engineering training. The engineer motto is about "be prepared for the unexpected" i.e. escape hatches, manual override, overprovisioning, assume that your temporary "train", "power plant", "airplane" will be in service for 40 years instead of 20, make it serviceable even without infrastructure.

I think we're saying the same thing and I just butchered the original quote. having checklists of everything that could go wrong, real and imagined, with senses of probabilities, I would consider "knowing everything about". Or maybe its "knowing what you dont know".

Because it is a hoax.

The author made lots of unsubstantiated and even nonsensical promises such as green threads with no runtime or the supposed C++ to V translator which would be a HUGE breakthrough in compiler technology because such a tool would be (as was exactly shown in an example) able to understand programmer's intent.

He just stringed together attractive looking words and phrases without really understanding what they mean.

And of course, none of the promises actually materialized, so either Medvednikov is grossly incompetent or a pathological liar. You decide which is the case.

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...

We do have a 7 line hello world, but that's not enough.

In the old site I implemented a slider with 7 small examples, I'll bring it back.

There's also a large Examples link on top.

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

Be sure to pop into #help on https://discord.gg/vlang and/or push a ticket with `v doctor` output.

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?

You are right, and V will give the developers that control.

It'll be possible to use `[noautofree]` in modules and use manual memory management with or without arena allocation.

Arena allocation should also work with -autofree, I don't see why not, it's just malloc() and free().

I learn Go by Learn-go-with-tests. Maybe you guys should do it too.

We have an extensive documentation page that is pretty much a tutorial:

https://github.com/vlang/v/blob/master/doc/docs.md

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?

Be sure to pop into Discord to chat further (https://discord.gg/vlang). You can bring up questions around this with Alex in #v-development and I'm sure others will also chime in.

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.

You're right but at the same time people also need to evaluate the state of the language with respect to the claims made on the home page.

- autofree not only leaks memory but in some cases causes double frees or use after free resulting in UB. Look at issues tagged autofree on their repo.

- No UB is claimed but the compiler does nothing to stop you from doing it and V is a very thin layer on top of C so it's trivial to cause UB. Signed integer overflow in V: instant UB.

- hot code reloading literally just overwrites the library in memory as the application is running. Better hope your compiler laid everything out exactly the same way or it will segfault and it usually does.

- Generics. Only one type argument is supported. The built in std types don't even use them because the implementation is so broken.

- option types: why have Some(T) | None when you can mix error handling in too and have Some(T) | None | Error(E)? That's right, option types three values. (Tri-state booleans anyone?)

- Compilation speed: V translates to C and then runs a C compiler. V isn't going to compile any faster than your C will. The only reasons that it's pretty fast right now are because most programs are very small and so is the std library and because they use tcc which performs no optimizations at all. If you want your C code to compile as fast as V does, just use tcc.

- Runtime speed: No rigorous benchmarks have been done. The claim of within 3% is a goal they have no idea how to achieve. Given their memory system relies on ref counting and optimizing out increments and decrements, they won't be able to hit that only taking memory management into account. Other design aspects have serious implications in terms of performance such as array copying being implicit. (b = a) copies all of a into a new array.

This is fine for a learning experience and I hope everyone involved is learning a lot but pitching this as some kind of project that people should learn and write real code in is crazy.

It sounds like you know a lot about language design, so why not file a few issues or make a contribution?

Why was it necessary to create a temporary account to write your post? I can probably guess who you are since there are only a few folks really vocal and on some kind of personal mission to shoot this down at every opportunity. What a waste of time. What a sad thing to do to an open source project.

I have tried this before and generally the response to my issues has been "this will be fixed" with no further explanation that would allow having a discussion and thinking through the soundness of the idea of even letting someone other than the author take a stab at implementing it.

Even for critical things like the memory management strategy, no one other than Alex has any idea how it is supposed to work (beyond some references to Lobster). Even when it's pointed out that Lobster makes some concessions that V does not so that the memory management system can work, there is still no discussion.

The V community and team seem far more interested in generating hype and publicity than actually doing the hard parts of language design.

I don't actually think the community is trying to be malicious. If you hang out in their discord, they're generally quite friendly. What they lack is focus.

The language and canonical backends aren't anywhere close to complete and there's already attention bring split to build an x86_64 backend and a wasm backend. Neither of these are anything more than toys even in comparison to the C one. At the same time, std is lacking critical things like a map type that doesn't require your keys to be strings. And yet they're working on a discord client and a websocket implementation. V-os and v-browser are seriously discussed with promises like "we'll start on that after 0.3".

V is sort of the ultimate yack shave. The author wanted to make a thin discord client but first they needed a new text editor so then they needed a language to write it in. It's really only a matter of time before the next project comes up and the author leaves V in the same state as his other projects.

Too true. The writing is on the wall for sure.

What "writing" would that be exactly?

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

Indeed, we now use tcc for dev builds. Our own version of tcc is prebuilt and distributed, so you don't even need a C compiler to start developing in V.

Will add it to the changelog.

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!

Yes, it does! :)

This is a frequently asked question, so I had it covered.

Things V improves on Go:

https://vlang.io/compare#go

The excluded parts I'd be interested in is cross-compiling + concurrency.

Awesome work, sure it will get there either way :)

We already support cross compiling to Windows/Linux (only amd64 for now), will record another demo soon.

Concurrency is WIP, and will be the main feature of 0.3.

We already have channels, locks, and thread safe typed arrays/maps.

Couple questions about channels:

    1. Will they be as heavy as Go's ? Go has 2 mutexes and some other fluff
    2. Are they "close-safe" like, if I send something to the channel, and it is nil or closed, will it panic crash or stuck forever like Go does, or V is trying to be "panic-free"? Will "prohibited" operation return an error or panic/stuck?
    3. If channels are closeable, will I be able to close them twice without panic (closing closed door might creak, but IMHO should not burn the house down...)

(At some point in the past I did suggest adding an error to channel operations so it will not panic if I am ready to intercept an error, but that was rejected)

Are you on Discord? If so, pop on into: https://discord.gg/vlang and chat at #concurrency

Thank you for the suggestion. No, I am not on discord.

I'm sorry - at this point I'd say with your input you should pop onto Discord to have more robust discussions.

Did they cite any reason for the rejection? Thanks

I need to find it, but I remember it was "we discussed it, and no, we decided not to" sort of answer there. There is also earlier explanations (from Rob Pike I think?) that was "we did not like how it looks like, couldn't find a nice looking syntax". The whole discussion left me with a bit of eery feeling, and left me with a bit of a sour taste (together with "error handling" one that I kind of tried to participate in). I pretty much stopped actively following golang-nuts after that, and now only look at proposals through meeting notes that Russ posts on github [1], where you can see accepted/not accepted status immediately.

Btw, there is another saga (drama?) unfolding on github proposal discussions over sum types [2], and judging by the past experience I don't have high hopes for it to get into the language.

[1] https://github.com/golang/go/issues/33502

[2] just one last I saw today, but there are more tickets about same or connected issue https://github.com/golang/go/issues/41716

https://news.ycombinator.com/item?id=25604064

Hello, I'm the one who has implemented channels for V, so I'll try to answer these questions:

1. "Heavy" is a vague term and I think that it is even used polemically here. Every channel implementation needs methods to avoid race conditions and I think Go uses what is needed for reliable operation, but not more (even when there is a "mutex" in their code it's not a real OS-mutex - Go's channel implementation is actually very efficient). V's implementation uses mostly atomics and sometimes spin-locks.

2. There are no "nil-channels" in V, but a channel can be closed. As in Go, just sending to a closed channel causes a panic - that's a design decision. The point is: not to panic requires some kind of error handling. In a language like C++ this can be done by throwing an exception (which has to be caught elsewhere). But neither Go nor V have exception (that is also a design decision). In V a failure due to a closed channel can be trapped using `or` (https://github.com/vlang/v/blob/master/doc/docs.md#syntax-an...) on the receiving side or by using `select` (https://github.com/vlang/v/blob/master/doc/docs.md#channel-s...) on the sending side or the receiving side.

3. Closing an already closed channel should not cause any panic.

Thank you for such extended answer.

1. I would politely disagree with Go channels are efficient. If they would be efficient, they would be actively used internally as a synchronization primitive. I don't remember seeing external libraries using it past notification mechanism of "it is done" kind either. There would be some nifty tricks possible if cost of channels is much lower, or compiler would be able to use some "very light" channels if it sees it is possible (not sure if it even theoretically possible, but I am not an CS theory guru...)

2. That's kind of unfortunate, I would prefer if error is requested, just return an error

   err := ch <- data_to_send

   ch <- data_to_send

which might panic. But looks like neither of languages allow this. I proposed the syntax above to Go, but it was rejected.

3. That's nice. Is there an error to catch if needed?

    err := close(ch)

Silly me - the syntax that I proposed was the second one

    err := close(ch)

to handle case when you don't want a panic on closing of closed channel. The first one was discussed on golang-nuts, but it died there.

Would highly suggest you pop onto Discord (https://discord.gg/vlang) to chat in #concurrency about this further...

1. There are some principle limits to take into account:

Channel operations involve task switches - especially on unbuffered channels. How expensive these are depends on the scheduler, but basically they are expensive on all operating systems.

Other synchronization primitives (like mutexes, semaphores, atomics) can be implemented in a way that the scheduler is not involved when no (long) blocking is needed (futex, spin-locks, ...).

The Go people took the path to implement their own scheduler, which is highly optimized for channel operations, on top of the OS (similar to a virtual machine). So, they don't use OS-threads or OS-mutexes. This does result in better channel performance, but still there are task switches. And this approach has other drawbacks concerning C interoperability.

V sticks to OS-threads and the OS-scheduler (and not re-implementing these could be called "lightweight"). This means better C interoperability but channel operations are even more expensive.

For this reason I've also implemented `shared` objects into the V core language as a more efficient way of sharing data (see also https://github.com/vlang/v/blob/master/doc/upcoming.md#varia...):

  shared x := ...
  go f(shared x)
  lock x {
      // modify x
  }
  rlock x {
      // read x
  }

2./3. Syntax considerations should be consistent within the whole language. As @illuminate has already pointed out we discuss these things on discord (https://discord.gg/vlang). There's also a channel #syntax.

No. Go is actually stable and mature with a performant runtime and most importantly, the project isn't led by a con artist.

How is this guy a con artist? Have you looked at all the repos under v/?

At the least I'd say he's over optimistic, but the work is getting done.

overpromising and underdelivering != con artist, though I do understand where you're coming from as the very initial (postponed) release and asking for donation gave a scam feel.

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?

Yes, it is called vpm

https://vpm.vlang.io/

Yes! It's called vpm.

    v install ui

What parts of this are closed source again?

None.

Cool, I thought earlier versions were partially closed source and I was curious. This is really high level work. Nice job. How many languages have you designed/implemented?

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.)

Then you'd have no way to differentiate between declaration and assignment, and have all the problems that brings. Hello, Python :)

I’m aware of the trade-offs. :) I’d rather use a digraph operator for mutating assignment, again with the Huffman coding argument. One design I’m thinking of is using “@” as the mutable qualifier (e.g. “@int” is a mutable int), and correspondingly use “@=” for mutating assignment. (The swirl in the “@” glyph is meant to allude to mutation, and it’s a character that visually stands out in code, as mutation should.)

Reply on news.ycombinator.com