8 ms·

I always have this feeling that the author of V just does not really know how to properly write a compiler. imho he just always hacks something up without prope

I always have this feeling that the author of V just does not really know how to properly write a compiler. imho he just always hacks something up without properly learning the craft, which frequently results in some monstrosity that at first does not quite work and gets slowly patched to the real thing (e.g. the parser). This is very annoying because sometimes the real thing is quite easy (or a solved problem) but the V compiler just seems to fail at it.

johnfn 6y ago
Should every software engineer immediately be well-versed in everything they attempt? It's the passion project of a single engineer, not a company or team. Imagine if we directed this mindset towards every new open source project.
- higerordermap 6y ago
  There are many people designing languages for hobby. See r/programminglanguages for examples. But they didn't claim they were creating next big thing with all those 'dreamed' features.
  - johnfn 6y ago
    I don't see anywhere on the website that the author claims the language is 'the next big thing'. Perhaps the author takes some pride in what they've accomplished, but should we really police people feeling proud of their own work?
    - cormacrelf 6y ago
      The context for most discussions of V is the over-promises about feature delivery the author has made. You could dig up all the old threads AGAIN (what, 5 times this year?), but that wouldn't really help anyone. Judging by the website, I don't think the general hype pattern (including the impossibly thin claims about compiler performance mainly measuring Clang) has changed all that much, though it appears to have slowed. A lot of the actual Next-Big-Thing-ism seems to be coming from excited users rather than the author himself. There is a GitHub issue entitled "Very long term consideration: what it takes to get a language adopted by Google?"; there are others about getting "parallelism & concurrency for seamless local and distributed programming" and similarly extraordinarily lofty goals. People love being part of the winning project, and the overall hype history has drawn them like moths. That's OK, they can all go hang out writing V programs and wishing upon stars. It probably shouldn't bother people as much as it has. When should we "police people feeling proud", then? Here I think there's not so much harm. Legally speaking, pretending he's in my jurisdiction (AU) for a moment, seeking donations can be trade or commerce, and then a bunch of consumer protection laws may apply, esp. ACL s 18. But you still need people who feel they've been wronged. Show me someone who tanked a heap of money into it on the pitch alone and I'll change my mind, but I don't think that's happening. On the point of design vs actual quality, you can get an idea of OP's perspective by browsing through the GitHub issues. To be fair, the project is only a few years old, but some of the issues there are simply alien to me. It just doesn't seem like it was written in a language that has the features V has. Every new feature seems to have missed matching an enum variant somewhere. I don't understand how a compiler could exist that appears NOT to be made of building blocks that don't completely break when you add new features. I just can't relate many of the errors people get to a "Parse -> Valid Syntax -> Type Checker -> IR -> ... IRs ... -> Machine Code" progression. This is what makes me think it's not going to survive very long -- those kinds of bugs don't simply stop cropping up.
      - delian66 6y ago
        Unfortunately, V currently does not generate a classical stricter IR, but C code (as strings) directly, which explains some of the issues concerning C compilation errors. I am optimistic about the future though, so I continue writing and changing V programs (the V compiler itself is a V program mind you)... I am not in the habit of wishing upon stars (or other people), for something that requires just thinking, engineering and time. p.s. PRs are welcome.
        cormacrelf 6y ago
        Right. It's like sitting down in a café with your whole day of work ahead of you, a nice cup of coffee and some thinking, engineering and time. Except the day is perhaps 400,000 man-hours long, for all the things V wants to be. Every new project is nice when it's greenfield, but V is something else. V seems to be perpetually on the cusp of greater things. And it has done all the things that projects do when they are there, and will continue to do the things that projects do when they are there. (Like stability guarantees!) That does not make it a great thing, but it stays enjoyable to hack on because you get to be part of a thing that exists. And it's on the cusp! As long as V never gets good, and the author keeps claiming things are around the corner, it will always be on this cusp. And coding it will never be too complicated, because V doesn't do any of that fancy stuff. Well, it already does, but not yet. "It does but not yet" is exactly what makes you the happiest, because you simultaneously get to be part of the avant garde, and not have to know how to do it. I bet the author loves it. It's no fun when people point out that it doesn't yet, because it will, it will because all these people here are busily plugging away and adding all the things it already has, which is significantly easier than adding the things it hasn't. It's even worse when people say it won't, because if it won't, then it never did. Unfortunately, for the people you need to make it work, that kind of "It does but not yet" is not fun. It makes me bristle. This Sisyphus, reader, would rather throw himself down the mountain. You, too, can feel the nausea if you sit with it.
        delian66 6y ago
        I am more motivated to have a language that compiles fast to small binaries, is easy to understand and use, and is cross platform, but thanks for you attempt for psychoanalysis of a stranger on the internet anyway. If I were you though, I would stick to coding, your prose is hard to read - at least try to use proper punctuation and spacing.
