13 ms·

V (Vlang) 0.2

247 points by 0xedb 6y ago

layer8 6y ago
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.)
- amedvednikov 6y ago
  Then you'd have no way to differentiate between declaration and assignment, and have all the problems that brings. Hello, Python :)
  - layer8 6y ago
    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.)
amedvednikov 6y ago
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 ?
socialdemocrat 6y ago
On my bucket list to check out. Still stuck on trying out Zig.
nine_k 6y ago
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.
- da_big_ghey 6y ago
  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.
  - Aeolun 6y ago
    I think that’s a very apt comparison. It’s good too, since it means we’ll eventually get to quite a nice place.
  - overflyer 6y ago
    That would bei Jai :D
    - da_big_ghey 6y ago
      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.
- amedvednikov 6y ago
  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.
hajhatten 6y ago
Never heard of V before, now I'm super excited. Congratulations on the 0.2 release!
Jenz 6y ago
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 https://christine.website/blog/vlang-update-2020-06-17
- amedvednikov 6y ago
  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).
  - kaba0 6y ago
    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.
    - amedvednikov 6y ago
      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).
      - 6y ago
senorsmile 6y ago
I just heard about and starting looking into V last night. This is perfect timing!
hota_mazi 6y ago
Code sample on the landing page would be nice. Here is Tetris in V: https://github.com/vlang/v/blob/master/examples/tetris/tetris.v https://github.com/vlang/v/blob/master/examples/tetris/tetri...
- amedvednikov 6y ago
  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.
mozarik 6y ago
I learn Go by Learn-go-with-tests. Maybe you guys should do it too.
- amedvednikov 6y ago
  We have an extensive documentation page that is pretty much a tutorial: https://github.com/vlang/v/blob/master/doc/docs.md https://github.com/vlang/v/blob/master/doc/docs.md
tarkin2 6y ago
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!
- amedvednikov 6y ago
  Yes, it does! :) This is a frequently asked question, so I had it covered. Things V improves on Go: https://vlang.io/compare#go https://vlang.io/compare#go
  - parhamn 6y ago
    The excluded parts I'd be interested in is cross-compiling + concurrency. Awesome work, sure it will get there either way :)
    - amedvednikov 6y ago
      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.
      - tandr 6y ago
        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)
        ylluminate 6y ago
tomcam 6y ago
A tcc backend is mentioned—can someone point me to that? P.S. This language looks amazing
- amedvednikov 6y ago
  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.
yawn 6y ago
From: https://vlang.io/compare#go 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.
- pwdisswordfish4 6y ago
  > goto language As in ‘considered harmful’? I’m staying away from any language with vulnerabilities like these: https://christine.website/blog/OVE-20190623-0001 https://christine.website/blog/OVE-20190623-0001
  - rsa25519 6y ago
    That looks like a vulnerability in a V playground, not a vulnerability in the V language itself.
    - pwdisswordfish4 6y ago
      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)?
      - t0astbread 6y ago
        So what do you think about Linux after the kernel.org hack?
  - coldtea 6y ago
    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?
antoineMoPa 6y ago
Does this language have a package management tool?
- animal_spirits 6y ago
  Yes, it is called vpm https://vpm.vlang.io/ https://vpm.vlang.io/
- amedvednikov 6y ago
  Yes! It's called vpm. v install ui
mrath 6y ago
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?
- ylluminate 6y ago
  Be sure to pop into Discord to chat further (https://discord.gg/vlang 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.
luxxuor 6y ago
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?
- amedvednikov 6y ago
  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().
adamzapasnik 6y ago
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?
awinter-py 6y ago
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
arthurcolle 6y ago
What parts of this are closed source again?
- amedvednikov 6y ago
  None.
  - arthurcolle 6y ago
    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?
himujjal 6y ago
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!
reikonomusha 6y ago
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) https://en.m.wikipedia.org/wiki/EC_(programming_language) [2] https://ec-lang.org/overview/ https://ec-lang.org/overview/
- jlokier 6y ago
  > 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.
anthk 6y ago
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
- ylluminate 6y ago
  Be sure to pop into #help on https://discord.gg/vlang https://discord.gg/vlang and/or push a ticket with `v doctor` output.
Aardappel 6y ago
Congrats to V on implementing the compile time memory management technique from http://aardappel.github.io/lobster/memory_management.html http://aardappel.github.io/lobster/memory_management.html, like you mentioned on Discord. Would be nice if you would credit it, though.
- mratsim 6y ago
  Nim has merged first class view types and their lifetime tracking: - https://github.com/nim-lang/RFCs/issues/178 https://github.com/nim-lang/RFCs/issues/178 - https://nim-lang.org/docs/manual_experimental.html#view-types https://nim-lang.org/docs/manual_experimental.html#view-type...
  - Aardappel 6y ago
    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.
