V is an [[MIT License]] licensed [[Transpiling Programming Language]] targeting [[C]] which is self-hosted (bootstrapped in [[3. Reference/Software/Programming Languages/C|C]]). - [Website](https://vlang.io/) - [Source](https://github.com/vlang/v) - [Documentation](https://github.com/vlang/v/blob/master/doc/docs.md) - [Package Registry](https://vpm.vlang.io/) - [Wikipedia](https://en.wikipedia.org/wiki/V_(programming_language)) > Despite being simple, **V** gives a lot of power to the developer and can be used in pretty much every field, including systems **programming**, webdev, gamedev, GUI, mobile, science, embedded, tooling, etc. # Notability It is a small, fast, low level programming language that compiles down to a very compatible set of C which allows it to be used to write programs for nearly every piece of hardware or software to exist in the last 50 years. No semicolons required! Apparently was originally developed for [[Volt Instant Messenger]]. # Philosophy > It's similar to Go and its design has also been influenced by Oberon, Rust, Swift, Kotlin, and Python. \- Official Documentation ## Controversy > Tons of people were saying the same thing before Volt was released. “It’s impossible to have a 200 KB Slack client. You are a scammer.” It seems that the main reason that V got a lot of hate early is simply that it seemed to do things that were too good to be true. Yet, as far as I'm aware, it actually does *most* of those things. Some of them were a little buggy or incomplete when first released - but things usually are - and have since been fixed. Some people have claimed that the lead developer `amedvednikov` is allergic to criticism and has banned people for it, but that claim doesn't seem to hold water. He does admit to deleting posts, but I honestly don't blame him. > I deleted 2 posts that were repeating the same points and contained misinformation. [[Zig]]'s developer was pitching a fit on HackerNews that V's was making almost as much on [[Patreon]] as him despite V being a new language. That seemed to be the crux of his ire - simply that V made outrageous claims and was making money. Yet, those claims were *true* (or at least mostly true). Various [[Odin]] developers (`gingerBill`, `Kelimion`, `dotbmp`) also threw a fit on a Github issue, making wild accusations. But even the complaints themselves belied a very narrow version of the world, which V's developer *rather politely* refuted point by point. An Odin dev later claimed that V's dev was "lashing out" and I think that is ridiculous. I think V's dev handled the intense attack really well. The lead V dev `volt_dev` *has* been "suspended" from Reddit, not sure why. ## No Runtime Claim > V doesn't need runtime information to decode JSON, because it achieves it via codegen. All information about types is known at compilation time. A lot of people have complained about this claim. But I think it is at least partially unfair. For most languages with a runtime library, there is a kind of extra overhead, lots of functions, often dead code hanging off of the distributable. In the ideal case V only uses code in the place you ask for it and only if you need it by using simple techniques. This would be tedious to do by hand, but is entirely possible to do, and V frontloading it for you makes it easy. However, there are still some [issues](https://github.com/vlang/v/issues/20126) and small programs often end up with far more code than they need. It can still be faster than using the standard libraries in C, even though that sounds impossible, because it never has to do all the extra work at runtime that C does, because it can optimize it in place at compile time. It's just a completely different way of thinking about programming languages than most other language designers are familiar with. But it is not impossible. It's just a different paradigm. ## No AST Other language devs also say this is impossible. It really isn't though. There's a lot of different ways to represent and transform code. Code doesn't need to be rendered into a traditional AST to accomplish those tasks. I've done it. But most books and classes teach it as the only way. ## Doom in Under a Second A great many people pointed out how "impossible" this was and ignored everything else. Yet, with an appropriate pipeline and pre-formatted code, it is. And V does it. > Clang compiles 200k lines of sqlite.c in 1 second. The problem was that V's dev was talking about the results of an unreleased project at the time and since people couldn't replicate it, they were understandably skeptical. It is a build with little to no optimization from the C backend, but *that isn't important*! Why not? Because during development you care about rapid compilation to test and iterate. The release build pipeline being slower doesn't really matter all that much. People were somehow inferring that "builds fast" meant "builds a fully optimized binary fast" and those are two very different claims. Yet [[Go]] was allowed to get away with claims like that because of the Google-centric marketing. ## Memory Management This is the one thing that critics have kinda right. V's dev thought that they were going to have solved the `autofree` problem pretty quickly, but it is still experimental years later. > Autofree is still WIP. Until it stabilises and becomes the default, please avoid using it. Right now allocations are handled by a minimal and well performing GC until V's autofree engine is production ready. > it can be enabled with `-autofree`. It takes care of most objects (~90-100%): the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via GC. [[Go]] made similarly outrageous claims about [[Garbage Collection]] (and many other capabilities of the language) and even silently changed their roadmap to remove references to embarrassing early claims, yet I hardly ever see anyone mention any of it. [[Swift]] also claimed that it didn't need GC because of an `autofree`-like system. It turned out it was just a standard reference counting GC with some compile-time hints. Despite this I never heard such a campaign of hate directed against it. Over time Swift removed references to its "fallback" GC, and retains unresolvable memory usage anomalies to this day. To me, V having only a partial solution is not even slightly on the same level as [[Go]]'s complete lies. It's not that I think that V's dev being overly optimistic about solving this problem should not be taken into account when considering it, just that the amount of rage around it is disproportionate. Progress continues and commits mentioning `autofree` are still coming in. Though it has been *years* and it seems that because GC performance is so good that the core devs are far less worried about it. As an aside: I've seen a lot of the same complaints leveled at GC time and time again, but surprisingly little evidence. Perhaps some of these people are building hard real-time systems, but I rather doubt it. I think it's just a white whale, the mythical way to manage memory without any work and without any overhead. I'm sure it will be largely figured out eventually, though I do wonder if it will be worth all of the effort. Of course that won't stop me from experimenting with implementing `autofree` myself at some point in the future I'm sure. # Platform Support ## OS Support In theory supports any OS or platform that has a compliant [[C]] compiler does, but its stdlib does not equally support every combination and not all are tested. > Here is a list of the operating systems, supported by V: (CI tests runs on every commit/PR for each of these): \- V's Build Documentation[^1] - Linux - Mac - Windows (some stdlib features [missing](https://github.com/vlang/v/blob/master/examples/readline/readline.v)) ## Secondary OS Support > The compiler is known to also work, and has support for these operating systems also (although we do not test it as regularly as for the above) \- V's Build Documentation[^1] - `vinix` - `ios` - `android` - `termux` - `freebsd` - `openbsd` - `netbsd` - `dragonfly` - `solaris` - `serenity` - `haiku` - `plan9` - `wasm32` - `wasm32-wasi` - `wasm32-emscripten` ## ISA Support - [[AMD64]] - [[ARM|ARM64]] - [[ARM|AARCH64]] - [[RISC-V|RISCV 64]] - [[s390x]] There is an [issue](https://github.com/vlang/v/issues/18737) with closures on some architectures right now, but active work is being done to identify the appropriate assembly code to make them work on these other ISAs. - [[POWERPC]] - [[POWERPC64]] - [[MIPS]] - [[SPARC|SPARC64]] ## Other [[Universal CTAGS]] supports V, so no special configuration is required. # Features # Example ## Fibonacci Sequence ```c // This program displays the fibonacci sequence import os fn main() { // Check for user input if os.args.len != 2 { println('usage: fibonacci [rank]') return } // Parse first argument and cast it to int stop := os.args[1].int() // Can only calculate correctly until rank 92 if stop > 92 { println('rank must be 92 or less') return } // Three consecutive terms of the sequence mut a := i64(0) mut b := i64(0) mut c := i64(1) println(a + b + c) for _ in 0 .. stop { // Set a and b to the next term a = b b = c // Compute the new term c = a + b // Print the new term println(c) } } ``` # Resources - [Awesome V](https://github.com/vlang/awesome-v) - [Forum](https://github.com/vlang/v/discussions) - [Roadmap](https://github.com/vlang/v/blob/master/ROADMAP.md) - [[Aixt]] a V-like language for embedded use ## V Libraries - for [[Redict]] - https://github.com/einar-hjortdal/redict # References - https://blog.siwei.dev/post/implementing-linked-lists-in-vlang/ - https://github.com/v-analyzer/v-analyzer ## Old Complaint Threads - https://www.reddit.com/r/vlang/comments/kyrs9h/how_does_v_compare_to_zig/ - https://www.reddit.com/r/programming/comments/atoq8e/v_is_a_new_language_touting_very_fast_compilation/ - https://www.reddit.com/r/rust/comments/b1ih91/v_language_new_programming_language_inspired_by/ - https://www.reddit.com/r/rust/comments/b1ih91/v_language_new_programming_language_inspired_by/ - https://github.com/vlang/v/issues/35 - https://news.ycombinator.com/item?id=21296855 - https://christine.website/blog/v-vaporware-2019-06-23/ - Some of the shit in this article are so absurd and unfair that my mind is blown - "So the compiler with "zero dependencies" is a _dynamically linked binary_ with dependencies on libpthread and libc" lol ## Footnotes [^1]: https://github.com/vlang/v/blob/54f7c36acac9b97da0c117251edd39000b8167e5/vlib/v/help/build/build-c.txt#L136