5 ms·

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 run

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.

throwaway894345 6y ago
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.
- Joker_vD 6y ago
  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.
- eslaught 6y ago
  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.
- higerordermap 6y ago
  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.
  - posix_me_less 6y ago
    > there are things you can't properly implement by compiling to C Very interesting claim, any examples?
    - thysultan 6y ago
      It's not only interesting, it's blatantly false.
    - aweinstock 6y ago
      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 https://en.wikipedia.org/wiki/Threaded_code#Direct_threading [1]: https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html
      - mratsim 6y ago
        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-pragma https://nim-lang.org/docs/manual.html#pragmas-computedgoto-p...
    - pornel 6y ago
      • 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.
- delian66 6y ago
  See https://github.com/vlang/v/wiki/On-the-benefits-of-using-C-as-a-language-backend https://github.com/vlang/v/wiki/On-the-benefits-of-using-C-a...
  - vlang1dot0 6y ago
    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 https://github.com/vlang/v/issues/6310), [2](https://github.com/vlang/v/issues/6263 https://github.com/vlang/v/issues/6263), [3](https://github.com/vlang/v/issues/4730 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.
    - delian66 6y ago

throwaway894345 6y ago

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.

Joker_vD 6y ago
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.
eslaught 6y ago
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.
higerordermap 6y ago
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.
- posix_me_less 6y ago
  > there are things you can't properly implement by compiling to C Very interesting claim, any examples?
  - thysultan 6y ago
    It's not only interesting, it's blatantly false.
  - aweinstock 6y ago
    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 https://en.wikipedia.org/wiki/Threaded_code#Direct_threading [1]: https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html
    - mratsim 6y ago
      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-pragma https://nim-lang.org/docs/manual.html#pragmas-computedgoto-p...
  - pornel 6y ago
    • 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.
delian66 6y ago
See https://github.com/vlang/v/wiki/On-the-benefits-of-using-C-as-a-language-backend https://github.com/vlang/v/wiki/On-the-benefits-of-using-C-a...
- vlang1dot0 6y ago
  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 https://github.com/vlang/v/issues/6310), [2](https://github.com/vlang/v/issues/6263 https://github.com/vlang/v/issues/6263), [3](https://github.com/vlang/v/issues/4730 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.
  - delian66 6y ago