[amedvednikov]

> citing V -> C translation only, without the C -> binary part

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:

https://www.youtube.com/watch?v=pvP6wmcl_Sc

This video is linked on the home page.

> crashed the compiler on trivial inputs

We have thousands of tests, lots of big projects written in V (V itself is 220k loc, Vinix OS, Ved editor, Gitly, vsql etc), and they all work fine, no compiler errors.

Can you give an example of a trivial input resulting in a crash/C error?

The infamous "The language is not what is promised" you referenced has claims like "there's no way V is written in V", and "there's no way to do json serialization without an AST". These things are simply not true.

[kgeist]

>Can you give an example of a trivial input resulting in a crash/C error?

Here:

https://github.com/vlang/v/issues/14023

I've seen quite a few such issues in the GitHub repo.

>We have thousands of tests, lots of big projects written in V (V itself is 220k loc, Vinix OS, Ved editor, Gitly, vsql etc), and they all work fine, no compiler errors.

Do these projects have large userbases (actual users, not just as a toy project)? How many contributors? I wrote a transpiler myself and I know that if you write in a safe subset (avoiding known gotchas) a project no one uses, then there's going to be zero problems with the project :)

I'm skeptical but I'm open to learn that I'm wrong.

[amedvednikov]

Good find, a pretty specific issue resulting in an unhandled error. That's why the language is not 1.0 yet :) Such cases are quickly picked up and fixed by the team. This one is already being worked on and will be fixed this week.

300+ contributors.

[sergiotapia]

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.

[kgeist]

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.

[amedvednikov]

no, we don't "merely use Boehm GC"

[kgeist]

What else do you use besides it?

[jokethrowaway]

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 author the best of luck, but it won't fly with developers.

[EdSchouten]

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.

[amedvednikov]

That was before the public release and only lasted for a week.

So saying now 2.5 years later some things are closed source is ridiculous.

[paskozdilar]

Note that, in most cases, you can't respond to a comment because it's been posted too recently. I think it's a mechanism to prevent flaming.

[amedvednikov]

No things are closed source. Never have been.

What things are broken for you?

What claims are not true?

[Tozen]

It is very impressive that the creator of Vlang can come here to face the critics, trolls, and bashers. That tells you something positive about his character and fortitude.

What is also very interesting, is that when various trolls make their derogatory claims or bash on his creation, he responds to them with facts and references. Many of them never respond back and run away.

[sergiotapia]

That's what is most crazy to me. Even the creator of Nim (Araq) flamed this guy in the Nim forums but most of his criticism seemed to be superficial and opinion based. I don't know what to think. I'm not a language expert by any means. I just hope this guy succeeds, the goals are tremendous.

[amedvednikov]

Thanks for your support :)

[paskozdilar]

> 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 optimization turned on should give you a more realistic result.

> We have thousands of tests, lots of big projects written in V (V itself is 220k loc, Vinix OS, Ved editor, Gitly, vsql etc), and they all work fine, no compiler errors.

To quote Djikstra:

    Program testing can be used to show the presence of bugs, but never to show their absence.

[dundarious]

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 codegen, and for the project user such as the need to trust that these different codegens are largely functionally equivalent (exposing and fixing a bug in debug means it would have been but now will not be present in release). But the tcc approach is arguably one of the better ways to minimize the negatives in this tradeoff, compared to cranelift, etc., as tcc is a small but popular enough project in general usage, meaning it has some battle-testing.

And I think the point about projects that "work fine" was quite reasonable, just showing there has been a non-trivial amount of battle-testing. There is now some basis to claim that the project is not full of trivial bugs, to the point of making it useless. Nowhere was it claimed this was a proof of the absence of all bugs -- that you included the Dijkstra quotation in this context is honestly quite humorous.

My understanding is that there has been some drama in the V community in the past, especially around the feature set and release timeline and promises from its author, but I don't see the justification for all this pompous negativity when it is finally out in the wild, warts and all, but showing some nice capabilities at the same time. I don't plan to use it for any hobby projects myself right now, but if I wasn't in the middle of using a different up-and-coming language with some of the same goals, I might.

[paskozdilar]

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

It would be absurd for someone to write a frontend to LLVM then claim that their compiler is as fast as LLVM. V uses TCC - TCC is fast at compilation, not V. V is fast at transpilation, but that's not what the author has claimed.

