121–130 of 193 posts
Earlier quoted context omitted.
Problem? Is the communication not up to the author? And shouldn't people rather help out than just make demands on an open source project?
I don't have time to help every single open source project that makes bold claims. I also don't demand anything, I just moved V to my ignored list. It may be unfair, and I may take a look in a few years again if there are enough solid news about V floating around.
Earlier quoted context omitted.
FWIW bro I enjoy that you are building something so ambitious and making progress despite the unwarranted hate. I have no idea why you bring out so many visceral trolls. Can someone share why this guy and vlang are so hated? It seems like he is ironing out the kinks even years after the hate keeps piling on. He keeps this up he's going to win.
It's a communication problem. Looking at the homepage and the projects it feels like everything is ready and, if the claims were true, it would be the most ground breaking language of the last decades. When you go to look at the code or try to run something you find out: - some things are still closed source - some are broken - some are wins from C It's a great strategy for collecting a check from VCs and I wish the…
> No things are closed source. Never have been.
That's not correct. I seem to remember that when V was released initially, the compiler was available for download in binary form only. The source code was only released later on.
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…
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...
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
It's a communication problem. Looking at the homepage and the projects it feels like everything is ready and, if the claims were true, it would be the most ground breaking language of the last decades. When you go to look at the code or try to run something you find out: - some things are still closed source - some are broken - some are wins from C It's a great strategy for collecting a check from VCs and I wish the…
As I can't respond to amedvednikov's comment below, let me respond to it through yours (sorry): > No things are closed source. Never have been. That's not correct. I seem to remember that when V was released initially, the compiler was available for download in binary form only. The source code was only released later on.
So saying now 2.5 years later some things are closed source is ridiculous.
Earlier quoted context omitted.
> Not really, here's a benchmark of V compiling itself in 0.3 seconds that includes all steps (including the C -> binary part) and results in the compiler binary From what I've seen, you've used tcc for the benchmark, right? If so, that's kinda cheating, since tcc is written to be a simple as possible (and therefore as fast as possible), so the compilation time is essentially zero. Benchmarking with gcc with optimiza…
The same argument can be levied at any project that goes for a "don't use full LLVM for debug builds where iteration time and hence compile time speed is paramount". That includes projects like cranelift for Rust. I don't think it's reasonable to say this is a wholesale illegitimate/cheating approach. It has tradeoffs, for the project developer such as the burden of maintaining two significantly different paths for c…
Thank you for a voice of reason :)
Earlier quoted context omitted.
I applaud Alexander's efforts, but the hate is somewhat warranted, because they make misleading claims such as having "innovative memory management" when in fact they merely use Boehm GC. All the hate could be entirely avoided if their "marketing material" was a little more honest and humble.
no, we don't "merely use Boehm GC"
Earlier quoted context omitted.
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…
> 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.
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.
Earlier quoted context omitted.
Problem? Is the communication not up to the author? And shouldn't people rather help out than just make demands on an open source project?
I don't have time to help every single open source project that makes bold claims. I also don't demand anything, I just moved V to my ignored list. It may be unfair, and I may take a look in a few years again if there are enough solid news about V floating around.