12 ms·

So if I recall correctly? when this language was first announced there was some strange controversy about it mostly being vaporware and serious claims being mad

So if I recall correctly? when this language was first announced there was some strange controversy about it mostly being vaporware and serious claims being made about the language and its performance before they were implemented. I assume this has mostly changed now? Has anyone tried using it recently?

axaxs 6y ago
I remember this as well. My opinion is that both sides were in the wrong. I think it's a case where the creator is overambitious, and set unrealistic timelines that obviously weren't met. In response, many called him a scammer/vaporware because he's soliciting donations. That said, the project kept progressing along and seems to get daily commits, which would be unusual for vaporware.
- higerordermap 6y ago
  I never mind that creator was ambitious. The problem is he made the claims as if they were implemented, without even knowing about the feasibility of them. 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.
  - Joker_vD 6y ago
    Well, I can definitely see why someone would want to add generics and less verbose error handling to Go.
    - higerordermap 6y ago
      The word is retrofit.
      - Joker_vD 6y ago
        I fail to get the distinction you're trying to make. "To retrofit", to my knowledge, means "to add a part to something that didn't have it originally". Is it supposed to be pejorative?
        kd0amg 6y ago
        Slightly pejorative in that it suggests a result that's less effective/streamlined/economical/whatever than had the new part been included (or at least accounted for as a possible extension) in the original design.
  - delian66 6y ago
    The joke is on you. I do use V daily and enjoy it for the most part. You bitch about it on HN, without using it. I find it pretty funny actually.
agumonkey 6y ago
I still don't want to play with that because the author seems to insinuate that his language is the leanest fastest because it compiles to C as if he's not taking the C->native step.
- aidenn0 6y ago
  TFA lists total time with clang and tcc backends. I believe it also has a beta quality x64 native backend now.
higerordermap 6y ago
A serious number of CS-defying claims, most of the rest being intellectually dishonest.
- penagwin 6y ago
  To be fair I didn't see a ton of "CS-defying" claims as in they were impossible, however he made a ton of claims that would put his language on par with languages with huge teams of people, several with major companies backing them, with far more resources. 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.
  - c-cube 6y ago
    There was at least the CS defying claim of "no GC, no leaks, simpler than rust" (I'm paraphrasing, but it was along these lines). Sounds easy when you just write it as a checkbox on a list of exciting features.
    - delian66 6y ago
      There is no GC, and the language is indeed simpler than rust. 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 https://aardappel.github.io/lobster/memory_management.html .
      - vlang1dot0 6y ago
        > regarding lobster memory management: > 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 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.
azhenley 6y ago
I believe part of it is that they were getting a lot of donations, probably based to some extent on those claims.
burlesona 6y ago
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.
qppo 6y ago
It got flamed hard on /r/programming several times. 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.
pityJuke 6y ago
Part of this authors' "vaporware" criticism aims squarely at his "Volt" app [2] (the reason for this language), which was supposed to be released sometime last year, but as far as I can see, after some buggy beta releases [1], has disappeared again. It may be coming back [3], but a lot of confusion here. [4] [1]: https://twitter.com/volt_app https://twitter.com/volt_app [2]: https://volt-app.com/ https://volt-app.com/ [3]: https://github.com/voltapp/volt/issues/164 https://github.com/voltapp/volt/issues/164 [4]: https://github.com/voltapp/volt/issues/149 https://github.com/voltapp/volt/issues/149

axaxs 6y ago

I remember this as well. My opinion is that both sides were in the wrong. I think it's a case where the creator is overambitious, and set unrealistic timelines that obviously weren't met. In response, many called him a scammer/vaporware because he's soliciting donations. That said, the project kept progressing along and seems to get daily commits, which would be unusual for vaporware.

higerordermap 6y ago
I never mind that creator was ambitious. The problem is he made the claims as if they were implemented, without even knowing about the feasibility of them. 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.
- Joker_vD 6y ago
  Well, I can definitely see why someone would want to add generics and less verbose error handling to Go.
  - higerordermap 6y ago
    The word is retrofit.
    - Joker_vD 6y ago
      I fail to get the distinction you're trying to make. "To retrofit", to my knowledge, means "to add a part to something that didn't have it originally". Is it supposed to be pejorative?
      - kd0amg 6y ago
        Slightly pejorative in that it suggests a result that's less effective/streamlined/economical/whatever than had the new part been included (or at least accounted for as a possible extension) in the original design.
- delian66 6y ago
  The joke is on you. I do use V daily and enjoy it for the most part. You bitch about it on HN, without using it. I find it pretty funny actually.

agumonkey 6y ago

I still don't want to play with that because the author seems to insinuate that his language is the leanest fastest because it compiles to C as if he's not taking the C->native step.

aidenn0 6y ago
TFA lists total time with clang and tcc backends. I believe it also has a beta quality x64 native backend now.

higerordermap 6y ago

A serious number of CS-defying claims, most of the rest being intellectually dishonest.

penagwin 6y ago
To be fair I didn't see a ton of "CS-defying" claims as in they were impossible, however he made a ton of claims that would put his language on par with languages with huge teams of people, several with major companies backing them, with far more resources. 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.
- c-cube 6y ago
  There was at least the CS defying claim of "no GC, no leaks, simpler than rust" (I'm paraphrasing, but it was along these lines). Sounds easy when you just write it as a checkbox on a list of exciting features.
  - delian66 6y ago
    There is no GC, and the language is indeed simpler than rust. 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 https://aardappel.github.io/lobster/memory_management.html .
    - vlang1dot0 6y ago
      > regarding lobster memory management: > 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 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.

azhenley 6y ago

I believe part of it is that they were getting a lot of donations, probably based to some extent on those claims.

burlesona 6y ago

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.

qppo 6y ago

It got flamed hard on /r/programming several times. 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.

pityJuke 6y ago

Part of this authors' "vaporware" criticism aims squarely at his "Volt" app [2] (the reason for this language), which was supposed to be released sometime last year, but as far as I can see, after some buggy beta releases [1], has disappeared again. It may be coming back [3], but a lot of confusion here. [4] [1]: https://twitter.com/volt_app https://twitter.com/volt_app [2]: https://volt-app.com/ https://volt-app.com/ [3]: https://github.com/voltapp/volt/issues/164 https://github.com/voltapp/volt/issues/164 [4]: https://github.com/voltapp/volt/issues/149 https://github.com/voltapp/volt/issues/149