Hacker News Reader

Comment by davidatbu | Hacker News Reader

Do the referenced compile times also include the time to compile from C to machine code (IIUC, V compiles to C)?

If so, it's incredible to me that this set of tradeoffs (which appear almost as ergonomic as Rust at first glance) can be had while keeping compile times this small!

At first glance, the thing I see as "missing" when comparing this to Rust is traits (or some form of inheritance). The memory management uses a combo of compile-time checking and reference counting by default, so that may take some of the predictability away.

But I mean, this looks like something I'd at least consider for everything except for incredibly perf-sensitive code, (ignoring the network effect of an active dev community, in ML or, frontend ..etc).

EDIT: I recommend you, reader, look at my convo with a maintainer of V below, because I revise my attitude to Vlang due to (IMO) its too-immature nature.

View on HN

That language looks so good because some of the claims are exaggerated, a lot.. Here is a review of previous version:

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

Keyword: previous version. If you scroll down in thread, it's stated that all issues raised in the blog have been fixed. Side note: Github has an issues section on every project which is a better medium.

I don't think so? let's do the first claim in that blog, "No null"

First, does V still claims no nulls? Yep, the release notes say: "Null can be used in unsafe only (for example, for C interop)."

let's test it:

     \   \  /   /  |  Welcome to the V REPL (for help with V itself, type  exit , then run  v help ).
      \   \/   /   |  Note: the REPL is highly experimental. For best V experience, use a text editor, 
       \      /    |  save your code in a  main.v  file and execute:  v run main.v 
        \    /     |  V 0.3.0 ec75860 . Use  list  to see the accumulated program so far.
         \__/      |  Use Ctrl-C or  exit  to exit, or  help  to see other available commands.
    >>>  a := []&int { len: 1 }
    >>>  println(a)
    [nil]
    >>> c := a[0]
    >>> c
    &nil

Yep, here is the null (called "nil" here). And no "unsafe" blocks anywhere.

Let's do another one.. how about "undefined behavior"? Let's try dangling pointer...

    root@7e7c471e6225:/v# cat >> test2.v
    struct Something {
        val   int
    }
    
    fn main() {
        x := voidptr(123)
        y := &Something(x)
        println(y)
    }
    root@7e7c471e6225:/v# ./v run test2.v 
    signal 11: segmentation fault
    /tmp/v_0/test2.14581707097346933317.tmp.c:7071: at print_backtrace: Backtrace
    /tmp/v_0/test2.14581707097346933317.tmp.c:7142: by    v_segmentation_fault_handler
    7fbb67436090 : by ???
    /tmp/v_0/test2.14581707097346933317.tmp.c:12468: by main

nope, not all issues have been fixed. My random sample showed some of them are still there.

you should check the video where they translate doom source to V and compile it[1], almost flawless... the C2V is just a few days old feature, and it is incredible how well works. The more I read about V the more I cannot believe it.

[1] https://www.youtube.com/watch?v=6oXrz3oRoEg

They've been working on C2V for a long time now and even still it falls over quickly for anything other than the exact version of doom they are using. Multiline comments crash the tool for instance.

Complete lies. DOOM is full of multiline comments. And we have a bunch of non DOOM tests.

I don't know what the story behind your account is, but it looks like you've been posting mostly in threads on this one topic for a couple years now. That's not cool on HN, regardless of how good or bad you feel a programming language is.

(I noticed that you've also posted a few comments about other languages, like Rust and C++, but they're a minority of your posts, and unfortunately quite a few have been flamewar comments too - which is not what this site is for.)

HN is for intellectually curious, respectful conversation on topics that interest you. Since agenda-driven or single-purpose accounts aren't compatible with that, we don't allow them here. We also don't allow trollish usernames (see https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...), which given the account history, this looks like.

I've banned the account for that reason, but if you want to pick a different username, we'd be happy to rename it and unban it. hn@ycombinator.com is the best place to let us know what username you'd prefer.

It would be good to review https://news.ycombinator.com/newsguidelines.html and make sure you're down with using HN as intended, too.

Yes! Thank you! I have noticed this account constantly trolling V posts as well, amongst a few other user accounts. I feel it's fine to express concerns in one or two posts, but to repeat them for years is wrong and bullying. Is there a way to submit these accounts or report them?

Thank you.

Thanks!

Glad you like it :) We're really proud of C2V and DOOM.v.

> Do the referenced compile times also include the time to compile from C to machine code

Of course.

I believe you're either the creator or a maintainer of V. Thank you for your open source efforts!

This is my first time running across V, and it looks like the HN community generally considers Vlang's claims misleading.