umvi 6y ago
Well I would hope then the V spec is well defined so that people can write competing compilers. The beauty of a language is the spec, not necessarily a specific implementation.
- benrbray 6y ago
  Language specs are a dime a dozen. Especially when type inference is involved, it's the compiler / interpreter that really does the heavy lifting. I have an idea, let's create a new programming language! I'll be the "ideas" man and come up with syntax ideas. You work on the compiler backend ok? And we'll split the fame 80/20 since I'm the face of the project, you know?
  - umvi 6y ago
    How about I create a new language, grow it and make it really popular, and then you can create a lightning fast alternate compiler to replace my crappy proof of concept one. Everybody wins.
    - mathgladiator 6y ago
      This is what I'm doing at the moment. I'm just translating to Java right now so I can have a robust platform to target; it's working well for me, but it would be nice if I could go directly to bytecode. However, that work doesn't add value until latency matters.
nicoburns 6y ago
I get a similar impression. And it's a shame because their language design skills seem much better than their compiler development skills. Unfortunately I think compiler implementation is probably more important than language design as a component of a languages overall success.
- delian66 6y ago
  PRs are welcome. Especially from skilled compiler developers.
  - nicoburns 6y ago
    Alas I'm not one either. I would love to make my own language. But I definitely don't have the skills to do so at the moment. For now I've decided I'm better of contributing change requests to existing languages. Edit: I would like to add that I once had your optimism and enthusiasm for my projects. I didn't quite manage to achieve them, but I got an awful lot further than most would have predicted and I learnt a great deal in the process. So all power to you.
leafboi 6y ago
How would you properly learn this craft? What resources would you recommend or look into?
- ActorNightly 6y ago
  Probably LLVM. You just have to parse the syntax into LLVM IR
  - fwip 6y ago
    If your language is fairly low-level, you might be able to get away with "translating" it into LLVM. If it's not low-level, you have to make a bunch of implementation decisions - how do your language's killer features work under the hood?? For just one example, for V, the author reuses Go's `go` keyword to launch a new coroutine/green thread. What algorithms do you use to share work between threads equally? What data structures do you use to represent those? What's the right balance between latency, throughput, memory usage, etc etc? Many common language features are non-trivial to implement, even with the help of the LLVM IR (which I think is wonderful).
- andoriyu 6y ago
  Dragon Book probably still valuable resource.
  - forgotpwd16 6y ago
    It should be noted though that Dragon is very detailed especially on parsing. Thus some consider it a bad introductory book and/or even outdated. But it's good resource if you want to become better and parsing is just a part of the book.
  - mbrodersen 6y ago
    The Dragon Book used to be a good recommendation but not anymore. It is outdated.
- brianush1 6y ago
  https://craftinginterpreters.com/ https://craftinginterpreters.com/ is a good intro book.
darthrupert 6y ago
Perhaps it will become the most popular web backend language then.
mathgladiator 6y ago
Given this is hacker news, hacking something up seems very appropriate. I don't know the author, but it is clear that he is prolific and talented. This project is very much in the seeking ground phase, so having a bunch of hacks is very appropriate. If it turns out useful, then people will fix things. If it turns out not to be useful, then oh well. The danger of course if there are show stopping bugs which prohibit the transition from interesting project to useful project.
jatins 6y ago
Maybe you are right. Heck, you probably are. But should it matter? If the claims are real – fast compilation times, hot reloading, and an overall nicer/safer language to work with. I'd be interested in hearing the critique of language, features, claims. Not sure if the implementation details are relevant to end users of language.
- pcstl 6y ago
  It's been shown time and time again they aren't: https://christine.website/blog/v-vaporware-2019-06-23 https://christine.website/blog/v-vaporware-2019-06-23 The author has been doing periodic reviews of the development of the language: https://christine.website/blog/vlang-update-2020-06-17 https://christine.website/blog/vlang-update-2020-06-17 V is mostly vaporware with a lot of bombastic marketing.
  - delian66 6y ago
    V is not vaporware - I use it daily, so do hundreds of other developers - see the commit log at https://github.com/vlang/v/commits/master https://github.com/vlang/v/commits/master . Have you tried it yourself? It takes just a minute to clone and build it, if you already have a working C99 compiler like gcc on your machine.
