Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hello V-Lang

blog.hackersreboot.tech

Post reply on HN
Print view View original

81–90 of 193 posts

Re: Hello V-Lang

#81

Post by sergiotapia »

amedvednikov wrote: post #40
kgeist wrote: post #37

Earlier quoted context omitted.

>Can you give an example of a trivial input resulting in a crash/C error? Here: https://github.com/vlang/v/issues/14023 I've seen quite a few such issues in the GitHub repo. >We have thousands of tests, lots of big projects written in V (V itself is 220k loc, Vinix OS, Ved editor, Gitly, vsql etc), and they all work fine, no compiler errors. Do these projects have large userbases (actual users, not just as a toy proj…

Good find, a pretty specific issue resulting in an unhandled error. That's why the language is not 1.0 yet :) Such cases are quickly picked up and fixed by the team. This one is already being worked on and will be fixed this week. 300+ contributors.

FWIW bro I enjoy that you are building something so ambitious and making progress despite the unwarranted hate. I have no idea why you bring out so many visceral trolls.

Can someone share why this guy and vlang are so hated? It seems like he is ironing out the kinks even years after the hate keeps piling on.

He keeps this up he's going to win.

Re: Hello V-Lang

#82

Post by christophilus »

amedvednikov wrote: post #55
christophilus wrote: post #47

Earlier quoted context omitted.

I took it for a spin recently and enjoyed the experience. The Postgres driver was woefully slow, compared to Golang (50 queries per second for a trivial query vs over 10k), which is the only reason my side project isn’t in V. It’s a great language, though. Looking forward to using it in the future.

Wow that shouldn't be the case! Can you link to the pg benchmark you did? We need to fix this asap.

Sure. I’ll open an issue tomorrow when I’m back at that machine.

Re: Hello V-Lang

#83

Post by Normille »

throwaway4good wrote: post #67
throwamon wrote: post #35

Earlier quoted context omitted.

Maybe, but I can tell you when I was 15 I didn't have instant worldwide reach and the on-the-Internet-nobody-knows-you're-a-dog effect at my disposal, and neither did my readers.

I grew up with if you build people will come. I don’t think it is like that anymore …

Now it's "tell people you're thinking of building it and they will come"

[see Kickstarter et al.]

Re: Hello V-Lang

#84

Post by vlovich123 »

amedvednikov wrote: post #38
paskozdilar wrote: post #34

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…

V is also written to be as simple as possible :) Compilation time is very important during development for the quick dev cycle (change, build, test). You don't need to do -O2 builds dozens of times per day. -prod (-O2) builds are definitely an order of magnitude slower, that's a fact.

What is the performance delta between debug and prod? What is the performance delta between tcc and GCC -O0 if you’ve had a chance to compare?

I also disagree with others that using a different compiler is somehow cheating. Engineering is about winning and choosing the right tradeoffs. Being able to choose a faster backend for debug is one that all compilers offer. Most people spend most of the time living with -O0 builds because they need to debug the code. Heck, 90% of complaints about Rust compile times are about its performance making a debug build and it’s where that dev team spends its efforts. This criticism seems misplaced although it’s not clear to me why there’s this much pushback that most other languages don’t see.

Re: Hello V-Lang

#85

Post by amedvednikov »

pwdisswordfish9 wrote: post #76
amedvednikov wrote: post #15

Earlier quoted context omitted.

It's a very biased and old list of articles from an author who openly claimed that "V should die". For example, the performance of V is measured on a debug build, without vlib cached, without vfmt disabled, with a 10x slower backend. Here's V compiling itself in 0.3 seconds: https://www.youtube.com/watch?v=pvP6wmcl_Sc Also complaining about not running on all Linux flavors on day 1. Right now V runs on literally ever…

> an author who openly claimed that "V should die". Citation needed. Or is the source for that claim the same as that for V benchmarks?

https://news.ycombinator.com/item?id=27442724

> I think it is something that should be ignored until it dies into obscurity

Re: Hello V-Lang

#86

Post by Daunk »

lawl wrote: post #27
bheadmaster wrote: post #20