I found a factual (IMO) evaluation of Vlang's claims here: https://mawfig.github.io/2022/06/18/v-lang-in-2022.html#summ... . I've tried looking at your replies on the HN thread that discusses it, and what I gathered is that almost all of the deficiencies in that analysis are factually correct, but will be corrected in future, non-alpha, versions of Vlang.

Is that impression correct? If not, is there a centralized place where you debunk the claims? (I understand you're an open source contributor and might not have the time, but I'm just letting you know that I won't engage with the language further without seeing something like that).

If my impression was correct, I would like to say that I concur with the general HN sentiment that the state of the language is so immature/alpha as to really cast doubt on whether the list of claimed features will actually be achieved at some point in the future.

All issues mentioned in this anonymous attack blog have already been fixed.

It'd be much faster for the author to submit a couple of github issues, they are fixed very quickly.

The state of the language is anything but immature, all claimed features on the website are very carefully worded, and are all achieved already.

I'll be honest: my decision is that I will come back to Vlang after (at least) six months, and hope that someone does a similar analysis, or do that analysis myself, and then reconsider.

Basically, if the author of that blog posts found (IMO) straightforward ways to invalidate Vlang's claims in ~1 month with the language, I suspect that I will also find _other_ ways to also invalidate Vlang's claims in a straightforward manner. While that's fine for an alpha stage language that I would contribute to, I currently don't have the interest/ability/bandwidth to contribute to a compiler project.

Also, I would like to recommend that you add language to the home page and the Github to the effect of: "Vlang is currently in alpha, and you might discover bugs that contradict some of the claims below. Since this is a WIP project, please contribute!" I literally couldn't Ctrl-F and find the word alpha.

Again, thank you very much for your open source efforts!

Btw, Volt's MacOS app doesn't work (neither the M1 version, nor the Intel). It just displays a blank white page.

I think a version number of 0.3 conveys "alpha".

Thanks! I honestly didn't know that, and thought pre1.0 software can be either beta or alpha, arbitrarily. Is there some decimal cutoff between alpha and beta?

> Is there some decimal cutoff between alpha and beta?

No, because they are human labels, not computer generated titles for specific versions. Both are below 1.0 (so, not "production ready",constantly in flux, anything can change, here be dragons etc etc) and that's all that matters. If it's alpha/beta is the same, the project is probably not ready for you to ship to production for real users, right at this moment. That's what those labels are trying to convey.

Note: I'm not talking about V specifically here, but the labels themselves and software versioning in general

Thanks!

It's interesting how you can call the language immature without even trying it.

0.3 pretty clearly means it's not production ready software.

If I had done the analysis in that blogpost (whose factual accuracy you corroborated) myself, I would have come to the same conclusion. Fortunately, the internet allows people to publish blogs where they share such analyses, so that effort doesn't have to be duplicated.

> 0.3 pretty clearly means it's not production ready software.

Despite the version 0.3 being visible, it is obvious that many more people than normal find that the wording on Github and the home page misleading (me included!). Obviously, this is a bit subjective, and I am telling you what I, personally, would have found a better signal to hone my expectations.

If you're interested in why that might be, I think it's because several other software projects I've used that are pre-1.0 don't have major bugs that interfere with their primary value proposition (like in Vlang). Off the top of my head, neovim, rocket (a rust webframework), mypy, reqwest come to mind.

It would take you literally a couple of minutes to try it yourself and see it all works. Less time than it took you to type these messages.

> If I had done the analysis in that blogpost (whose factual accuracy you corroborated) myself, I would have come to the same conclusion.

No, you would not even be able to reproduce those bugs, because they have been fixed.

> don't have major bugs that interfere with their primary value proposition (like in Vlang).

can you list such major bugs here please?

> It would take you literally a couple of minutes to try it yourself and see it all works.

I had previously said: "if the author of that blog post found (IMO) straightforward ways to invalidate Vlang's claims in ~1 month with the language, I suspect that I will also find _other_ ways to also invalidate Vlang's claims in a straightforward manner."

Unfortunately, I don't have a month of spare time, like that blogger, to put towards that effort.

> can you list such major bugs here please?

It might be (though I doubt it) that the major bugs outlined in that blog post (which your community promptly fixed) happen to be the final set of such major bugs that interfere with Vlang's primary value proposition. Like I said, I'm not willing to put a month of spare time to find out.

I will almost certainly check back after some time (probably more than 1 year), and hopefully by then I will have the spare time to do the inspection, or someone else will have done it. I sincerely hope that you and your community succeed in achieving your goals! Good luck!

So you can't list the major bugs here.

Then please don't spread the misinformation that V has "major bugs that interfere with their primary value proposition".

> But I mean, this looks like something I'd at least consider for everything except for incredibly perf-sensitive code,

Which is true of nowadays of the majority of languages very much including managed languages in the pack.

Reply on news.ycombinator.com