6 ms·

Here are the summarized V features for anyone who dislikes salestalk: - small binaries and fast compilation - cross-platform support - cross-compil

Here are the summarized V features for anyone who dislikes salestalk: - small binaries and fast compilation - cross-platform support - cross-compilation - cross-platform drawing library (GDI+/Cocoa Drawing, OpenGL) - native GUI toolkits (V-UI) - value types - auto-free engine that adds necessary free() commands - C transpilation (both ways, allegedly emits human-readable C) - C foreign function interface ("V can call C Code and any language with C-interop can call V Code") - hot-code reloading (not mentioned how, but probably dynamic library hot swapping) - package manager - autoformatter - profiler - documentation-from-source generator - V-to-JavaScript/WASM transpilation - built-in testing framework - built-in web framework (vweb) - ORM ("you can just write V instead of SQL while interacting with databases") Some tools in pure V: Vinix - An open-source Operating System that can already run GCC, Bash, V etc. Volt - A 300Kb native desktop client for Slack, Discord, Skype, Gmail, Twitter, Facebook, and more. (only supports MacOS at the moment) VSQL - A single-file SQL database written in pure V with no dependencies. Gitly - Open-source light and fast alternative to GitHub/GitLab, written entirely in V. Vorum - Right now it's a very basic forum/blogging software, but in the future, it will be a full-featured light alternative to Discourse. The V forum runs on Vorum. Vgram - A bot library for Telegram Bot API.

lawl 5y ago
i'm pretty sure that half of these features don't work. Such as the famous "autofree" where everyone doubted it could work and the solution now was.... to drop in boehm-gc. for anyone unfamiliar with v, take everything on that list with a giant spoon full of salt.
- amedvednikov 5y ago
  autofree demo: V's compile time memory management demo. Running the Ved editor on an 8 MB file with 0 leaks. https://www.youtube.com/watch?v=gmB8ea8uLsM https://www.youtube.com/watch?v=gmB8ea8uLsM
  - lawl 5y ago
    Yes, we know, this is always your reply. We also know that boehm-gc is just temporary until you fixed the issues with autofree. Do let me know when that happens.
    - amedvednikov 5y ago
      Well you said it doesn't work, which is not true. You also claimed this about half of the features on the list, which is also not true. Regarding autofree/gc, here's a good summary from another comment here: https://news.ycombinator.com/item?id=31060052 https://news.ycombinator.com/item?id=31060052
    - Tozen 5y ago
      There isn't any reason why Vlang can't have both autofree and boehm-gc. I don't understand the "must be this or that only" logic being applied to it. Other popular programming languages also have multiple memory management options, and so can Vlang.
- Daunk 5y ago
  This has very much been the case for me when trying out V. It advertises some great features that just barely works in the right circumstances.
  - amedvednikov 5y ago
    Can you give an example of features that barely work for you?
- cyber_kinetist 5y ago
  The solution V seems to apply here is a bit more nuanced than that. They’re going in roughly the similar direction as Nim did with the new ORC, which is essentially keeping the GC but try to do some compiler analysis to insert free() calls at compile time as much as it can using scope-based memory management and move semantics. The confusing thing about V is that these design decisions aren’t written properly on the docs, so the author’s claims might feel like “selling snake oil” although it’s already implemented in another language with great success. It would have been much better if the creator of V had acknowledged any previous work done on the topic. Also, the choice of Boehm GC is a little bit disappointing, but understandable since it’s basically the easiest garbage collector you can stick it into a language (without designing your own GC). Maybe this will change later on. Though I’m still not confident enough on the usability and stability of the language. Almost all claims of the usability/stability of the language seems to come from the main creator himself, I would like to hear some takes from people other than him who have used the language in any serious form.
  - amedvednikov 5y ago
    > keeping the GC but try to do some compiler analysis to insert free() calls at compile time as much as it can This is correct. > Also, the choice of Boehm GC is a little bit disappointing Which one would you recommend? > Almost all claims of the usability/stability of the language seems to come from the main creator himself The creators of Vinix and vsql don't have any issues with the usability/stability.
    - convolvatron 5y ago
      >> Also, the choice of Boehm GC is a little bit disappointing >Which one would you recommend? boehm is conservative. this is a costly and very unnecessary implementation for a language which already has a compiler and knows explicitly which values are pointers.
      - amedvednikov 5y ago
        Thanks, will investigate. We'll have our own GC in the future anyway.
