Comment by burlesona | Hacker News Reader

Comment by burlesona | Hacker News Reader

Parent Full thread

I think when V was first announced (and to a lesser degree still today) it was really hard to tell the difference between the things the author had actually running and what was only “the vision.”

For example, V compiles to C super fast. Then you compile the C code at normal C compilation speed. Very logical design so no complaints there, but the original claims made it sound like it went straight from V to machine code in a blink, which isn’t exactly true.

However I will say that the project has been very active, the author has made his claims a lot more clear, and so far he’s delivering on his promises little by little.

If I were to summarize my experience testing out V, I would say the author looked around at the world of software engineering and said, “there are lots of good pieces out there, but what I want is one language + Stdlib that does absolutely everything, and what the hell, I’m just going to make it myself.”

It’s super ambitious, but it’s also pretty neat.

I wonder what are the tradeoffs between targeting C and targeting LLVM/LLIR? Is it mostly "I know C"? Given that LLVM is purpose-built for this kind of use case, I would expect that it would be the better target, but I'm not very knowledgeable on the subject.

Well, emitting C is easier than emitting LLIR. Not just in the sense that you know C already and don't know LLIR yet, but if your source language is close enough to C semantics (basically, it's imperative language), you can most of the time generate the code in one straightforward walk over your whole AST. In fact, translating it to some home-made lowered IR and then to C would probably produce less effective binary.

I'm one of the maintainers of the Terra language, so I can shed some light here.

In addition to what the sibling comment said, LLVM is a moving target. The project moves slower now than it used to, but as a general principle, the project does not provide backwards compatibility. That means there is a certain amount of constant effort required just to keep up. Even projects featured on the LLVM homepage get behind, sometimes by a large number of releases.

You're right that LLVM is better for some things. E.g. if you want to generate "real" debug info. Or if you want to generate code for GPUs, without having to teach your compiler to generate what is essentially a different language. But if you're talking about the fastest (and in many ways most stable) path to generating code, you can't really beat source-to-source with C as output.

Can use any compiler. (GCC sometimes optimizes better than LLVM, GCC has more platform support, TCC can be used for faster compilation).

LLVM interface is unstable.

That said there are things you can't properly implement by compiling to C.

> there are things you can't properly implement by compiling to C

Very interesting claim, any examples?

It's not only interesting, it's blatantly false.

If your source language has some construct that you want to express as state machines (e.g. async, CPS, pattern match compilation), and you want to compile the state machine as direct threaded code[0] (which involves fewer branches than a while-switch), then if you're compiling to C, you need computed gotos[1], which are non-standard.

[0]: https://en.wikipedia.org/wiki/Threaded_code#Direct_threading [1]: https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

GCC, Clang, ICC do support computed gotos and you can fallback to ``while true`` loop + switch dispatch for others.

This is what Nim does: https://nim-lang.org/docs/manual.html#pragmas-computedgoto-p...

• You don't control your ABI. For example, you can't reserve a register for error object return like Swift does.

• You don't control your stack and stack frames. You can't implement a segmented stack, for example.

• You have very limited options for unwinding. setjmp doesn't really cut it. You could leverage C++ exceptions or platform-specific things like SEH, but you can't design anything radically different.

• You can't have debug information fancier than #line and maybe reusing C++ name mangling. You can't make debuggers see your higher-level constructs and data as anything other than their lowering.

• You have very limited options for specifying pointer aliasing.

• If you don't want to inherit UB from C, you'll have to be very clever about using alternative constructs that don't cause UB while still compile to efficient code you wanted.

• If you mean standard C, not C with compiler extensions, then look at the whole list of non-standard intrinsics and built-ins for things C can't do.

See https://github.com/vlang/v/wiki/On-the-benefits-of-using-C-a...

