6 ms·
Hm I looked around the repo, and there doesn't seem to be much there. $ find . -name '*.v'|xargs wc -l|sort -n ... 314 ./glm/glm.v 330 ./ti
by chubot 7y ago
Hm I looked around the repo, and there doesn't seem to be much there.
$ find . -name '*.v'|xargs wc -l|sort -n
...
314 ./glm/glm.v
330 ./time/time.v
338 ./builtin/utf8.v
339 ./examples/tetris/tetris.v
490 ./os/os.v
630 ./compiler/scanner.v
644 ./compiler/table.v
712 ./gg/gg.v
814 ./builtin/string.v
845 ./compiler/main.v
848 ./compiler/fn.v
3216 ./compiler/parser.v
12573 total
I'm a big fan of compact code, i.e. doing more with less... but I have been working on langauges for long enough to know that it takes surprisingly large amounts of code to do anything useful in this space.
If you discount the lexer and parser, it's like 8-9K lines of code, and it's hard to imagine much being done there. You can make a "toy" in that much code, but the gap to a production compiler is very wide (e.g. a minimum of 50K or 100K lines of code).
There is also this translation which is not in the repo:
$ wc -l v.c
15099 v.c
----
Also, this bootstrapping part looks pretty slick, except I get a core dump (on Ubuntu 16.04 with default GCC):
$ time cc -w -o vc v.c
real 0m0.553s
user 0m0.517s
sys 0m0.035s
~/git/languages/v/compiler$ time ./vc -o v .
Segmentation fault (core dumped)
real 0m0.095s
user 0m0.002s
sys 0m0.000s
- deleted 7y ago[deleted]
- noncoml 7y agoWhere did you find `v.c`?
- reikonomusha 7y agoWhen I look at the great list of features, then actually look at all of this code written in V, I’m pretty underwhelmed. The code doesn’t look that much different from writing C, except it has more Go-like syntax. The language doesn’t seem to be assisting the writing of code very much, certainly not as much as claimed.
- dloss 7y agomkdir /var/tmp/vlang0.0.12 fixes the Segmentation fault for me EDIT: Not needed anymore
- yorwba 7y agoYou can also mkdir vlib in whichever directory you're trying to run vc and it will generate that temporary directory automatically. Unfortunately, that doesn't seem to be enough to actually generate output (or I just can't find the output file). EDIT: The generated C code gets put in /var/tmp/vlang0.0.12/v.c and compiling it gives me a new compiler which outputs slightly different C, so it seems to work. The description in the README doesn't mention that manual compilation step, so something seems to have gone wrong. EDIT2: It works if you have clang installed, which I didn't. The compilation step should probably default to cc instead.
- amedvednikov 7y agoAll of this has been fixed.
- cooperadymas 7y agoI can't understand criticising a brand new, v0.0.12 language built entirely by one person of being too small...
- estebank 7y agoExtraordinary claims require extraordinary evidence. If the information presented on https://vlang.io/ https://vlang.io/ had any hint of being aspirational as opposed to comparing it directly with existing languages, and the author had less confrontational interactions with skeptical people online, the reaction to this language would be different. Of course, without the extraordinary claims this code dump would also not receive the attention it has.
- bscphil 7y agoIt's worth noting that the website now has "WIP" annotations on many of the claims. I'm not sure how recently these were added as this thread is my introduction to the language. My assessment (not a language designer) is that this is something that shows some promise as a transpiled language for people who want a Go-like language without some of the common pain points and are OK with having no GC. I would add that people who do design languages seem to think it's going to be considerably harder to deliver on the WIP elements than the designer of V thinks. In particular, I note that "direct machine code generation" is a planned item (which would be required for the faster compile time that V promises), but doesn't (as of this source code release) seem to be started - could be wrong about that. Obviously you can promise whatever you want, but writing an entire machine code compiler that will run faster than GCC and equal it in performance is a difficult task. The goals of the project remind me a lot of Nim, and I'd have preferred to see a comparison with it rather than Rust. While I don't have a use for it myself, the designer does seem sincere about their efforts. (My "ideal" language would be something closer to a lightweight version of Rust that was simpler to use, even if it slightly ate in to what you could do with it.)
- amedvednikov 7y agoThanks! Work on x64 generation started back in August. I'll publish it very soon. I haven't touched it in a while, and it simply doesn't compile at the moment.
- amedvednikov 7y agoThese are not all files (for example, token.v, json.v, cgen.v are missing).
- yorwba 7y agoThat's what the "..." indicates. They're still included in the total count (assuming by json.v you actually mean json/json_primitives.v).
- amedvednikov 7y agoRight, of course :)
- graphememes 7y agoSomeone who makes a language should know this.