Live data from Hacker News

Hello V-Lang

blog.hackersreboot.tech

161–170 of 193 posts

Re: Hello V-Lang

#161

Earlier quoted context omitted.

> Not really, here's a benchmark of V compiling itself in 0.3 seconds that includes all steps (including the C -> binary part) and results in the compiler binary From what I've seen, you've used tcc for the benchmark, right? If so, that's kinda cheating, since tcc is written to be a simple as possible (and therefore as fast as possible), so the compilation time is essentially zero. Benchmarking with gcc with optimiza…

The same argument can be levied at any project that goes for a "don't use full LLVM for debug builds where iteration time and hence compile time speed is paramount". That includes projects like cranelift for Rust. I don't think it's reasonable to say this is a wholesale illegitimate/cheating approach. It has tradeoffs, for the project developer such as the burden of maintaining two significantly different paths for c…

> The same argument can be levied at any project that goes for a "don't use full LLVM for debug builds where iteration time and hence compile time speed is paramount"

It would be absurd for someone to write a frontend to LLVM then claim that their compiler is as fast as LLVM. V uses TCC - TCC is fast at compilation, not V. V is fast at transpilation, but that's not what the author has claimed.

> that you included the Dijkstra quotation in this context is honestly quite humorous

Proving compiler correctness with tests only is like proving that your regex parses html correctly with tests. It's never gonna work.

Re: Hello V-Lang

#162
post #138

Earlier quoted context omitted.

How is it related to spec'ing the language. It's just fuzzy use of terms to appear extraordinary. That's all. Btw he still didn't answer my simple question, meanwhile everybody is commenting saying how nice the community is, how people should help instead of criticizing and deflecting the actual issue people had with the project.

> How is it related to spec'ing the language You wrote a bit further up: " The problem is that in the initial releases the "high goals" were listed as "features" of the language ". The "features" you mention are obviously the specification. Have e.g. a look at how long they specified Algol 68 and when finally a compiler appeared; CPL is yet another good example; actually at that time Wirth was one of the few who deli…

I'd like to see the ALGOL group writing "we're faster and leaner than fortran" while writing their spec and no compiler to run tests against. I struggle to follow.

Re: Hello V-Lang

#163
post #152

Earlier quoted context omitted.

But you said it's unfinished and hidden behind a flag. And it's been like that for several years. I found this in the docs: >Autofree is still WIP. Until it stabilises and becomes the default, please compile your long running processes with -gc boehm, which will use the Boehm-Demers-Weiser conservative garbage collector

gc is also behind the flag so why do you pick one over the other? the language is still at 0.2

Are you arguing it's fairer to say V's default is to ignore managing memory at all?

Re: Hello V-Lang

#164
post #150

Earlier quoted context omitted.

Really? - No null Then what is `voidptr(0)`? - No global variables https://github.com/vlang/v/blob/master/doc/docs.md#global-va... At least add "by default" to the web site. - No undefined values Which is done by initializing all values to 0. Probably not a good idea to do that for references though. (See also "no null values") - No undefined behavior `*voidptr(0)` is accepted by the compiler. Unsigned integer overfl…

Besides the obvious trolling, much of this is your interpretation and what you want the developers of Vlang to say instead. Let's keep in mind that others can have different interpretations, opinions, or things they like to nitpick about too. The developers of Vlang aren't obligated to you or me in any way, so are entitled to type their perspectives on their website. The real deal are the many users, supporters, and…

So no actual response to objective criticism just "my interpretation is things are going well so they can claim anything they want"? Wow, what a compelling argument you make!

If you want to look at GitHub, sure let's do that. I see perhaps 5 regularly active contributors, many more who seem to have left the community, and a downward slope of commit activity starting in April 2020. Hardly some vast hub of activity like your comment would suggest.

Given autofree has been practically untouched in 6 months with no major bug fixes to speak of, reality would seem to be that V is on the slow road to nowhere. At the current rate of progress, I doubt we'll see 0.3 before mid 2023 and 1.0 perhaps sometime in the 2030s. It's been 6 months since anything was completed on the 0.3 checklist: https://github.com/vlang/v/commits/master/ROADMAP.md

Re: Hello V-Lang