awb 6y ago
Just as we separate web design and development into different disciplines, we should consider splitting language design and development into different disciplines as well. The V language looks beautiful (like an improved version of Go). There's always the chance someone will design something that's too complicated to develop, but that's the same with web design.
- Barrin92 6y ago
  I don't think a total split is reasonable (in both examples given). Technical implementation and design inform each other because there's always a point where limitations, performance, or some other aspect becomes relevant, and where having knowledge of both domains is very useful. You can have a designer say, create a great UI but if they are not aware of the underlying limitations of the tech it can create a lot of headache. This may be even more relevant for language design and implementation. Ideally you have 'all-rounders' around for these issues.
  - awb 6y ago
    Yes, ideally in both the designer has some mid-level understanding of development and the developer has some mid-level understanding of design. Without that overlap, things can go off the rails.
- hardwaregeek 6y ago
  Except in web design you rarely create a design that is literally, provably impossible to make
  - delian66 6y ago
    Can you be more specific about what is impossible to make?
    - hardwaregeek 6y ago
      Any decent language designer should know the Halting Problem and how that translates to static analysis (Rice's Theorem). But more than that, it's quite easy to design typechecking algorithms that exhibit combinatorial explosion. A naive language designer could promise fast compilation speeds and robust typechecking with inference, assuming that typechecking could be sped up with caches and a fast implementation language. However if the typechecking algorithm is O(n^3), no matter what, compilation speed will be slow.
rvz 6y ago
It seems you find the bugs in V-lang 'easy' to fix and you dislike the authors 'hacks' and believe he isn't properly learning the craft on how to write a compiler. Perhaps you could show him the way by sending in a pull request or patchset to the project to verify your expertise in fixing these 'annoying' bugs and properly writing a compiler. Patches are welcome.

johnfn 6y ago

Should every software engineer immediately be well-versed in everything they attempt? It's the passion project of a single engineer, not a company or team. Imagine if we directed this mindset towards every new open source project.

higerordermap 6y ago
There are many people designing languages for hobby. See r/programminglanguages for examples. But they didn't claim they were creating next big thing with all those 'dreamed' features.
- johnfn 6y ago
  I don't see anywhere on the website that the author claims the language is 'the next big thing'. Perhaps the author takes some pride in what they've accomplished, but should we really police people feeling proud of their own work?
  - cormacrelf 6y ago
    The context for most discussions of V is the over-promises about feature delivery the author has made. You could dig up all the old threads AGAIN (what, 5 times this year?), but that wouldn't really help anyone. Judging by the website, I don't think the general hype pattern (including the impossibly thin claims about compiler performance mainly measuring Clang) has changed all that much, though it appears to have slowed. A lot of the actual Next-Big-Thing-ism seems to be coming from excited users rather than the author himself. There is a GitHub issue entitled "Very long term consideration: what it takes to get a language adopted by Google?"; there are others about getting "parallelism & concurrency for seamless local and distributed programming" and similarly extraordinarily lofty goals. People love being part of the winning project, and the overall hype history has drawn them like moths. That's OK, they can all go hang out writing V programs and wishing upon stars. It probably shouldn't bother people as much as it has. When should we "police people feeling proud", then? Here I think there's not so much harm. Legally speaking, pretending he's in my jurisdiction (AU) for a moment, seeking donations can be trade or commerce, and then a bunch of consumer protection laws may apply, esp. ACL s 18. But you still need people who feel they've been wronged. Show me someone who tanked a heap of money into it on the pitch alone and I'll change my mind, but I don't think that's happening. On the point of design vs actual quality, you can get an idea of OP's perspective by browsing through the GitHub issues. To be fair, the project is only a few years old, but some of the issues there are simply alien to me. It just doesn't seem like it was written in a language that has the features V has. Every new feature seems to have missed matching an enum variant somewhere. I don't understand how a compiler could exist that appears NOT to be made of building blocks that don't completely break when you add new features. I just can't relate many of the errors people get to a "Parse -> Valid Syntax -> Type Checker -> IR -> ... IRs ... -> Machine Code" progression. This is what makes me think it's not going to survive very long -- those kinds of bugs don't simply stop cropping up.
    - delian66 6y ago
      Unfortunately, V currently does not generate a classical stricter IR, but C code (as strings) directly, which explains some of the issues concerning C compilation errors. I am optimistic about the future though, so I continue writing and changing V programs (the V compiler itself is a V program mind you)... I am not in the habit of wishing upon stars (or other people), for something that requires just thinking, engineering and time. p.s. PRs are welcome.
      - cormacrelf 6y ago
        Right. It's like sitting down in a café with your whole day of work ahead of you, a nice cup of coffee and some thinking, engineering and time. Except the day is perhaps 400,000 man-hours long, for all the things V wants to be. Every new project is nice when it's greenfield, but V is something else. V seems to be perpetually on the cusp of greater things. And it has done all the things that projects do when they are there, and will continue to do the things that projects do when they are there. (Like stability guarantees!) That does not make it a great thing, but it stays enjoyable to hack on because you get to be part of a thing that exists. And it's on the cusp! As long as V never gets good, and the author keeps claiming things are around the corner, it will always be on this cusp. And coding it will never be too complicated, because V doesn't do any of that fancy stuff. Well, it already does, but not yet. "It does but not yet" is exactly what makes you the happiest, because you simultaneously get to be part of the avant garde, and not have to know how to do it. I bet the author loves it. It's no fun when people point out that it doesn't yet, because it will, it will because all these people here are busily plugging away and adding all the things it already has, which is significantly easier than adding the things it hasn't. It's even worse when people say it won't, because if it won't, then it never did. Unfortunately, for the people you need to make it work, that kind of "It does but not yet" is not fun. It makes me bristle. This Sisyphus, reader, would rather throw himself down the mountain. You, too, can feel the nausea if you sit with it.
        delian66 6y ago
        I am more motivated to have a language that compiles fast to small binaries, is easy to understand and use, and is cross platform, but thanks for you attempt for psychoanalysis of a stranger on the internet anyway. If I were you though, I would stick to coding, your prose is hard to read - at least try to use proper punctuation and spacing.

umvi 6y ago

Well I would hope then the V spec is well defined so that people can write competing compilers. The beauty of a language is the spec, not necessarily a specific implementation.

benrbray 6y ago
Language specs are a dime a dozen. Especially when type inference is involved, it's the compiler / interpreter that really does the heavy lifting. I have an idea, let's create a new programming language! I'll be the "ideas" man and come up with syntax ideas. You work on the compiler backend ok? And we'll split the fame 80/20 since I'm the face of the project, you know?
- umvi 6y ago
  How about I create a new language, grow it and make it really popular, and then you can create a lightning fast alternate compiler to replace my crappy proof of concept one. Everybody wins.
  - mathgladiator 6y ago
    This is what I'm doing at the moment. I'm just translating to Java right now so I can have a robust platform to target; it's working well for me, but it would be nice if I could go directly to bytecode. However, that work doesn't add value until latency matters.

nicoburns 6y ago

I get a similar impression. And it's a shame because their language design skills seem much better than their compiler development skills. Unfortunately I think compiler implementation is probably more important than language design as a component of a languages overall success.

delian66 6y ago
PRs are welcome. Especially from skilled compiler developers.
- nicoburns 6y ago
  Alas I'm not one either. I would love to make my own language. But I definitely don't have the skills to do so at the moment. For now I've decided I'm better of contributing change requests to existing languages. Edit: I would like to add that I once had your optimism and enthusiasm for my projects. I didn't quite manage to achieve them, but I got an awful lot further than most would have predicted and I learnt a great deal in the process. So all power to you.

leafboi 6y ago

How would you properly learn this craft? What resources would you recommend or look into?

ActorNightly 6y ago
Probably LLVM. You just have to parse the syntax into LLVM IR
- fwip 6y ago
  If your language is fairly low-level, you might be able to get away with "translating" it into LLVM. If it's not low-level, you have to make a bunch of implementation decisions - how do your language's killer features work under the hood?? For just one example, for V, the author reuses Go's `go` keyword to launch a new coroutine/green thread. What algorithms do you use to share work between threads equally? What data structures do you use to represent those? What's the right balance between latency, throughput, memory usage, etc etc? Many common language features are non-trivial to implement, even with the help of the LLVM IR (which I think is wonderful).
andoriyu 6y ago
Dragon Book probably still valuable resource.
- forgotpwd16 6y ago
  It should be noted though that Dragon is very detailed especially on parsing. Thus some consider it a bad introductory book and/or even outdated. But it's good resource if you want to become better and parsing is just a part of the book.
- mbrodersen 6y ago
  The Dragon Book used to be a good recommendation but not anymore. It is outdated.
brianush1 6y ago
https://craftinginterpreters.com/ https://craftinginterpreters.com/ is a good intro book.

darthrupert 6y ago

Perhaps it will become the most popular web backend language then.

mathgladiator 6y ago

Given this is hacker news, hacking something up seems very appropriate. I don't know the author, but it is clear that he is prolific and talented. This project is very much in the seeking ground phase, so having a bunch of hacks is very appropriate. If it turns out useful, then people will fix things. If it turns out not to be useful, then oh well. The danger of course if there are show stopping bugs which prohibit the transition from interesting project to useful project.

jatins 6y ago

Maybe you are right. Heck, you probably are. But should it matter? If the claims are real – fast compilation times, hot reloading, and an overall nicer/safer language to work with. I'd be interested in hearing the critique of language, features, claims. Not sure if the implementation details are relevant to end users of language.

pcstl 6y ago
It's been shown time and time again they aren't: https://christine.website/blog/v-vaporware-2019-06-23 https://christine.website/blog/v-vaporware-2019-06-23 The author has been doing periodic reviews of the development of the language: https://christine.website/blog/vlang-update-2020-06-17 https://christine.website/blog/vlang-update-2020-06-17 V is mostly vaporware with a lot of bombastic marketing.
- delian66 6y ago
  V is not vaporware - I use it daily, so do hundreds of other developers - see the commit log at https://github.com/vlang/v/commits/master https://github.com/vlang/v/commits/master . Have you tried it yourself? It takes just a minute to clone and build it, if you already have a working C99 compiler like gcc on your machine.

awb 6y ago

Just as we separate web design and development into different disciplines, we should consider splitting language design and development into different disciplines as well. The V language looks beautiful (like an improved version of Go). There's always the chance someone will design something that's too complicated to develop, but that's the same with web design.

Barrin92 6y ago
I don't think a total split is reasonable (in both examples given). Technical implementation and design inform each other because there's always a point where limitations, performance, or some other aspect becomes relevant, and where having knowledge of both domains is very useful. You can have a designer say, create a great UI but if they are not aware of the underlying limitations of the tech it can create a lot of headache. This may be even more relevant for language design and implementation. Ideally you have 'all-rounders' around for these issues.
- awb 6y ago
  Yes, ideally in both the designer has some mid-level understanding of development and the developer has some mid-level understanding of design. Without that overlap, things can go off the rails.
hardwaregeek 6y ago
Except in web design you rarely create a design that is literally, provably impossible to make
- delian66 6y ago
  Can you be more specific about what is impossible to make?
  - hardwaregeek 6y ago
    Any decent language designer should know the Halting Problem and how that translates to static analysis (Rice's Theorem). But more than that, it's quite easy to design typechecking algorithms that exhibit combinatorial explosion. A naive language designer could promise fast compilation speeds and robust typechecking with inference, assuming that typechecking could be sped up with caches and a fast implementation language. However if the typechecking algorithm is O(n^3), no matter what, compilation speed will be slow.

rvz 6y ago

It seems you find the bugs in V-lang 'easy' to fix and you dislike the authors 'hacks' and believe he isn't properly learning the craft on how to write a compiler. Perhaps you could show him the way by sending in a pull request or patchset to the project to verify your expertise in fixing these 'annoying' bugs and properly writing a compiler. Patches are welcome.