deleted 6y ago
[deleted]
112 6y ago
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!
tutfbhuf 6y ago
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.
st3fan 6y ago
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.
- vlang1dot0 6y ago
  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.
  - st3fan 6y ago
    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.

247 points by 0xedb 6y ago

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

amedvednikov 6y ago
Then you'd have no way to differentiate between declaration and assignment, and have all the problems that brings. Hello, Python :)
- layer8 6y ago
  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.)

amedvednikov 6y ago

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 ?

socialdemocrat 6y ago

On my bucket list to check out. Still stuck on trying out Zig.

nine_k 6y ago

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.

da_big_ghey 6y ago
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.
- Aeolun 6y ago
  I think that’s a very apt comparison. It’s good too, since it means we’ll eventually get to quite a nice place.
- overflyer 6y ago
  That would bei Jai :D
  - da_big_ghey 6y ago
    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.
amedvednikov 6y ago
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.

hajhatten 6y ago

Never heard of V before, now I'm super excited. Congratulations on the 0.2 release!

Jenz 6y ago

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 https://christine.website/blog/vlang-update-2020-06-17

amedvednikov 6y ago
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).
- kaba0 6y ago
  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.
  - amedvednikov 6y ago
    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).
    - 6y ago

senorsmile 6y ago

I just heard about and starting looking into V last night. This is perfect timing!

hota_mazi 6y ago

Code sample on the landing page would be nice. Here is Tetris in V: https://github.com/vlang/v/blob/master/examples/tetris/tetris.v https://github.com/vlang/v/blob/master/examples/tetris/tetri...

amedvednikov 6y ago
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.

mozarik 6y ago

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

amedvednikov 6y ago
We have an extensive documentation page that is pretty much a tutorial: https://github.com/vlang/v/blob/master/doc/docs.md https://github.com/vlang/v/blob/master/doc/docs.md

tarkin2 6y ago

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!

amedvednikov 6y ago
Yes, it does! :) This is a frequently asked question, so I had it covered. Things V improves on Go: https://vlang.io/compare#go https://vlang.io/compare#go
- parhamn 6y ago
  The excluded parts I'd be interested in is cross-compiling + concurrency. Awesome work, sure it will get there either way :)
  - amedvednikov 6y ago
    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.
    - tandr 6y ago
      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)
      - ylluminate 6y ago

tomcam 6y ago

A tcc backend is mentioned—can someone point me to that? P.S. This language looks amazing

amedvednikov 6y ago
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.

yawn 6y ago

From: https://vlang.io/compare#go 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.

pwdisswordfish4 6y ago
> goto language As in ‘considered harmful’? I’m staying away from any language with vulnerabilities like these: https://christine.website/blog/OVE-20190623-0001 https://christine.website/blog/OVE-20190623-0001
- rsa25519 6y ago
  That looks like a vulnerability in a V playground, not a vulnerability in the V language itself.
  - pwdisswordfish4 6y ago
    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)?
    - t0astbread 6y ago
      So what do you think about Linux after the kernel.org hack?
- coldtea 6y ago
  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?

antoineMoPa 6y ago

Does this language have a package management tool?

animal_spirits 6y ago
Yes, it is called vpm https://vpm.vlang.io/ https://vpm.vlang.io/
amedvednikov 6y ago
Yes! It's called vpm. v install ui

mrath 6y ago

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?

ylluminate 6y ago
Be sure to pop into Discord to chat further (https://discord.gg/vlang 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.

luxxuor 6y ago

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?

amedvednikov 6y ago
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().

adamzapasnik 6y ago

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?

awinter-py 6y ago

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

arthurcolle 6y ago

What parts of this are closed source again?

amedvednikov 6y ago
None.
- arthurcolle 6y ago
  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?

himujjal 6y ago

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!

reikonomusha 6y ago

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) https://en.m.wikipedia.org/wiki/EC_(programming_language) [2] https://ec-lang.org/overview/ https://ec-lang.org/overview/

jlokier 6y ago
> 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.

anthk 6y ago

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

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

Aardappel 6y ago

Congrats to V on implementing the compile time memory management technique from http://aardappel.github.io/lobster/memory_management.html http://aardappel.github.io/lobster/memory_management.html, like you mentioned on Discord. Would be nice if you would credit it, though.

mratsim 6y ago
Nim has merged first class view types and their lifetime tracking: - https://github.com/nim-lang/RFCs/issues/178 https://github.com/nim-lang/RFCs/issues/178 - https://nim-lang.org/docs/manual_experimental.html#view-types https://nim-lang.org/docs/manual_experimental.html#view-type...
- Aardappel 6y ago
  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.

deleted 6y ago

[deleted]

112 6y ago

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!

tutfbhuf 6y ago

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.

st3fan 6y ago

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.

vlang1dot0 6y ago
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.
- st3fan 6y ago
  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.