There are certainly some good reasons to use C as your backend, but there are some huge downsides as well. The main one in my mind is that you're limited by restrictions placed on you by the target language. V claims no UB but C has lots of UB so extreme care must be taken while doing code generation not to run afoul of C's rules. A quick glance at V's issue tracker shows that is not the case. Nor does there seem to be any plan for solving this.

Other points in that document are frankly baloney:

- Writing programs that pass -Wall -pedantic, Clang analyzer, PVS, and result in zero Valgrind warnings/errors is a dream of any C/C++ developer. With V it's going to be guaranteed for every V program. (We are not there yet, but very close.)

Clang analyzer is not integrated at all so this is not "very close".

Valgrind tests are mostly disabled (especially with -autofree), this is baloney.

Author has yet to set up PVS or Coverity although it was suggested a few days ago on Discord. Again, baloney.

`-Wall -pedantic` Given V can't even compile valid V programs consistently without generating C _errors_ I find this extremely difficult to believe.

> Stability. New languages using LLVM directly are going to crash often. That's inevitable, and can be seen across all new languages using LLVM. The V compiler hasn't crashed once for me, and I haven't received any crash reports from other users.

V issue tracker has lots of instances of the V compiler crashing. "I haven't received any crash reports from other users" is a verifiable fabrication. ([1](https://github.com/vlang/v/issues/6310), [2](https://github.com/vlang/v/issues/6263), [3](https://github.com/vlang/v/issues/4730))

> Simplicity. LLVM is a huge C++ dependency, meaning that both developers of the language and the users are forced to install it. Calling C++ is not easy from V/C, so C wrappers have to be used, increasing the number of dependencies and complexities.

But you need a C compiler. `v -o` requires either clang (and thus LLVM) or GCC both of which are massive dependencies. This logic rings hollow.

> Author has yet to set up PVS or Coverity although it was suggested a few days ago on Discord. Again, baloney.

I personally, find the following course of events very interesting:

On 2020/09/14, a Discord user named `Engineer` writes the following:

> We should consider using Coverity as this is an opensource github project - we can test the output v filename.v -o filename.c as input for Coverity - to help us understand issues with the generated C code.

Mind you, that is not a code contributor, and his earlier questions, are about a mysterious undisclosed C compiler, that produces much more stricter error messages than gcc's ones.

Then he makes a short lecture on the topic of `What is static analysis?` again on Discord...

It is a Scooby Doo mystery indeed.

I have nothing against Coverity personally - it may very well help the V code generator, but I hate being forced to use a product in such a way.

Yes, please continue unraveling this "Scooby Doo mystery", I'm sure it will be entertaining for everyone!

Do you think there's a coordinated campaign by(?) Coverity to get your open source project to use it? For what reason? It's surely not to make money considering Coverity gives open source projects a free license.

> I have nothing against Coverity personally - it may very well help the V code generator, but I hate being forced to use a product in such a way.

Yes, two random people telling you to consider using a static analysis tool is "forcing" you to use a product.

----

This is a great example why everyone should stay away from V. Industry standard best practices are treated as conspiracy theories by the developers.

It's fine for people to decide they want to make a new language; that's great! It's also totally fine for all of those people to have no idea what they're doing; that's how you learn. But at some point, you need to recognize that you don't know what you don't know. V is not anywhere close to the level of production ready-ness you yourself have repeatedly claimed.

I myself do not claim that V is production ready. It is not even 0.2 ... I think it is very disingenuous of you, to put words in my mouth in such a way. I would appreciate, if you stop doing that to me, or others in the future.

As for Coverity, we are considering it, and afaik Alex has a license for PVS-Studio.

> But you need a C compiler. `v -o` requires either clang (and thus LLVM) or GCC both of which are massive dependencies. This logic rings hollow.

It requires a C compiler. You said it yourself. Clang and GCC are not the only existing C compilers. tcc for example is tiny compared to them - on linux, `thirdparty/tcc/` is ~4.1MB, excluding the `thirdparty/tcc/.git` folder, and ~5.8MB including it.

Reply on news.ycombinator.com