> that you included the Dijkstra quotation in this context is honestly quite humorous

Proving compiler correctness with tests only is like proving that your regex parses html correctly with tests. It's never gonna work.

[dundarious]

Does Rust not make claims about performance, even though a large proportion of that comes from LLVM's work? Do Rust or GCC or Clang (or probably even Haskell) use tests as the primary way to ensure/approach correctness? The number of compilers for any language that actually prove correctness and that are used for some practical purpose can probably be counted on one hand (e.g., CompCert), so I'm not going to use that as an appropriate bar.

The tcc backend is just a smart choice, and in TFA it is mentioned up front:

> V compiles ≈110k (Clang backend) and ≈1 million (x64 and tcc backends) lines of code per second per CPU core. (Intel i5-7500, SM0256L SSD, no optimization)

[bheadmaster]

It's trivial to have fast compilation speed if all you do is transpile to C (naively, i.e. without any program analysis) and use TCC to compile the C (again, naively, that's why it's so fast). Such "languages" are often written as CS homework assignments.

But even with the transpilation step, the V transpiler is still unable to output correct code on trivial examples, demonstrated in other comments. The fact that you have thousands of tests (Alex's words) and the trivial examples still fail, makes me completely sure that something about the whole approach is fundamentally wrong; which lead me to the "testing whether your regex parses html properly" comment. Tests are useless if the thing you're testing does not prove anything.

The fact that the author is pushing this unfinished mess as a completed achievement (instead of work in progress), without ever mentioning any downsides (except when presented with undeniable proof, at which point he makes up another justification for the issue), only shows the author's inexperience and disconnection from the community. V compiler is a toy project wrapped up in a pretty box to look like something serious. And when faced with criticism, Alex seems to turn to his three different accounts to argue with the commenters, instead of reading the damn Dragon Book and fixing his damn compiler.

To me, personally, V language is the perfect example of an overhyped griftwork.

[dundarious]

It may be easier to have a C backend that is compiled via tcc, but if it's a smart choice (for the tradeoffs of a debug build), and hardly anybody else is doing it, then it's positive and noteworthy. The fact that it may not be particularly difficult is irrelevant.

I can't assess the quality of V in general, and it may be lacking for my needs, but I know a lot of early stage language projects with a lot of trivial bug reports (I've filed a few), that are still engineering accomplishments capable of real usage. V seems to be in that league. Maybe it's near the bottom of that league, but you can just state that and leave it at that.

Maybe V has a bit of a "dirty main branch" approach, where other languages you're used to tend to instead have long-lasting branches for the work-in-progress stuff. I can see how that would be annoying, being able to use half-finished functionality, and I might not like it myself. Maybe the author claims features are further ahead than they really are -- that would be even more frustrating. But your criticisms are hyperbolic (denigrating the work as at the level of a CS homework assignment, and comparing it to almost entirely non-existent languages that are mathematically provably correct) and often seem vindictive (unlikely to be leveled at other highly analogous early days language projects). Any legitimate criticisms you have are lost in the vitriol.

[amedvednikov]

Can you link to those trivial examples demonstrated in other comments?

[amedvednikov]

> I don't think it's reasonable to say this is a wholesale illegitimate/cheating approach.

Thank you for a voice of reason :)

[amedvednikov]

V is also written to be as simple as possible :)

Compilation time is very important during development for the quick dev cycle (change, build, test).

You don't need to do -O2 builds dozens of times per day.

-prod (-O2) builds are definitely an order of magnitude slower, that's a fact.

[vlovich123]

What is the performance delta between debug and prod? What is the performance delta between tcc and GCC -O0 if you’ve had a chance to compare?

I also disagree with others that using a different compiler is somehow cheating. Engineering is about winning and choosing the right tradeoffs. Being able to choose a faster backend for debug is one that all compilers offer. Most people spend most of the time living with -O0 builds because they need to debug the code. Heck, 90% of complaints about Rust compile times are about its performance making a debug build and it’s where that dev team spends its efforts. This criticism seems misplaced although it’s not clear to me why there’s this much pushback that most other languages don’t see.

[amedvednikov]

No difference between tcc and gcc -O0, despite tcc compiling it 10 times faster.

20%-100% difference between gcc -O0 and -O2.