Here are the summarized V features for anyone who dislikes salestalk: - small binaries and fast compilation - cross-platform support - cross-compilation - cross-platform drawing library (GDI+/Cocoa Drawing, OpenGL) - native GUI toolkits (V-UI) - value types - auto-free engine that adds necessary free() commands - C transpilation (both ways, allegedly emits human-readable C) - C foreign function interface ("V can call…

i'm pretty sure that half of these features don't work. Such as the famous "autofree" where everyone doubted it could work and the solution now was.... to drop in boehm-gc. for anyone unfamiliar with v, take everything on that list with a giant spoon full of salt.

This has very much been the case for me when trying out V. It advertises some great features that just barely works in the right circumstances.

Re: Hello V-Lang

#87

Post by WithinReason »

ReleaseCandidat wrote: post #62

Interesting definition of 'pure functions': Pure functions by default V functions are pure by default, meaning that their return values are a function of their arguments only, and their evaluation has no side effects (besides I/O). https://github.com/vlang/v/blob/master/doc/docs.md#pure-func...

You mean the "besides I/O" part?

Re: Hello V-Lang

#88

Post by cyber_kinetist »

lawl wrote: post #27
bheadmaster wrote: post #20

Here are the summarized V features for anyone who dislikes salestalk: - small binaries and fast compilation - cross-platform support - cross-compilation - cross-platform drawing library (GDI+/Cocoa Drawing, OpenGL) - native GUI toolkits (V-UI) - value types - auto-free engine that adds necessary free() commands - C transpilation (both ways, allegedly emits human-readable C) - C foreign function interface ("V can call…

i'm pretty sure that half of these features don't work. Such as the famous "autofree" where everyone doubted it could work and the solution now was.... to drop in boehm-gc. for anyone unfamiliar with v, take everything on that list with a giant spoon full of salt.

The solution V seems to apply here is a bit more nuanced than that. They’re going in roughly the similar direction as Nim did with the new ORC, which is essentially keeping the GC but try to do some compiler analysis to insert free() calls at compile time as much as it can using scope-based memory management and move semantics. The confusing thing about V is that these design decisions aren’t written properly on the docs, so the author’s claims might feel like “selling snake oil” although it’s already implemented in another language with great success. It would have been much better if the creator of V had acknowledged any previous work done on the topic. Also, the choice of Boehm GC is a little bit disappointing, but understandable since it’s basically the easiest garbage collector you can stick it into a language (without designing your own GC). Maybe this will change later on.

Though I’m still not confident enough on the usability and stability of the language. Almost all claims of the usability/stability of the language seems to come from the main creator himself, I would like to hear some takes from people other than him who have used the language in any serious form.

Re: Hello V-Lang

#89

Post by dundarious »

paskozdilar wrote: post #34
amedvednikov wrote: post #26

Earlier quoted context omitted.

> citing V -> C translation only, without the C -> binary part 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: https://www.youtube.com/watch?v=pvP6wmcl_Sc This video is linked on the home page. > crashed the compiler on trivial inputs We have thousands of tests, lots of big projects written in V (V itself…

> 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 codegen, and for the project user such as the need to trust that these different codegens are largely functionally equivalent (exposing and fixing a bug in debug means it would have been but now will not be present in release). But the tcc approach is arguably one of the better ways to minimize the negatives in this tradeoff, compared to cranelift, etc., as tcc is a small but popular enough project in general usage, meaning it has some battle-testing.

And I think the point about projects that "work fine" was quite reasonable, just showing there has been a non-trivial amount of battle-testing. There is now some basis to claim that the project is not full of trivial bugs, to the point of making it useless. Nowhere was it claimed this was a proof of the absence of all bugs -- that you included the Dijkstra quotation in this context is honestly quite humorous.

My understanding is that there has been some drama in the V community in the past, especially around the feature set and release timeline and promises from its author, but I don't see the justification for all this pompous negativity when it is finally out in the wild, warts and all, but showing some nice capabilities at the same time. I don't plan to use it for any hobby projects myself right now, but if I wasn't in the middle of using a different up-and-coming language with some of the same goals, I might.

Re: Hello V-Lang

#90

Post by anecd0te »

lawl wrote: post #27
bheadmaster wrote: post #20

Here are the summarized V features for anyone who dislikes salestalk: - small binaries and fast compilation - cross-platform support - cross-compilation - cross-platform drawing library (GDI+/Cocoa Drawing, OpenGL) - native GUI toolkits (V-UI) - value types - auto-free engine that adds necessary free() commands - C transpilation (both ways, allegedly emits human-readable C) - C foreign function interface ("V can call…

i'm pretty sure that half of these features don't work. Such as the famous "autofree" where everyone doubted it could work and the solution now was.... to drop in boehm-gc. for anyone unfamiliar with v, take everything on that list with a giant spoon full of salt.

I assumed that there was a English language barrier from the original author that made the mistake of present versus future tense for the feature list. When combined with a lack of feature tracking that looked to people like big claims were made without substance, but to me it always felt like everything in V was "work in progress."

They definitely have a hacker mindset to get the minimum working examples through and keep on developing, which is admirable in some ways. The downside is I don't think there's a lot of development experience hanging around that project, so things stick to minimal implementations.

Post reply on HN