[bheadmaster]

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]

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.

[cyber_kinetist]

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]

> 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]

>> 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]

Thanks, will investigate.

We'll have our own GC in the future anyway.

[Tozen]

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

[anecd0te]

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]

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]

> 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

[Daunk]

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]

Can you give an example of features that barely work for you?

[amedvednikov]

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

[lawl]

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]

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

[Tozen]

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.

[Ristovski]

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]

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

[2]: https://github.com/vlang/v/issues/4128

[3]: https://github.com/vlang/v/issues/14033

[4]: https://github.com/vlang/v/issues/13821

[5]: https://github.com/vlang/v/issues/13539

[6]: https://github.com/vlang/v/issues/12201

[7]: https://github.com/vlang/v/issues/13554

[8]: https://github.com/vlang/v/issues/13398

[9]: https://github.com/vlang/v/issues/12455

[10]: https://github.com/vlang/v/issues/12453

[11]: https://github.com/vlang/ved/commits?author=medvednikov&befo...

[12]: https://github.com/vlang/v/search?q=is_autofree

[13]: https://github.com/vlang/v/blob/704e3c6e7275336b5b4f8da27438...

[14]: https://github.com/vlang/v/blob/3fa9128716cdc8a794b2ec0be4fb...

[super_flanker]

Thanks for taking time and explaining things around v's state of affairs.

Also I'd like to add that V's first feature, "no null" is a myth. V supports initializing a reference with 0, which is null/nil or whatever you call it.

I'm pretty sure v's author will not bother responding to a well laid out facts.

[Tozen]

Actually, V's author was gracious enough to come to HN to address and answer a number of users (including on this thread). This includes that he has previously answered questions by vlang1dot0 (on other threads), despite repeated attempts at spreading misinformation or the obvious and continual trolling (with just the username alone).

If you notice, HN doesn't have zig1dot0, nim1dot0, or odin1dot0 accounts trolling any threads they can find pertaining to the language or alluding to why they aren't at 1.0 yet. Despite the fact that both Zig and Odin started around 2016 (3 or more years before Vlang) and have yet to achieve 1.0. Zig only managed self-hosting this year (2022), after more than 6 years of existence. Nim took 11 years to reach 1.0 (created 2008 to achieved 1.0 in 2019).

Add to this, the incessant and demonstrably false claims that V is vaporware or fake despite it having over 90 releases, applications written in it, and thorough documentation about the language.

https://github.com/vlang/v/releases (releases) https://github.com/vlang/v/blob/master/doc/docs.md (documentation) https://modules.vlang.io/ (modules)

By the way, types in V are zeroed by default. Zeroed means that they are assigned default values. Empty string for string types, 0 for integers, and false for Boolean types. When not sure what to initialize variables with, it is recommended to make them mutable, so to be updated as needed. In V, you don't assign null or nil. There isn't any *ptr = NULL or Var := nil. That is the context in which they are referring to.

[Tozen]

First, nobody should take what you have posted as an honest assessment, because your username is for the explicit purpose of trolling. Running around with the name "vlang1dot0", demonstrates a commitment to being a hardcore troll and spreading misinformation.

As with any attempt at propaganda and misinformation, you are taking elements of truth and then greatly distorting it to fit your agenda. Which is possibly to hurt your competition, because of developing or being heavily invested in a competing language. It would be much more honest to come out and say what your preferred language is and what your involvement with it is, than to put on a troll costume and do hit posts.

> ...Because of this dichotomy, there cannot be completely objective discussion about the language.

No, you have created a false dichotomy. You can not be objective, because of your bias and possible investment in other languages.

> 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?

This is a straw man argument. It would be like someone saying, "If the car was really such a good idea, why wasn't it invented by the Egyptians back in 1000 BC? They had plenty of gold and engineers."

Programming languages are built upon and borrow from each other. It is the prior existence of C, Python, and Go that something new which is blended from various elements of each, with various new concepts added, can be created. Thus we can have Vlang and various other newer languages.

-Cross compilation

You didn't refute that Vlang can do it, but rather it doesn't meet your preferences. So damn what it makes use of C compilers, for now or as an option in the future? So have other languages. Not to mention, Vlang has very strong interop with C, to begin with.

And they are working on the native backend, which is producing results, and will only get better. It must also be kept in mind how young Vlang is as a language, which started from 2019. So its level of progress and popularity is arguably amazing, and has surpassed a number of its rivals. It is asinine to compare a language of such young age to those from say 2008 or the 1990s, who at the same comparative stages were less advanced.

- native GUI toolkits

Again, you are spouting out your preferences. Furthermore, Vlang has a number of GUI wrapper libraries. Such as: vsdl/vsdl2, vig (ImGui), vnk (nuklear), viup (IUP), etc... If a person doesn't want to use the VUI (written in V), they can hop over to a bunch of others.

- Autofree

The developers have repeatedly said that it wouldn't be ready until 0.3 of the language. It exists and functions, but they are working on improving it, which is not anything unusual at this stage. People can disable it with -noautofree, and do manual memory management. There is -prealloc too. There is also GC (-gc boehm).

The developers have stated there would be a few memory management options, of which there will be at least -autofree and -gc boehm. Not sure why certain people are getting their panties all twisted, when a number of other programming languages also have multiple memory management options, to include those languages having had all kinds of development problems and they still have issues.

- GitHub Issues

This is probably the more ludicrous part of your post. All popular programming languages on GitHub will have a long list of issues. The more popular, the more you will see. For example, Rust has nearly 8,000 OPEN issues. If someone listed them all on HN, would they win any points?

The true point is that issues submitted, are those that contributors and developers work on to resolve. Using an open issue as a reference to attempt to prove a language is somehow deficient is very, very deceptive. That's a problem they are fixing and will usually fix (sooner or later), or discover it's not really an issue as user error. More importantly, is how useful those users, supporters, and contributors feel the language is. That's why Vlang is constantly gaining in popularity, despite angry detractors and competitors.

Troll hit jobs will simply not stop Vlang, and just reflects an odd desperation in wishing it would. Whatever programming language that you prefer or are developing, it should be able to stand on its own merits, without the need for trolling others.