HN user
It has an automated release generated every week. The could be no commit activity whatsoever and there would still be 52 "releases" of V every year.
It's one thing to like V but it's another to constantly repeat misleading information in an attempt to give it more credence than it has.
Even V's own changelog only contains 28 releases (mostly from the 0.1 era in 2019 - early 2020) not "hundreds" like you've claimed.
I don't see how that really follows. V heap allocates any value which is address taken. You don't need to be an advanced C programmer to use pointers.
They've been working on C2V for a long time now and even still it falls over quickly for anything other than the exact version of doom they are using. Multiline comments crash the tool for instance.
You only merged it one hour ago.
https://github.com/vlang/v/pull/14805
Over promising (hardly a one line patch) and under delivering (well beyond your "it will be fixed today" statement) as usual.
Did you even bother to read what he pasted? Tcc is used in the first set of commands that do not terminate.
How's that "one line" fix in the type checker coming? Looks like it wasn't fixed yesterday.
Your demo includes code that uses manual memory management because of autofree bugs.
https://github.com/vlang/ved/blob/9b85e6291c9fe9135db1e300de...
Yes, technically you can do that but it makes no sense from a design point of view to have a language that cares so much about safety it adds a borrowing system but then says "fuck it" to type safety.
You have to have type safety to have memory safety and that was the whole point of Rust.
If the US gov decides to project its will on your software project, an ISO standard is not going to help you at all. They will sabotage the ISO process, or force your hosting provider (GitHub) to remove your project or apply changes to it, or just kidnap your maintainers and beat them with wrenches until they comply[0].
If your threat model legitimately considers the US gov to be a hostile actor, you need far more than a piece of paper that claims what the behavior of your compiler is.
I see about 1k lines of new tests, probably 500-600 lines of build system integration across various files, nearly 1k lines of cargo lock file information for dev dependencies and the Rust code appears to be more highly commented than the C code was.
Sounds to me like you already decided what your conclusion was and are just looking for data to back it up without actually analyzing it.
According to the article:
YJIT is a relatively simple JIT compiler that totals about 11,000 lines of C code.
So no actual response to objective criticism just "my interpretation is things are going well so they can claim anything they want"? Wow, what a compelling argument you make!
If you want to look at GitHub, sure let's do that. I see perhaps 5 regularly active contributors, many more who seem to have left the community, and a downward slope of commit activity starting in April 2020. Hardly some vast hub of activity like your comment would suggest.
Given autofree has been practically untouched in 6 months with no major bug fixes to speak of, reality would seem to be that V is on the slow road to nowhere. At the current rate of progress, I doubt we'll see 0.3 before mid 2023 and 1.0 perhaps sometime in the 2030s. It's been 6 months since anything was completed on the 0.3 checklist: https://github.com/vlang/v/commits/master/ROADMAP.md
Are you arguing it's fairer to say V's default is to ignore managing memory at all?
So, you're saying C2V is closed source then? Which is exactly what Alex said isn't true.
Really?
- No null
Then what is `voidptr(0)`?
- No global variables
https://github.com/vlang/v/blob/master/doc/docs.md#global-va...
At least add "by default" to the web site.
- No undefined values
Which is done by initializing all values to 0. Probably not a good idea to do that for references though. (See also "no null values")
- No undefined behavior
`*voidptr(0)` is accepted by the compiler. Unsigned integer overflow is accepted by the compiler and UB in the generated C. How can V generate C code free of UB when it can't even generate C code that compiles all the time?
- Pure functions by default
Excluding I/O, one of the biggest sources of impurity, from your definition of pure is useless.
- Generics
You don't actually have generics, you have templates. Kind of ironic since Go has actually added generics before V has managed to get a 0.3 release out. The distinction is this: with generics the compiler is able to validate that the generic code type checks prior to substitution/monomorphization. With templated code, it's not possible to perform type checking until the concrete types have been instantiated. V implements templates with all the drawbacks including code bloat and inflated compile times that comes with it.
So how do you plan to make autofree work without move semantics, an ownership model or borrowing annotations? If your answer is "like Lobster", then how do you plan to deal with the semantic differences between those languages which the Lobster model relies on?
No, "it's fast because it's C" doesn't hold. You can write slow code in any language.
Could you point to the C2V source?
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)
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...
This feels intentionally ignorant of the state of Rust considering there is more funding and more people paid to work directly on Rust than any prior point in the project's entire history.
Rust is not governed by the Rust Foundation. Rust is governed by the Core Team and the teams under them.
I'm pretty sure sed could have saved them the trouble.
Budget doesn't really have anything to do with it. The vast majority of people on a team or working group aren't paid to work on Rust; they're volunteers.
I don't see how that follows. Declarative build configuration is very good and Rust needs to lean harder in that direction and minimize the use of build.rs.
The foundation is funding oncall support staff for crates.io which was a much more urgent need than funding more devs.
Amazon, Microsoft, Huawei, Google and Futurewei are all now employing a good chunk of the devs to work on it full time.
Not sure I'd point to C++ of all things as being free from the concerns of large corporations lol. This is just such an uninformed take.
Yeah given the general responses from other people involved with the project, Steve seems pretty far out on a limb here.
V was also self hosted (written in V) from the start, which says a lot about the maturity of the language.
How could that possibly be true? You need a V compiler to compile V but none would have existed "from the start".
You've also said multiple times on Discord that the original V compiler was written in Go.
Frankly it's rather amusing.
The languages you've listed generally work as advertised and while you might dislike some of the design decisions or tradeoffs inherent in those decisions, ultimately, they do what they claim to.
The same cannot be said of V.