The V Programming Language 0.4
vlang.io
vlang.io
Maybe someday I should try learning V again. I was going to learn it over the summer of 2020 to expand my repertoire beyond C++, but I gave up fairly quickly and ended up learning Qt instead, which has proved to be a very wise choice - knowing Qt why I have my current job (for multiple reasons).
Seems to me they're trying to dog food the project which makes sense to me.
So showcasing what the language and compiler can do is a bad thing?
transpiling to C actually makes adoption much easier. if you create an entirely new compiler auditing and verifying that takes many years and tons of money before it can be used for anything serious.
Well, maybe.
I like transpiling to C because it brings with it all the hyper-optimisation that has gone into C compilers over decades.
As a solo on-again/off-again language designer, I can attest that you really cannot fixate on language purity or similar stuff like that: the goal is to write a program in your new language as soon as possible, and implement the features that motivated you to create a new language in the first place.
Transpiling to C is, in practice, no different from transpiling to assembler, with the advantage of portability and instant environment support (can call C libraries).
I've got a featurelist I'd like to implement. Focusing on emitting machine-code or assembly eats away valuable time I could have instead used to create a feature, or 10.
Why? Correct me if I’m wrong but this language has literally no unique attributes that would make it different than D or Go, so you won’t improve as a developer from it at all.
Not trying to dissuade you from it, afaik most of the initial false claims have been debunked and now V is a real thing, but what is left from it is.. really not that interesting to my eyes.
I'm not familiar with D, but compared to Golang, it seems to have a bunch of goodies compared to it. Small list: immutability by default for lots of things, no null, small and fast compiler, "4 ways to manage memory", hot code reloading and repl.
These are just the ones I could find on a quick skim, I'm sure there is more.
> Not trying to dissuade you from it
You are literally saying that it's not "interesting to my eyes" but then before that you say "you won’t improve as a developer from it at all", how is this not trying to dissuade someone?
Go's compiler is famously fast, isn't it? I don't know about small, but that only seems relevant if you're working on the compiler itself.
> "4 ways to manage memory"
People complain about D having 2 ways to manage memory, so isn't this twice as bad?
I'm intrigued that you compared V to D. I'm a huge fan of D, and I'd be interested in hearing why you made that comparison.
It does, a lot: https://vlang.io/compare#go
Adding some of that back to V only “fixes” where Go went wrong, so I would need something additional on top to consider this language.
Just for one thing: focus on simplicity and fast builds.
There are dynamic languages with zero compile times, but Java builds just as fast for me as Go and it is a much more expressive language than Go, which is a shame.
Not from my experience. Go is a breath of fresh air in this over-engineered complex industry.
Go promotes simplicity and speed, and so does V.
Not every program is a basic CLI app with 3 network requests, and the only tool we have against complexity is abstractions.
You don't need complex langs to write software.
Not understanding the need to be dismissive of someone else's plans. Part of the fun of programming is checking things out, if we maintain an open-mind.
> this language has literally no unique attributes that would make it different than D or Go, so you won’t improve as a developer from it at all...
Such a statement can be perceived as highly inflammatory. V clearly has different features from D and Go. Additionally, V is among the most popular programming languages on GitHub[1], based on stars. And has been so for some years now. Other people clearly use and experiment with it. What you and I like, doesn't mean that others don't or can't have different preferences.
To note, refereed link is only about the language repo and not as language used for making projects.
Such as? I’m open to changing my mind, but didn’t see anything notable on the official website’s listed differences between V and Go.
> Additionally, V is among the most popular programming languages on GitHub
Come on, not even you believe that! There are clearly more projects written in goddamn Coq out there than V, it is such a niche language currently..
V can produce JavaScript, and it has an interpreter, but those are pretty experimental features. V has built in markup templates (like Mustache but worse), basic built in JSON reflection (D's CTFE can implement this), and built in portable inline SQL (for some reason), but that might be less desirable than targeting one specific ORM with its entire feature set. V also has a built in Sokol shader compiler, and can run `.vsh` files in a special script mode that works very slightly differently than normal V, but those aren't exactly killer features compared to D imo.
"They" are many different people (developers or contributors). As an open-source project, people focus on what they like or may need.
Furthermore, V has a native backend, in addition to others: C, JavaScript, WASM, etc... They've stated (on their website) that their plan is to eventually make the native backend the primary, as they close in on 1.0. The other backends can be seen, for those that have actually used or know of the language, by checking out the -b flag.
It is important to note that (at the time of writing this comment) the native backend can compile only three examples in the `examples/` directory in the V compiler codebase:
hello_world.v
fizz_buzz.v
rune.v
This is m first time seeing this language 'V'. So no pre-baggage.
The splash page is making extraordinary claims.
But a lot of languages have the same features, but not the big claims like size and speed.
So what is this group doing different that couldn't be done in Rust or Go or dozen others.
Do we need another language? Or if there is just 'one simple trick', then just update the others.
If it is 80% GO, then why wouldn't the GO team just incorporate this 'whatever it is'.
or- Can someone explain it to me like i'm 5 what is the big idea under the hood here.
Talking specifically about Go, how much time did it take for Go team to acknowledge and make some workarounds to support generics? And this is not a new concept it exists for more than 30 years. I can not imaging Go actually developing and incorporating new things, it is a simple and "completed" language.
V doesn’t even have that, so there are like 10 languages just like that with slightly different syntax.
And I don't think every new language has to have some unique feature too. You can compare almost any modern "scripting" language for example to Common Lisp and ask why they exist, but they do and they enable lots of developers just fine.
But V fails to make me interested on this count as well.
Either that or V author is up for a few ACM turing awards.
That is mainly because of how it is organized. tcc also compiles itself fast, because of how it works, and how it is organised.
That other compilers, like rustc, gcc or clang can not do it, because they have other priorities/tradeoffs, is their problem.
Each line of what?
are they comparing how long it takes for each platform P to compile v sources or P sources ?
V can not compile C or Go, Go can not compile C, and C compilers can not compile V or Go, so it can not be otherwise.
No header files hell for example.
https://mawfig.github.io/2022/06/18/v-lang-in-2022.html
Many of the claims were false at the start. Some were fixed, some are in the "extraordinary research needed" category.
I can test the claims in the article in 5 years.
I have a 90% chance that V will no longer be active, i.e. no active development happening.
I'd love to be proven wrong though, but I'll only find out in 2028.
We're not going anywhere :)
You can check the number of commits over the last 4 years.
That's what everyone says (https://ourincrediblejourney.tumblr.com/).
Only time will tell. I'm not in a rush to use a new language, so as I said above, I can run the ultimate test.
I can check back on V in 5 years from now, if it's still around.
Good luck!
For example, the following code from the article still leaks with autofree:
[heap]
struct MyHeapValue {
value i64
}
fn draw_text(value MyHeapValue) {
}
fn main() {
// ...
arg1 := MyHeapValue { 42 }
arg2 := MyHeapValue { 100 }
draw_text(arg1)
draw_text(arg2)
// ...
}
It is still relevant that autofree does not work on heap-allocated structs. In particular, this is relevant to the day-to-day usage of the V programming language.
Whether this is well-documented by V itself does not change that it is relevant, in my opinion.
The normal "day-to-day" situation would be to have the GC on or as fallback, and to do otherwise (like -gc none or -prealloc), one should know what they are doing or be prepared to deal with such issues.
Those parts of the review, considered relevant in normal usage were resolved:
https://github.com/vlang/v/issues/14803
https://github.com/vlang/v/issues/14787
https://github.com/vlang/v/issues/14786
But even beyond that, the intent of the so-called review was arguably malevolent. It was not done in good faith, to be helpful to the developers or community, but done to spur on drama (thus adding the vaporware link and spamming it) and knowingly looking for ways to bash an alpha version of the language.
I am simply pointing out that a single claim from the article is still relevant to how V functions today. To be more specific, the still-relevant claim is: "So forcing the value to be allocated on the heap reveals that autofree leaks the values."
The post I am replying to did not say "almost none of the claims in this article are relevant now," it specifically said "none" without qualification.
Maybe I am just unusual in how I use the English language, but I would unquestionably consider this to be a case where you should really qualify the word none, because otherwise it's just not true.
Whether autofree is completely in alpha and intended not to be used or not, the claim from the article that it doesn't work for everything is relevant. I don't see how it couldn't be.
Surely if autofree is WIP, it's no big deal to simply agree that the fact it doesn't work on heap-allocated structs is relevant to its current state?
Now, to be clear, I am aware that arguing over a single extremely small point is, to some degree, missing the point of the comment I was originally replying to. But this is also just how I talk about things on the internet. If part of your claim is untrue, even to an extremely minor degree, I will point that out. This is why when I personally claim things, I almost always qualify what I am saying. (See? Even here I said "almost always," because I just naturally add qualifications so as not to overstate my case).
I don't know about a long-term plan, but it seems that V will now need one if there isn't already one. Many languages start out fresh and either die out (metaphorically) or get crushed on their own features. Planning seems to be necessary to avoid either fates, and yet is not sufficient to guarantee survival. I personally witnessed this from D firsthand back when a stdlib divide was threatening its future, and believe every successful language author need to answer this question (for example, Rust would say the coevolution with Servo was massively beneficial). So Alex---or other core developers if any---, do you have any thoughts on this?
We don't plan to die. There's no language that ticks all V's checkboxes:
- simple
- fast to compile
- C/C++ perf
- fits all domains
- flexible memory management (gc, manual, autofree in the future, arena)
- batteries included
- readability and development speed of python, C perf
etc
"Simple"---and yet usable---is very hard to define and achieve. If the language has to fit all domains, it seems that the best approach is to identify versatile, multi-use features (better explained by Guy Steele's Growing a Language talk). And such features are relatively uncommon! So most languages tend to have many features only for specific uses and pray that they don't clash with other features, i.e. ditching the simplicity. It is not really impossible, but I'd rather have it as a guiding principle other than a mission.
"Fast to compile" is good to have, but I hope you to use it just as a guide as well. The critical threshold is the apparent interactivity (about 100 ms), and anything faster than that is not worthwhile as is. Slow languages can also create an illusion of interactivity with many efforts (e.g. incremental compilation), so you would rather want to identify and avoid the global cause of latency. For example header files have a large impact on C/C++'s compilation speed, even when everything is cached and using loglinear algorithms or faster. I think V got a general idea right, so don't be too fixated about concrete numbers.
"C/C++ perf" needs more quantification. First of all, many C/C++ programs are actually slow for many reasons. It is just that many performance-sensitive programs were also written in C/C++. Many other languages tend to use other related statements like "no language runtimes", "no hidden control flows" or "no allocations". Not very satisfactory, but still better because they imply actual actions. And please be aware that this goal is in general directly contradictory to the simplicity, another reason to ditch it...
"Fits all domains" is what I'm most unsure about. I believe attempts to write everything in V are related, but they won't ever be sufficient (let's talk about writing a proof-certified mathematical routine :-). Many languages provide the extensibility as a primary solution, but it is not enough---I mean, unless you think PyTorch tracing CPython bytecode and producing a fused CUDA kernel as extensibility. Many domains do share common requirements in terms of programming, so multi-paradigmatic approaches would scale better... unless new programming paradigm can be hard to retrofit to the existing language. (Lisp doesn't count because it generates a family of languages.) As a concrete goal, I think you should instead pick a small number of distinct domains and advertise as "fits many domains" instead.
"Flexible memory management" is probably the easiest to achieve. Existing languages are surprisingly hard to mix and match multiple memory management schemes primarily because they didn't start with multiple schemes after all. (I believe a GC extension of Rust will be extremely valuable in this regard.) This is something V can directly provide now, keep pursuing it.
"Batteries included" is a cross-cutting concern that touches on almost all other missions except for performance. While this has been one of Python's mottos, it is evident that Python's "batteries" are now too old. Thankfully this issue is also relatively well-understood: you need a good package manager and standard libraries should also use that machinary. Many consider Cargo as the model solution, though not every aspect is appreciated (e.g. single identifier namespace, YMMV). Ironically though Rust itself didn't have Cargo at the beginning, so its standard library situation is not actually ideal. But at least you have a good example to agree or disagree with.
"Readability and development speed of python" is half the anti-simplicity and half the tooling concern. Readability is as subjective as simplicity and development speed has two factors (global and local), where global factor is more about the modularity problem, so let's consider the tooling, the local factor. Tooling is something people like to have and no one likes to appreciate at the same time. It is one of the most labor-intensive tasks in PL and, while you can prepare for them in advance, the actual work needs to be done one by one until approaches like JetBrain MPS become much more viable. It can however happen completely independently from the language development itself as well, so I believe it's of less concern.
The last thing I want to say is that, it's fine to miss all those checkboxes! Many languages are mediocre in all aspects and yet still useful and popular. Some languages even develop a completely unexpected niche out of nothing, like JavaScript and Python. You may still want to retain some good characteristics (which by itself would be an impressive achievement), but you can't know in advance whether they were worthwhile or not. So checkboxes are not as important as they seem---the perseverence to keep them in sight is more important.
It does seem to be still in its very early stages but if they are able to make this a more mature library, it may actually be quite useful for tiny, fast apps.
- Effort applied; To be tailored for certain kinds of projects; Solve problems in existing languages; Approaches to prevent/force adoption of beta quality project; Philosophical approaches behind project or lack thereof.
Now on the personal, subjective note, the more I look, the more I want to avoid V and get my hands on Jai [1][2]
[1] https://github.com/Jai-Community/Jai-Community-Library/wiki/... [2] https://github.com/Jai-Community/Jai-Community-Library/wiki/...
You can pass `-cc gcc` to use another C compiler for example, instead of tcc.
There is also a native backend, that generates executables directly, without generating C, then using a C compiler to compile it. You can use `-b native` to try it, instead of the more developed C backend. Note that the native backend, is still work in progress though and it does not support some language constructs.
Is this hatred still present?
Has anyone used the language extensively that can comment on its usability?
> I'm sure you'll like it!
And what's wrong with this comment?
I'd like you to elaborate on this instead. Were there many articles with explicit death threats?
Only the author of the vaporware articles said that, AFAIK.
That is your interpretation of what is being said, where "prove to be something viable" is being added, and graciously giving the benefit of the doubt to the person who wrote the statement.
I took it, as possibly many others, as "ignore V until it dies". Thus, "V should die", would also be near enough to the intent, malice, and vitriol be conveyed. If someone said something similar to me or about something I created, "Ignore X until it dies", would not interpret it as anything other than ill intent.
> I would like to see this situation result in a net improvement for everyone involved. V is an interesting take on a stagnant field of computer science, but I cannot continue to comment on this language or give it any of the signal boost I have given it with this series of posts.
This exactly aligns with what she said in the comment I quoted (the only addition is "[V] should be ignored", which is another way to say "no more signal boost"). You are free to disagree with my interpretation, but your interpretation doesn't seem to explain this paragraph.
---
> If someone said something similar to me or about something I created, "Ignore X until it dies", would not interpret it as anything other than ill intent.
I also have my share of people saying mean things to me (as I've said elsewhere, I also went through lots of shitposts), and I learned that I have only a finite amount of time to deal with them. Salvage what you can learn from them (positive or not), but otherwise minimize useless interactions because it is often the case that actually I was at fault, or even that no one is at fault and the human language is just so imperfect. I believe the latter was indeed the case for aforementioned reasons.
(In the case anyone wondering why I'm trying to interact this much then, I still want V to be successful and my experience suggests that no one said something like my comments so far. It is sort of a folk knowledge and many take or assume it granted, but it has to be learned and few will tell you that fact.)
> > I'm sure you'll like it!
> And what's wrong with this comment?
It's interesting how you deliberately avoided quoting part of the comment. One could potentially interpret that as you being deliberately misleading.
I hope the language or another like it eventually can fill this niche. I’ve been dreaming of a similar language myself..
Like complaining that V depends on OpenGl, Git, libc, and electricity!
If you've been dreaming about a language like this, give it a try. Spend 20 minutes on it, and form your opinion.
I'm sure you'll like it!
Note: I’m interested in V but not involved in V development.
Various competing languages use reddit as a forum, because their language didn't previously have one or their developers didn't open up discussions on GitHub. Evangelists of competing languages can be allowed to bash, flame, or troll opposing languages on various subreddits.
If they outnumber a rival language, in a place they often congregate and the mods will allow such behavior, then they can get away with typing the most outrageous or foul statements for points. It came become a bash and troll festival, and anyone that dares oppose, can get intentionally downvoted away or punished by their mods who have control.
People that are casuals or don't know what's going on behind the scenes, may see only their side. There is often no balanced discussion. Any opposing view points to the false accusations, extreme negative positions, misinformation, or wrong statements may not be allowed to be seen.
Arguably? According to who? What evidence supports such a claim?
Notably the criticism died down a little (from the Zig author in particular) when the Vlang devs backed off some of the more outlandish claims and correctly added "WIP" labels to them instead of implying that they were actually working and implemented. So the Vlang devs/community at the time at least recognized they were doing something wrong in how they were communicating their work; although today in this thread it seems like they are trying to back peddle.
I have not spoken about anyone being a salty rival, whatever that means.
Thanks in advance.
The words in quotes are from what appear to be ambassadors of the V language here on HN. If you feel they don’t represent your community, maybe ask them to stop brigading instead of asking me to shut my mouth? Just another example of the V community I guess…
If you have some problem, you can simply address people individually, without attacking an entire community of many, that share a common interest in a programming language.
The people you send are the people who represent all of you. Sorry if you think that's unfair, but that's the reputation you're building. That's not on me, that's on you.
All people on HN are individuals, not some kind of a collective Borg.
Here's an example on how to properly evangelize on HN: https://news.ycombinator.com/item?id=37252231
Note they didn't call anyone "salty", "delusional", or accuse them of engaging in a vindictive campaign against them. Take notes. Have a great day.
It is the same, as asking you to not talk about all Australians, all Chinese or all Bulgarians, when you mean the actions of specific people/individuals.
That is all I am asking for, and I think that is not difficult to understand.
A lot of what was going on initially, was coming from obvious competitors and evangelists, to include being uncivil, inflammatory, and directly insulting. The initial "criticism" was not so much that, but false accusations of the language being a scam, vaporware, fraud, or didn't really exist. To include attacks and jealousy over donations, rising popularity, and having supporters. This was not any kind of "valid" criticism, that the creator or contributors of the language could reason about with instigators.
The "criticism" never died down, but rather V was open-sourced and established itself on GitHub. The initial series of false accusations could not stand nor could the support it was getting be stopped. So, the rhetoric and targets shifted to whatever could be found to go after on the newly released alpha version of the language and its new website. In that new mix of what was being thrown at it, there were indeed some very valid criticisms, as can be found with any new language and many sites.
Constructive and valid criticism, is not the same as insults, trolling, misinformation, rivalry, or false accusations. There is clearly a difference. It's disingenuous to pretend something from one group is the same as the other, or that the intent behind what is being done is not different.
You’re not going to change my mind that the initial promises were outlandish unless you implement them (you haven’t yet in 4 years), and claiming today they weren’t (as Alex is) is literally the worst approach you could take to build trust in your language. People weren’t mad about V they were mad about the exaggerations, prevarications, shifting explanations, aggressive tone, and now gaslighting from the V author. And if you turn it back around on me yet again you’re proving my point.
Well, that's because the reason behind the criticism was never really the language. It was the attitude of its author and proponents. Sadly, this very thread proves that that attitude has not changed [1] one bit, so it's no wonder the criticisms remain.
> The initial "criticism" was not so much that, but false accusations of the language being a scam, vaporware, fraud, or didn't really exist.
Backlash is to be expected whenever extraordinary claims get made with nothing to back them up. Apparently V is supposed to be able to translate entire C & C++ projects to V and run as fast as C, but with memory freed automatically by the compiler. Now, combine such impossible claims with the initial unavailability of the source code, asking for donations, refusing to elaborate on how exactly this would work, and the fact that none of is is true even today.
That's because none of the outrageous claims are possible. They weren't possible back when V was announced either and when the programming community immediately pointed it out, the response was the same as we've seen in every thread since then - gaslighting.
It's one thing to make hopeful and starry-eyed, but misguided claims, it's another to double down on them, deny any mistakes, and play a victim.
A bunch of people attacked them based on that, calling out the inaccurate statements. The group included the creator of Odin, a competing language.
Right in the sense that it can take a really long time to release a work in progress feature.
Wrong that some of the claims made initially were phantasmagorical and also debunked very quickly.
Also, vaporware is a a thing. I'm perfectly willing to stay by the claim that GNU Hurd will be useless to me until the day I die.
For reference GNU Hurd has been in "dev, design, planning and early implementation attempts" for 33 years, and I imagine I'll live 50 more years (fingers crossed!).
I can live with that.
I haven’t had the pleasure to try out V yet but I hope this discussion can rise above. Endless bickering leaves a sour taste in my mouth.
What, in your opinion, are legitimate reasons for someone to be upset with V?
How can you assert that they're misleading or highly interpretive wrongs if you haven't dug into them yourself and actually used V? All the negative press I've seen on V has been highly detailed and reproducible.
Whenever this topic comes up I’m at a loss to understand why anyone would waste so much energy mud slinging over some personal language project. It only makes sense if it’s become a hate meme. My pocket word for an event that’s a sort of social singularity. It occurs when enough popular voices have directed the entirety of a community to shame a target based on some perceived wrong, real or otherwise.
Wherever it comes up I’m pretty taken aback by how tribal and ego focused we can be, even among the smartest of us. And that thought isn’t meant be taken as condescending. After all, we’re only human. And for a larger span of human history, that word has meant “hairless ape” more than anything else.
Does the fact that he earns money off of Patreon by overpromising all the impossible features change your perspective on the matter?
> I haven’t had the pleasure to try out V yet
How can you know that the wrongs are misleading if you've never even tried the language?
I'm still waiting for that CS breakthrough to happen - Rust guys will be so mad they spent their time writing lifetime annotations for the borrow checker :)
> 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.
So most objects are freed by the autofree engine, and the rest are freed via reference counting. This implies that no objects are freed by the GC, which is exactly what I've said.
Please stop gaslighting people.
[0] https://web.archive.org/web/20210315092012/https://github.co...
RC was later replaced with a tracing GC.
RC is a type of GC btw, so...
The fact that the feature promised is impossible. I'm quoting some comments from which this whole discussion has started, since you don't seem to be able to follow:
> dgellow: They got lot of push back because what the core devs were describing Vlang to be was technically close to impossible
> amedvedikov: There were no close to impossible/missing features.
Static analysis (autofree) with reference counting, by itself, cannot theoretically free all of the objects during the runtime of the program. And I know that you know that since you've made the decision to switch to a tracing garbage collector.
The choice of tracing garbage collection makes the initial claim much less impressive and innovative - Go already has escape analysis, which is basically an implementation of autofree. But Go used a garbage collection from the start, so escape analysis is just an optimization - exactly what autofree is for the current V with GC.
V promised something impossible, it's not a big deal, we all make technical mistakes and learn from them. What makes it a big deal is your stubborn attempts to rewrite history and gaslight people.
It can't, that's what it says on the home page. Stuff that can't be freed during compile time is handled via GC.
What's the issue again? What's the impossible claim?
The documentation I've quoted and posted a source to specifically says that all objects are freed either by 1) autofree or 2) reference counting.
> What's the impossible claim?
The impossible claim is that all objects are freed either by 1) autofree or 2) reference counting. As I've mentioned, neither static analysis (which is what autofree is) nor reference counting is capable of completely freeing all unreachable objects at runtime - reference counting is in particular unable to handle cyclic references.
> What's the issue again?
The issue is you vehemently claiming that V has never, ever promised a feature that was impossible - which is false, as I've demonstrated and cited with reference to archive.org of V lang documentation. So can you stop doing that, please?
V never promised autofree without GC or RC.
Yes, because that version of documentation specified a feature that was impossible, which is exactly what we're discussing.
> V never promised autofree without GC or RC
First of all, I never mentioned "autofree without RC". I am strictly speaking about "autofree without GC".
Second of all, V documentation has had the "autofree frees 90% of objects, RC frees everything else" segment, which clearly implies no GC. So the documentation has clearly specified that feature, which was an impossible feature.
Even the next paragraph says:
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.
But gaslighting people and pretending that overly grandiose claims/promises haven't been made in the past leaves a bitter taste, and doesn't inspire trust in core developers. Instead, it makes me think that the core devs are incapable of admitting a mistake - which would make their language a hazard.
For example, what if V gets huge and a serious security bug gets discovered - how can I trust that the developers will properly communicate the existence of such a bug and not just keep quiet about it, consider how they aren't even willing to admit that V has made some impossible claims/promises in the past? If I discover a bug, will they also pretend that the bug doesn't exist, even when confronted with indisputable evidence, because it threatens to damage their reputation?
As long as that attitude doesn't change, I'm not touching V with a 10 foot pole.
See my numerous replies to you in this thread, where I have quoted the documentation, provided the archive.org link and explained why the claim is impossible.
Do you have any other argument except "nuh-uh, didn't happen, lol"?
No heavy GC tracing everything or expensive RC for each object.
What's your issue with the wording?
1) The first sentence clearly stated that:
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.
2) Your emphasis of "everything" seems to imply a contrast to Python or Go method of memory deallocation:
"It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything
Yes, and what's wrong with that? That's how it works now too, except RC has been replaced by a tracing GC.
March 2019
> No. V's memory management is similar to Rust but much easier to use. More information about it will be posted in the near future.
May 2019
> No. V manages memory at compilation time (like Rust). Right now only basic cases are handled. For others, manual memory management is required for now. The right approach to solve this will be figured out in the near future.
April 2020
> No. V manages memory at compilation, like Rust: vlang.io/docs#memory
August 2023
> You can look up vlang.io on web archive and see that it never said GC-less autofree
"The right approach to solve this will be figured out in the near future."
And it was figured out, and we now have what we have. It's described on the home page in detail. 4 ways to handle memory.
Why another new account?
Unless things changed drastically V lang, as described by their documentation, is a vapor ware.
Fair enough. But then, you should know false advertising by the language maintainer leaves an even bitterer one.
[1]: https://mawfig.github.io/2022/06/18/v-lang-in-2022.html
[2]: https://jalopnik.com/elon-musk-tesla-self-driving-cars-anniv...
[0]: Across the span of the 2019-2022.
git clone https://github.com/vlang/v
cd v
make
./v your_program.v
You can also download .zip releases from https://github.com/vlang/v/releases , without needing git. The .zips there are <15MB, and contain a prebuilt V executable, so you do not even need make to use it.
I count myself among the skeptics of V. Mostly because in the initial communications about it, some of the claims were hard to believe. For example, they used to claim that V was memory safe without GC, but also without borrow checker, and it was never explained how they achieved such thing. Now I see that they claim that the language is very similar to Go, so I assume that they went with a GC. That's really cool, I actually think that GCs are a massive boon for language ergonomics. But there remain some unexplained topics, for example, how is that they achieve being "free of data races" [1]. It's nice to see a new language in the area and I hope the language succeed. But I'll continue to be skeptical until I see proper explanation of some of their claims.
Maybe "scam" is a harsh claim, but "outrageous and frequently false claims made by devs lacking solid credentials to match them".
And there were several comments and articles debunking these claims.
To add to the strangeness of how its being mischaracterized, was the apparent jealousy (back in 2019) over the amount of donations that other developers got. Then for certain ones to have got so upset at getting less, they started to bash and publicly ask people to give them their money instead.
Somehow, it's OK for X to get money for their competing language, but it's "wrong" for Y to get money for their language.
There were a TON of red flags around V for at least 1 year after the initial announcement. Funding, exaggerated claims, etc.
I wish V the best of luck but the start wasn't something that inspired confidence in neutral observers like me.
It's also ethically wrong to engage in falsely labeling or making false accusations, such as "scam" or "vaporware". Particularly, when the actual intent or agenda is that such persons are detractors or competitors from rival languages.
Lastly, various financial supporters of the V language have even come on HN to tell and explain how proud they are of the language and the progress it has made. Despite detractors and competitors, V is still making fantastic progress, and that's great to see.
> Particularly, when the actual intent or agenda is that such persons are detractors or competitors from rival languages.
V was not open-sourced when the accusation was made, and there were probably two or three people qualifying your description of "rivals" (even after assuming bad intents). Stop diluting the context.
> Lastly, various financial supporters of the V language have even come on HN to tell and explain how proud they are of the language and the progress it has made.
This is not different from how many investors to failed crowdfunding campaigns would behave before the actual failure. They will either acknolwedge risks (but few actually evaluate them) or "answer" every criticism with non sequiturs. It is not really their fault, but still useless as an evidence.
V has been open source since its public release on June 22, 2019.
On June 20, 2019 an early access build of the compiler was released.
This confusion should have been temporary and could have been easily resolved, but your reaction arguably made things worse. For example back then I actually asked you about the exact generic compilation strategy [1], and your answer was unnecessarily aggressive and content-free. It turns out that my later guess (to which you never replied) was right, i.e. the initial V compiler maintained a partial C code template that can be patched. If you had actually answered as such, people would have less reasons to disbelieve you because you have demonstrated a necessary understanding. This was also why other language developers were particularly harsh to you at the beginning.
I said you don't need AST to generate json serialization code.
What's the drama about?
> You have previously claimed that the V compiler uses no AST. However, most of the features that you claim would require a form of AST to even work, including generics and interfaces. [...] It's pretty much impossible to not have unless you have a very basic language or doing naïve transformations into another similar language.
You have misinterpreted this as follows:
> Claims like it's not possible to build features without AST or codegen json decoders are just ridiculous.
GingerBill pointed out that you have misread his comments and restated that:
> [...] if you language does not have an AST, which is technically possible, then you cannot have a lot of the features you have been advertising.
This is not saying "impossible". He is claiming that it is possible, but some features will be lacking. I considered this is inaccurate because he was unclear about which features will be affected, so I quantified the original claim as follows and asked you for the confirmation:
> For example, you can implement generics without an AST if you don't care about performance; [...] [T]hose features can be implemented without an AST, but an AST is a standard and reasonable way to do them and not using an AST would require a strong rationale. So what's that rationale? (And amedvednikov, this is my question for you.)
Now, I knew the discussion can often go awry even without bad intents and tried to make it constructive as much as I could. There were many reasonable answers, like "yeah, that's how I did and that makes compilation much faster" or "none of both, the compiler doesn't directly emit binaries". The latter would trigger other questions and at the end everyone could have a much better understanding of what the V compiler actually does.
Instead you replied:
> No you don't understand :) It's IMPOSSIBLE without AST. The Odin creator says so. That's why I'm a liar.
I still don't know why you said that. I even explicitly said that gingerBill has another misconception! You've said that you have no bad feelings to me, and I wish it's true, but this is a typical way to convey that you are angry at me (and gingerBill). "Aggression" generally refers to any action or response that makes someone else unpleasant, and your comment was clearly aggressive to me.
On the other hand, I can see why you have bad feeling about gingerBill. That's another reason I wanted to step in because confirmation bias is pervasive and continuous counterarguments are needed to avoid that---gingerBill initially didn't question your intents. I wanted to make you distracted and not vent your apparent anger by throwing another question, but it didn't work.
For that reason I chose to entirely ignore that paragraph in my reply and asked for the confirmation again, but you never replied back. Others may consider this as another evidence that you were indeed angry at me. I don't, to be explicit, but such an unnecessarily aggressive discourse is often colloquially called a drama.
----
I still can't believe I have to explicitly write this comment, but after multiple interactions I feel it's necessary and hope it helps. It is very hard to effectively communicate only with texts, and I had been there years ago. I only sort-of-learned this after decades of shitposting and fruitless debates. I believe one can learn this without all my hassles.
They were released 2 days before the source. It was just an early access thing.
There was also an announcement on Twitter.
> I, among others to which you still seem to have bad feelings
I don't know who you are, and I have no bad feelings towards you.
You really ought to clarify that YOU are the author.
V has been open-sourced, on GitHub, and downloadable since June 22nd of 2019. The language creator publicly stated he would put it out in late June, and did.
There was some excessive fuss about, around June of 2019, over a Patreon supporter early release. That was his right to do such a release, and it was specific for those supporters, but detractors were "angry" that it wasn't for them or open-sourced.
What some detractors were trying to do, was claim that V would never be released because it was somehow a "scam" or "vaporware". That is, there was nothing to release. They were of course wrong, because V was publicly released. That's when targets were switched or the goal posts moved. Anything that could be used to attempt to justify the earlier vitriol, inhibit the rising popularity, or hurt the public image of the language was used.
Furthermore, no programming language is released as a finished product. And an alpha version of any language, is understood by most, as work in progress (WIP) by default. There is no "scam" there. For open-source projects, any person is free to contribute, if they are really so technically knowledgeable as they claim or give the appearance of being. Everyone is free to donate or sponsor a project that they like, there's nothing nefarious about that.
[1] I should point out that vaporware can be a temporary status, that is, something can become a vaporware until it no longer is. So the exact pinpointing is necessary.