6 ms·

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 mem

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 https://www.youtube.com/watch?v=gmB8ea8uLsM

edko 6y ago
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?
- amedvednikov 6y ago
  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/c2f802a137b5171dade1d5fdc364cd92d34e3ca7/examples/users/screenshot.png 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.
  - solarkraft 6y ago
    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?
    - amedvednikov 6y ago
      We will do this for the text rendered via V's graphics library as well, by using system accessibility APIs directly.
  - csande17 6y ago
    > 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.
- amedvednikov 6y ago
  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 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.
himujjal 6y ago
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?
- amedvednikov 6y ago
  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.
  - YorickPeterse 6y ago
    How exactly does V know when/where to release memory?
    - amedvednikov 6y ago
      See my reply to the sibling comment.
  - dgb23 6y ago
    This sounds interesting. I would love to understand how autofree decides what it can handle, and when ARC comes in.
NiekvdMaas 6y ago
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.
- amedvednikov 6y ago
  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/790876897952923678/Screenshot_2020-12-22_at_10.42.14.png?width=1666&height=1067 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 :)
  - deleted 6y ago
    [deleted]
  - abc-xyz 6y ago
    Did you ever release the code of the original Go version of Eul/Volt?
da_big_ghey 6y ago
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?
- amedvednikov 6y ago
  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 https://github.com/floooh/sokol
  - da_big_ghey 6y ago
    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 https://github.com/KhronosGroup/MoltenVK Mesa does software implementation of Vulkan, too: https://en.wikipedia.org/wiki/Mesa_(computer_graphics) https://en.wikipedia.org/wiki/Mesa_(computer_graphics)
    - amedvednikov 6y ago
      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.
chubs 6y ago
Amazing stuff! And if you really have managed to solve compile-time memory management, that's super impressive stuff.
- higerordermap 6y ago
  Turing ded
breck 6y ago
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.
zaphirplane 6y ago
What is v’s take on inheritance / traits / mixin
somurzakov 6y ago
Поздравляю, отличная работа! Не думали написать статью на habr.com ?

edko 6y ago

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?

amedvednikov 6y ago
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/c2f802a137b5171dade1d5fdc364cd92d34e3ca7/examples/users/screenshot.png 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.
- solarkraft 6y ago
  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?
  - amedvednikov 6y ago
    We will do this for the text rendered via V's graphics library as well, by using system accessibility APIs directly.
- csande17 6y ago
  > 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.
amedvednikov 6y ago
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 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.

himujjal 6y ago

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?

amedvednikov 6y ago
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.
- YorickPeterse 6y ago
  How exactly does V know when/where to release memory?
  - amedvednikov 6y ago
    See my reply to the sibling comment.
- dgb23 6y ago
  This sounds interesting. I would love to understand how autofree decides what it can handle, and when ARC comes in.

NiekvdMaas 6y ago

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.

amedvednikov 6y ago
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/790876897952923678/Screenshot_2020-12-22_at_10.42.14.png?width=1666&height=1067 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 :)
- deleted 6y ago
  [deleted]
- abc-xyz 6y ago
  Did you ever release the code of the original Go version of Eul/Volt?

da_big_ghey 6y ago

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?

amedvednikov 6y ago
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 https://github.com/floooh/sokol
- da_big_ghey 6y ago
  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 https://github.com/KhronosGroup/MoltenVK Mesa does software implementation of Vulkan, too: https://en.wikipedia.org/wiki/Mesa_(computer_graphics) https://en.wikipedia.org/wiki/Mesa_(computer_graphics)
  - amedvednikov 6y ago
    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.

chubs 6y ago

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

higerordermap 6y ago
Turing ded

breck 6y ago

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.

zaphirplane 6y ago

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

somurzakov 6y ago

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