- anecd0te 5y ago
  I assumed that there was a English language barrier from the original author that made the mistake of present versus future tense for the feature list. When combined with a lack of feature tracking that looked to people like big claims were made without substance, but to me it always felt like everything in V was "work in progress." They definitely have a hacker mindset to get the minimum working examples through and keep on developing, which is admirable in some ways. The downside is I don't think there's a lot of development experience hanging around that project, so things stick to minimal implementations.
  - saghm 5y ago
    I've never been able to quite understand what was going on with V (and the associated messenger client Volt written in it), but it seems to be something a bit more complicated than just a language barrier. I made a habit of checking the Volt website for a while out of interest in using the project, and it was somewhat surreal how fast the documented timeline would change. There was a super specific timeline in terms of what month features would land out as far as 2-3 years (e.g. "support for $os in $current_year + 2, open source in $current_year + 3), and but then as the months went by, the items on the timeline would not land, and the timeline would get revised pushing things out with no announcement of any sort. The platforms that were supported seemed to be constantly changing; one month there would be a Windows binary with Mac and Linux listed as "coming soon", and then the next month, there would be a Mac one but the Windows one was gone with no explanation. Charitably, I think the developer had fairly unrealistic expectations for how future work would progress and probably a lack of focus on following the plan they had publicly stated. I don't _think_ there was any malicious intent, but ultimately I felt like I wouldn't be able to trust that the products would be reliable if/when they did end up releasing and lost interest in following the timeline.
    - anecd0te 5y ago
      > There was a super specific timeline in terms of what month features would land out as far as 2-3 years (e.g. "support for $os in $current_year + 2, open source in $current_year + 3), and but then as the months went by, the items on the timeline would not land, and the timeline would get revised pushing things out with no announcement of any sort. That just strikes me as youth and inexperience
- Tozen 5y ago
  > i'm pretty sure that half of these features don't work. That's just bashing. It's one thing to actually use something and criticize, its another to not even use the language and assume things. > Such as the famous "autofree" where everyone doubted it could work and the solution now was.... to drop in boehm-gc. Autofree is still part of Vlang. Also, many other languages have multiple methods of memory management. Which many argue is a good thing. Take for example, Nim, which has several (see below). Yet, I have never seen anybody at HN lose their minds over it and bash Nim about it. Nim has: gc:refc, gc:markAndSweep, gc:boehm, gc:go, gc:arc, etc... So exactly why can't Vlang have both AutoFree and GC? Yeah, the correct answer is that it should not be a problem. And as a newer developing language, they should be allowed to experiment to find what works best, as the other languages before it.
Ristovski 5y ago
I am still wondering why Volt, the native desktop client for Slack/Discord et al only supports MacOS when V boasts about cross-platform support and cross-compilation.
vlang1dot0 5y ago
The reason V is so controversial is that it separates nearly everyone who looks at it into two diametrically opposed groups: those who have some experience or knowledge of programming language design and implementation and those who do not. The first group are generally the "detractors" and view every concession made to the impossible set of features as a reinforcement of their belief that the language cannot work as advertised. The second group sees every concession as a step closer to the eventual goals, sure that it's simply a matter of time and one more bug fix until the promised result is achieved. Because of this dichotomy, there cannot be completely objective discussion about the language. I would strongly urge anyone thinking of spending time on V to first examine it closely and see if it holds up to detailed scrutiny. In my opinion, V does not and the author knows this but deliberately pretends otherwise for his own personal gain. Of course, you should not solely take my word for this any more than you should take Alex's to the contrary. Consider, if it really was so easy to build a language with the speed of C, the ease of use of Python and the simplicity of Go, why haven't those languages with orders of magnitude more funding simply done so? There are fundamental tradeoffs to language design and it's clear the author does not understand this. The core problem with V is that while many language implementations tread a middle ground between the "just get an MVP out so users can give feedback; ship fast, ship often; as long as it works" engineering mindset and the "ivory tower" academic mindset, V picks the former while giving the finger to a burning pile of compiler books. The author appears willfully ignorant of the basic tecnhiques used to build compilers even going so far as to state that V won't use an abstract syntax tree because "AST is going to require lots of extra CPU power and RAM" [1]. The author later discovered that implementing an AST was actually necessary to make developing the compiler easier and made the compiler faster not slower as he originally proclaimed [2]. A few notes on the advertised feature list: - cross-compilation Cross compilation in V depends on having a C compiler toolchain present for the given target. That is to say, V's cross-compilation story is exactly the same at present as C's is. I'm sure some one will mention the "native backend" which has recently started to be able to build "hello world" without miscompilations. Until such time as it is able to build even slightly complex programs, this is a complete non-sequitur. - native GUI toolkits Native in this context means "compiled code", not that it uses the platform's native UI toolkit. V-UI draws it's own components to the screen and does not use native platform libraries at all other than to open a drawing surface. - auto-free engine that adds necessary free() commands Autofree does not work anywhere close to as well as advertised. Autofree will both leak memory in trivial programs [3] [4] [5] [6] as well as introduce use-after-free and double-free Undefined Behaviors [7] [8] [9] [10]. The autofree Ved demo required changes to Ved to work around autofree's broken state [11]. Autofree cannot work as well as advertised (90%+ of variables handled automatically, down from 100% orignally) without extensive inter-procedural analysis which doesn't exist [12] and would destroy V's compiler performance claims if it did. For anyone who still thinks there might be something to autofree, please explain how this logic for inserting a call to free could possibly be sound [13]: mut af := g.is_autofree && !g.is_builtin_mod && node.op == .assign && node.left_types.len == 1 && (node.left[0] is ast.Ident || node.left[0] is ast.SelectorExpr) - profiler The profiler works by adding instrumentation calls to every function generated in your binary [14]. This can completely change the performance of your program and invalidates the results produced. No mention of this problem exists anywhere in the documentation. In conclusion, people need to stop treating this as some kind of serious up-and-coming language and instead see it as the massive pile of poorly implemented hacks it is. [1]: https://github.com/vlang/v/issues/1255#issuecomment-513565054 https://github.com/vlang/v/issues/1255#issuecomment-51356505... [2]: https://github.com/vlang/v/issues/4128 https://github.com/vlang/v/issues/4128 [3]: https://github.com/vlang/v/issues/14033 https://github.com/vlang/v/issues/14033 [4]: https://github.com/vlang/v/issues/13821 https://github.com/vlang/v/issues/13821 [5]: https://github.com/vlang/v/issues/13539 https://github.com/vlang/v/issues/13539 [6]: https://github.com/vlang/v/issues/12201 https://github.com/vlang/v/issues/12201 [7]: https://github.com/vlang/v/issues/13554 https://github.com/vlang/v/issues/13554 [8]: https://github.com/vlang/v/issues/13398 https://github.com/vlang/v/issues/13398 [9]: https://github.com/vlang/v/issues/12455 https://github.com/vlang/v/issues/12455 [10]: https://github.com/vlang/v/issues/12453 https://github.com/vlang/v/issues/12453 [11]: https://github.com/vlang/ved/commits?author=medvednikov&before=0cc6d72b6ac12724ec424a47f8611b7ca9d7f948+35 https://github.com/vlang/ved/commits?author=medvednikov&befo... [12]: https://github.com/vlang/v/search?q=is_autofree https://github.com/vlang/v/search?q=is_autofree [13]: https://github.com/vlang/v/blob/704e3c6e7275336b5b4f8da2743871f1ee7d5b25/vlib/v/gen/c/assign.v#L30-L33 https://github.com/vlang/v/blob/704e3c6e7275336b5b4f8da27438... [14]: https://github.com/vlang/v/blob/3fa9128716cdc8a794b2ec0be4fb2be454ea25ee/vlib/v/gen/c/profile.v https://github.com/vlang/v/blob/3fa9128716cdc8a794b2ec0be4fb...

lawl 5y ago

i'm pretty sure that half of these features don't work. Such as the famous "autofree" where everyone doubted it could work and the solution now was.... to drop in boehm-gc. for anyone unfamiliar with v, take everything on that list with a giant spoon full of salt.

amedvednikov 5y ago
autofree demo: V's compile time memory management demo. Running the Ved editor on an 8 MB file with 0 leaks. https://www.youtube.com/watch?v=gmB8ea8uLsM https://www.youtube.com/watch?v=gmB8ea8uLsM
- lawl 5y ago
  Yes, we know, this is always your reply. We also know that boehm-gc is just temporary until you fixed the issues with autofree. Do let me know when that happens.
  - amedvednikov 5y ago
    Well you said it doesn't work, which is not true. You also claimed this about half of the features on the list, which is also not true. Regarding autofree/gc, here's a good summary from another comment here: https://news.ycombinator.com/item?id=31060052 https://news.ycombinator.com/item?id=31060052
  - Tozen 5y ago
    There isn't any reason why Vlang can't have both autofree and boehm-gc. I don't understand the "must be this or that only" logic being applied to it. Other popular programming languages also have multiple memory management options, and so can Vlang.
Daunk 5y ago
This has very much been the case for me when trying out V. It advertises some great features that just barely works in the right circumstances.
- amedvednikov 5y ago
  Can you give an example of features that barely work for you?
cyber_kinetist 5y ago
The solution V seems to apply here is a bit more nuanced than that. They’re going in roughly the similar direction as Nim did with the new ORC, which is essentially keeping the GC but try to do some compiler analysis to insert free() calls at compile time as much as it can using scope-based memory management and move semantics. The confusing thing about V is that these design decisions aren’t written properly on the docs, so the author’s claims might feel like “selling snake oil” although it’s already implemented in another language with great success. It would have been much better if the creator of V had acknowledged any previous work done on the topic. Also, the choice of Boehm GC is a little bit disappointing, but understandable since it’s basically the easiest garbage collector you can stick it into a language (without designing your own GC). Maybe this will change later on. Though I’m still not confident enough on the usability and stability of the language. Almost all claims of the usability/stability of the language seems to come from the main creator himself, I would like to hear some takes from people other than him who have used the language in any serious form.
- amedvednikov 5y ago
  > keeping the GC but try to do some compiler analysis to insert free() calls at compile time as much as it can This is correct. > Also, the choice of Boehm GC is a little bit disappointing Which one would you recommend? > Almost all claims of the usability/stability of the language seems to come from the main creator himself The creators of Vinix and vsql don't have any issues with the usability/stability.
  - convolvatron 5y ago
    >> Also, the choice of Boehm GC is a little bit disappointing >Which one would you recommend? boehm is conservative. this is a costly and very unnecessary implementation for a language which already has a compiler and knows explicitly which values are pointers.
    - amedvednikov 5y ago
      Thanks, will investigate. We'll have our own GC in the future anyway.
anecd0te 5y ago
I assumed that there was a English language barrier from the original author that made the mistake of present versus future tense for the feature list. When combined with a lack of feature tracking that looked to people like big claims were made without substance, but to me it always felt like everything in V was "work in progress." They definitely have a hacker mindset to get the minimum working examples through and keep on developing, which is admirable in some ways. The downside is I don't think there's a lot of development experience hanging around that project, so things stick to minimal implementations.
- saghm 5y ago
  I've never been able to quite understand what was going on with V (and the associated messenger client Volt written in it), but it seems to be something a bit more complicated than just a language barrier. I made a habit of checking the Volt website for a while out of interest in using the project, and it was somewhat surreal how fast the documented timeline would change. There was a super specific timeline in terms of what month features would land out as far as 2-3 years (e.g. "support for $os in $current_year + 2, open source in $current_year + 3), and but then as the months went by, the items on the timeline would not land, and the timeline would get revised pushing things out with no announcement of any sort. The platforms that were supported seemed to be constantly changing; one month there would be a Windows binary with Mac and Linux listed as "coming soon", and then the next month, there would be a Mac one but the Windows one was gone with no explanation. Charitably, I think the developer had fairly unrealistic expectations for how future work would progress and probably a lack of focus on following the plan they had publicly stated. I don't _think_ there was any malicious intent, but ultimately I felt like I wouldn't be able to trust that the products would be reliable if/when they did end up releasing and lost interest in following the timeline.
  - anecd0te 5y ago
    > There was a super specific timeline in terms of what month features would land out as far as 2-3 years (e.g. "support for $os in $current_year + 2, open source in $current_year + 3), and but then as the months went by, the items on the timeline would not land, and the timeline would get revised pushing things out with no announcement of any sort. That just strikes me as youth and inexperience
Tozen 5y ago
> i'm pretty sure that half of these features don't work. That's just bashing. It's one thing to actually use something and criticize, its another to not even use the language and assume things. > Such as the famous "autofree" where everyone doubted it could work and the solution now was.... to drop in boehm-gc. Autofree is still part of Vlang. Also, many other languages have multiple methods of memory management. Which many argue is a good thing. Take for example, Nim, which has several (see below). Yet, I have never seen anybody at HN lose their minds over it and bash Nim about it. Nim has: gc:refc, gc:markAndSweep, gc:boehm, gc:go, gc:arc, etc... So exactly why can't Vlang have both AutoFree and GC? Yeah, the correct answer is that it should not be a problem. And as a newer developing language, they should be allowed to experiment to find what works best, as the other languages before it.

Ristovski 5y ago

I am still wondering why Volt, the native desktop client for Slack/Discord et al only supports MacOS when V boasts about cross-platform support and cross-compilation.

vlang1dot0 5y ago

The reason V is so controversial is that it separates nearly everyone who looks at it into two diametrically opposed groups: those who have some experience or knowledge of programming language design and implementation and those who do not. The first group are generally the "detractors" and view every concession made to the impossible set of features as a reinforcement of their belief that the language cannot work as advertised. The second group sees every concession as a step closer to the eventual goals, sure that it's simply a matter of time and one more bug fix until the promised result is achieved. Because of this dichotomy, there cannot be completely objective discussion about the language. I would strongly urge anyone thinking of spending time on V to first examine it closely and see if it holds up to detailed scrutiny. In my opinion, V does not and the author knows this but deliberately pretends otherwise for his own personal gain. Of course, you should not solely take my word for this any more than you should take Alex's to the contrary. Consider, if it really was so easy to build a language with the speed of C, the ease of use of Python and the simplicity of Go, why haven't those languages with orders of magnitude more funding simply done so? There are fundamental tradeoffs to language design and it's clear the author does not understand this. The core problem with V is that while many language implementations tread a middle ground between the "just get an MVP out so users can give feedback; ship fast, ship often; as long as it works" engineering mindset and the "ivory tower" academic mindset, V picks the former while giving the finger to a burning pile of compiler books. The author appears willfully ignorant of the basic tecnhiques used to build compilers even going so far as to state that V won't use an abstract syntax tree because "AST is going to require lots of extra CPU power and RAM" [1]. The author later discovered that implementing an AST was actually necessary to make developing the compiler easier and made the compiler faster not slower as he originally proclaimed [2]. A few notes on the advertised feature list: - cross-compilation Cross compilation in V depends on having a C compiler toolchain present for the given target. That is to say, V's cross-compilation story is exactly the same at present as C's is. I'm sure some one will mention the "native backend" which has recently started to be able to build "hello world" without miscompilations. Until such time as it is able to build even slightly complex programs, this is a complete non-sequitur. - native GUI toolkits Native in this context means "compiled code", not that it uses the platform's native UI toolkit. V-UI draws it's own components to the screen and does not use native platform libraries at all other than to open a drawing surface. - auto-free engine that adds necessary free() commands Autofree does not work anywhere close to as well as advertised. Autofree will both leak memory in trivial programs [3] [4] [5] [6] as well as introduce use-after-free and double-free Undefined Behaviors [7] [8] [9] [10]. The autofree Ved demo required changes to Ved to work around autofree's broken state [11]. Autofree cannot work as well as advertised (90%+ of variables handled automatically, down from 100% orignally) without extensive inter-procedural analysis which doesn't exist [12] and would destroy V's compiler performance claims if it did. For anyone who still thinks there might be something to autofree, please explain how this logic for inserting a call to free could possibly be sound [13]: mut af := g.is_autofree && !g.is_builtin_mod && node.op == .assign && node.left_types.len == 1 && (node.left[0] is ast.Ident || node.left[0] is ast.SelectorExpr) - profiler The profiler works by adding instrumentation calls to every function generated in your binary [14]. This can completely change the performance of your program and invalidates the results produced. No mention of this problem exists anywhere in the documentation. In conclusion, people need to stop treating this as some kind of serious up-and-coming language and instead see it as the massive pile of poorly implemented hacks it is. [1]: https://github.com/vlang/v/issues/1255#issuecomment-513565054 https://github.com/vlang/v/issues/1255#issuecomment-51356505... [2]: https://github.com/vlang/v/issues/4128 https://github.com/vlang/v/issues/4128 [3]: https://github.com/vlang/v/issues/14033 https://github.com/vlang/v/issues/14033 [4]: https://github.com/vlang/v/issues/13821 https://github.com/vlang/v/issues/13821 [5]: https://github.com/vlang/v/issues/13539 https://github.com/vlang/v/issues/13539 [6]: https://github.com/vlang/v/issues/12201 https://github.com/vlang/v/issues/12201 [7]: https://github.com/vlang/v/issues/13554 https://github.com/vlang/v/issues/13554 [8]: https://github.com/vlang/v/issues/13398 https://github.com/vlang/v/issues/13398 [9]: https://github.com/vlang/v/issues/12455 https://github.com/vlang/v/issues/12455 [10]: https://github.com/vlang/v/issues/12453 https://github.com/vlang/v/issues/12453 [11]: https://github.com/vlang/ved/commits?author=medvednikov&before=0cc6d72b6ac12724ec424a47f8611b7ca9d7f948+35 https://github.com/vlang/ved/commits?author=medvednikov&befo... [12]: https://github.com/vlang/v/search?q=is_autofree https://github.com/vlang/v/search?q=is_autofree [13]: https://github.com/vlang/v/blob/704e3c6e7275336b5b4f8da2743871f1ee7d5b25/vlib/v/gen/c/assign.v#L30-L33 https://github.com/vlang/v/blob/704e3c6e7275336b5b4f8da27438... [14]: https://github.com/vlang/v/blob/3fa9128716cdc8a794b2ec0be4fb2be454ea25ee/vlib/v/gen/c/profile.v https://github.com/vlang/v/blob/3fa9128716cdc8a794b2ec0be4fb...