3 ms·

> Now that (part of?) the code has been released, it seems to be little more than a transpiler from V to C, with allowed inlined C, with most advertised feature

by dom96 7y ago

> Now that (part of?) the code has been released, it seems to be little more than a transpiler from V to C, with allowed inlined C, with most advertised features stubbed out. This is a little off-topic but I feel it needs to be discussed. The term "transpiler" that you've used here is a little belittling, not only to V but to other languages which are translated to C. I don't think its fair nor accurate to characterize compilers which translate code to C as "transpilers". It's valid when languages of the same level of abstraction are translated to each other, but not when one language (C) is low-level and the other is high-level. All this being said though, V does seem to lean very heavily on inlined C inside its standard library and compiler. So that assessment is totally fair.

NikkiA 7y ago
Given that the claim was that V was a native code generator with the option for transpiling to C, I think that pointing out that it's only a transpiler is fair
ScottFree 7y ago
> V does seem to lean very heavily on inlined C inside its standard library and compiler. So that assessment is totally fair. If you don't mind me asking, how heavily did Nim rely on inlined C inside it's standard library and compiler when it was only 3 months old? Or did you guys do something different that early in it's development?
- dom96 7y ago
  I wasn't around back then. But as far as I know there was never much inline C used, many C functions were wrapped sure, but that's necessary to use POSIX/WinAPIs. Nim has always had a "everything should be implemented in pure Nim" philosophy. So much so that the stdlib is even separated into "pure" modules[1] (implemented in Nim completely) and "impure" modules (those that depend on external C/C++ libs). Nowadays major things are implemented in Nim, for example we don't use libuv/libevent but instead have written our own epoll/kqueue/IOCP implementation. 1 - https://github.com/nim-lang/Nim/tree/devel/lib/pure https://github.com/nim-lang/Nim/tree/devel/lib/pure
amedvednikov 7y ago
> V does seem to lean very heavily on inlined C inside its standard library and compiler This is completely false. Why are competing language developers so willing to spread misinformation? :) There are 0 lines of C in the compiler. The vlib has about 500. So that's 500 out of ~14k. Most of it was added last spring when V just didn't have the necessary features. All of C code will be removed this month.
- stephen82 7y ago
  I think I have found a single line of C here lol: Here it is: https://github.com/vlang/v/blob/978ec58fe300929555786fdf58cae1969ea317ba/sync/sync_mac.v https://github.com/vlang/v/blob/978ec58fe300929555786fdf58ca... Please explain the use of `#include <pthread.h>` then, because as far as I can tell, this is a C header...unless I'm missing something here mate.
  - graphememes 7y ago
    Oh, there are a lot more than this one line as well. It would be one thing if he apologized, but instead playing the victim makes the whole situation worse. I wonder how long until the patreons drop below 800.

by dom96 7y ago

NikkiA 7y ago

Given that the claim was that V was a native code generator with the option for transpiling to C, I think that pointing out that it's only a transpiler is fair

ScottFree 7y ago

> V does seem to lean very heavily on inlined C inside its standard library and compiler. So that assessment is totally fair. If you don't mind me asking, how heavily did Nim rely on inlined C inside it's standard library and compiler when it was only 3 months old? Or did you guys do something different that early in it's development?

dom96 7y ago
I wasn't around back then. But as far as I know there was never much inline C used, many C functions were wrapped sure, but that's necessary to use POSIX/WinAPIs. Nim has always had a "everything should be implemented in pure Nim" philosophy. So much so that the stdlib is even separated into "pure" modules[1] (implemented in Nim completely) and "impure" modules (those that depend on external C/C++ libs). Nowadays major things are implemented in Nim, for example we don't use libuv/libevent but instead have written our own epoll/kqueue/IOCP implementation. 1 - https://github.com/nim-lang/Nim/tree/devel/lib/pure https://github.com/nim-lang/Nim/tree/devel/lib/pure

amedvednikov 7y ago

> V does seem to lean very heavily on inlined C inside its standard library and compiler This is completely false. Why are competing language developers so willing to spread misinformation? :) There are 0 lines of C in the compiler. The vlib has about 500. So that's 500 out of ~14k. Most of it was added last spring when V just didn't have the necessary features. All of C code will be removed this month.

stephen82 7y ago
I think I have found a single line of C here lol: Here it is: https://github.com/vlang/v/blob/978ec58fe300929555786fdf58cae1969ea317ba/sync/sync_mac.v https://github.com/vlang/v/blob/978ec58fe300929555786fdf58ca... Please explain the use of `#include <pthread.h>` then, because as far as I can tell, this is a C header...unless I'm missing something here mate.
- graphememes 7y ago
  Oh, there are a lot more than this one line as well. It would be one thing if he apologized, but instead playing the victim makes the whole situation worse. I wonder how long until the patreons drop below 800.