I assume this has mostly changed now? Has anyone tried using it recently?
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.
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.
LLVM interface is unstable.
That said there are things you can't properly implement by compiling to C.
Very interesting claim, any examples?
• 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.
[0]: https://en.wikipedia.org/wiki/Threaded_code#Direct_threading [1]: https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html
This is what Nim does: https://nim-lang.org/docs/manual.html#pragmas-computedgoto-p...
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.
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.
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.
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.
[1]: https://twitter.com/volt_app
My personal impression was that V was an extremely ambitious project by a single developer without much experience taking on such a project, and the feature list was more of a roadmap last I looked.
There were also some head scratchers in the implementation/libraries and I recall that the playground got pwned and there was a great blog post flaming it but I can't find it at the moment.
It was like, really? You're going to have all these features that teams of engineers have been working on for decades (in many cases)? And do them flawlessly? You're also going to beat Zig, Nim, and Go - in far less time?
I've got no problem with projects like this for fun, but it's being marketed as a full fledge project.
The "only" thing missing for now is "no leaks", but we are working on it.
You may be interested in https://aardappel.github.io/lobster/memory_management.html .
> the scope of anonymous functions cannot outlive variables' scope they reference, however V plans full closure support
> lobster compiles whole codebase at once (so it can properly track data flow across module boundaries), however V plans incremental compilation support
> both points are direct consequence of lobster's choice for memory management, ie solving them would mean moving away from lobster's strategy as far as I undersand
https://github.com/vlang/v/issues/1247
Lobster's approach at least has some theoretical rigorousness to it. What V is doing is quite different both in terms of the implementation and the requirements from the language itself and they have never been shown how their version is sound.
That said, the project kept progressing along and seems to get daily commits, which would be unusual for vaporware.
The creator of V also seems to lack knowledge of CS fundamentals and apparently thinking he can make a great language by retrofitting "missing features" into Go.
The language is an unfunny joke.