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!
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.
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 :)
Though I guess "VLang" works.
Also garbage collection. What are you doing for that? ARC?
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.
https://github.com/vlang/v/blob/master/vlib/v/tests/valgrind...
It has lots of comments and will give you a good picture.
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?
Swift also has value types, and optimization passes to promote heap-allocated objects and closures to the stack where possible using escape analysis.
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.
That should free most objects in a simple scenario, but how do you free objects in a cycle without a garbage collector?
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.
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.
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.
We use Sokol, an amazing wrapper library, and it only supports the big 3.
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)
We'll see how it goes, maybe at some point Vulkan will be supported by Sokol, this library is growing very quickly.