[paskozdilar]

It's a dishonest benchmark. You're basically saying that "V compiles fast if you use a fast C compiler after the transpilation step", and wrapping it up as "V compiles fast". Those two are not exactly the same.

[amedvednikov]

It's absolutely not a dishonest benchmark. This backend comes bundled with V, it's what it uses by default. That's how you get the end result binaries when you use V.

To the end user it doesn't matter how the binary was generated. Via LLVM or via a bundled C compiler.

The only thing that matters: getting that binary after compilation and getting it fast.

[paskozdilar]

At this point, I'm sure you can find a justification for any kind of criticism anyone brings up, so I will stop bringing it up. Sorry for being a bother, and good luck with your Go clone.

[amedvednikov]

It's not a justification. It's how it works. People download the language, they use it to compile a binary, it's produced quickly.

I'm not sure how you can argue about that.

[kgeist]

Did you consider writing an interpreter for the quick dev cycle mode instead? Compilation times are down to 0 seconds (if we ignore the parsing time). As LuaJIT's Mike Pall has shown, a well-thought out interpreter can be as fast as a naive compiler. It's also more portable, and experiments are easier to introduce. The main page at vlang.io focuses on compilation speed, not runtime speed. You also admit that the fast compilation mode uses simpler backends without optimizations. So why not just interpret it, if compilation speed and quick dev cycles is number one priority? That's what interpreted languages already excel at.

[amedvednikov]

Runtime speed is as fast as it gets, because it's C.

Writing an interpreter is a huge task. It works well without it. Actually I'd say it's quicker, because interpreters have startup costs.

[vlang1dot0]

No, "it's fast because it's C" doesn't hold. You can write slow code in any language.

[kgeist]

As I said, I may be wrong. I think I will try V some day to see it for myself (maybe I'll write an article about my findings). As you are the author of the language, can you comment on what is the state of the auto-free system? How is memory management implemented?

[amedvednikov]

I don't think it's correct making claims like "it's a toy language" and "crashes on trivial input" without actually trying it out.

You don't need an article to clone the repo, build the language in <1s and play with it.

Autofree works:

https://www.youtube.com/watch?v=gmB8ea8uLsM

But it's not finished yet. We saw a better performance with a GC (due to all the extra copying autofree has to do), and made it the default.

I've always been anti-GC, but V is so minimal and doesn't result in many allocations in the first place, GC works really well with it.

In the end the user will have full control over how they want to do memory management: manual, autofree, gc.

[cyber_kinetist]

Is all the extra copying that autofree has to do related to the lack of move semantics in the language? Nim had to introduce a bunch of new language constructs/semantics to support their ORC backend, which is the solution that’s similar to yours. (See https://nim-lang.org/docs/destructors.html.) I expected V to move in the same direction but hadn’t found any discussion of move semantics in the docs so I found it strange.

[amedvednikov]

V will never have move semantics. Complicates the language too much.

[vlang1dot0]

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?

[kgeist]

>But it's not finished yet. We saw a better performance with a GC (due to all the extra copying autofree has to do), and made it the default

On vlang.io I can find this:

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

So it's been 2 years and it's still unfinished, and you just use Boehm GC instead (from what I understood). Isn't your landing page a little misleading? This is the problem with V: a lot of grandiose claims but at the end of the day you use a GC used in every other toy language.

[amedvednikov]

But it says right there:

Note: right now autofree is hidden behind the -autofree flag. It will be enabled by default in V 0.3.

Using gc means it's a toy language? Got you.

[kgeist]

>Using gc means it's a toy language? Got you.

No, I mean it's a common characteristic of toy languages to use Boehm GC because it requires zero configuration to work, as it scans conservatively. It doesn't require you to emit stack maps or provide the GC with type metadata. Boehm GC means low effort (in regards to memory management). It's perfectly fine to use it, and it's an amazing library itself, but it contrasts with all the claims on the landing page (in the section "innovative memory management").

[bheadmaster]

A toy language is a term for a computer programming language that is not considered to fulfill the robustness or completeness requirement of a computer programming language.

[ylluminate]

Then by this definition and by example of what has been done with V so far, it's definitely no "toy language."

[kaba0]

Could you explain clearly what is the memory model of the language? Because I haven’t seen it anywhere outside of the ridiculous old claims.