#165
post #152

Earlier quoted context omitted.

But you said it's unfinished and hidden behind a flag. And it's been like that for several years. I found this in the docs: >Autofree is still WIP. Until it stabilises and becomes the default, please compile your long running processes with -gc boehm, which will use the Boehm-Demers-Weiser conservative garbage collector

gc is also behind the flag so why do you pick one over the other? the language is still at 0.2

>so why do you pick one over the other?

Because the documentation recommends to use GC instead of auto-free which is "WIP".

Re: Hello V-Lang

#166
post #138

Earlier quoted context omitted.

> How is it related to spec'ing the language You wrote a bit further up: " The problem is that in the initial releases the "high goals" were listed as "features" of the language ". The "features" you mention are obviously the specification. Have e.g. a look at how long they specified Algol 68 and when finally a compiler appeared; CPL is yet another good example; actually at that time Wirth was one of the few who deli…

I'd like to see the ALGOL group writing "we're faster and leaner than fortran" while writing their spec and no compiler to run tests against. I struggle to follow.

Something like this actually happened when they had to decide between Wirth's and Hoare's practice-oriented proposal and Wijngaarden's rather academic proposal. There was quite a bit of controversy about this, not based on true implementations. Big egos exist everywhere and in all times.

Re: Hello V-Lang

#167
post #139

Why was this misspelled? Shouldn't it be Vlang ( https://vlang.io/ ), not V-Lang?

Ok, so I am the author of the article and I wanted to put it as "V" but wasn't differentiating for example in search and "Vlang" just didn't feel good.

Re: Hello V-Lang

#168
Hey Guys, So I am the author of the article and it is about time I address the comments here. I just want to say that I just got to know about it, I used it and it felt good. I tested a lot of the features but ofc couldn't get them all. I know nothing of any controversies surrounding the language. Also, I am just starting out in writing so I might've not included some details or it might've looked like a "sales talk" but in all honesty I had written a section in the draft versions but forgot to include it. I am planning to write another post to address the issues of the language and my writing about it.

Thanks for reading and commenting. I appreciate it and hope to use these comments to improve myself as both a researcher and a writer. Thanks again!

Re: Hello V-Lang

#169

Earlier quoted context omitted.

The same argument can be levied at any project that goes for a "don't use full LLVM for debug builds where iteration time and hence compile time speed is paramount". That includes projects like cranelift for Rust. I don't think it's reasonable to say this is a wholesale illegitimate/cheating approach. It has tradeoffs, for the project developer such as the burden of maintaining two significantly different paths for c…

> The same argument can be levied at any project that goes for a "don't use full LLVM for debug builds where iteration time and hence compile time speed is paramount" It would be absurd for someone to write a frontend to LLVM then claim that their compiler is as fast as LLVM. V uses TCC - TCC is fast at compilation , not V. V is fast at transpilation , but that's not what the author has claimed. > that you included t…

Does Rust not make claims about performance, even though a large proportion of that comes from LLVM's work? Do Rust or GCC or Clang (or probably even Haskell) use tests as the primary way to ensure/approach correctness? The number of compilers for any language that actually prove correctness and that are used for some practical purpose can probably be counted on one hand (e.g., CompCert), so I'm not going to use that as an appropriate bar.

The tcc backend is just a smart choice, and in TFA it is mentioned up front:

> V compiles ≈110k (Clang backend) and ≈1 million (x64 and tcc backends) lines of code per second per CPU core. (Intel i5-7500, SM0256L SSD, no optimization)

Re: Hello V-Lang

#170

Earlier quoted context omitted.

> keeping the GC but try to do some compiler analysis to insert free() calls at compile time as much as it can This is correct. > Also, the choice of Boehm GC is a little bit disappointing Which one would you recommend? > Almost all claims of the usability/stability of the language seems to come from the main creator himself The creators of Vinix and vsql don't have any issues with the usability/stability.

>> Also, the choice of Boehm GC is a little bit disappointing >Which one would you recommend? boehm is conservative. this is a costly and very unnecessary implementation for a language which already has a compiler and knows explicitly which values are pointers.

Thanks, will investigate.

We'll have our own GC in the future anyway.

Post reply on HN