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.
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.
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.
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.
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?
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.
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.
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
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.
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!
The list of features looks incredible, I would say it's everything RUST wanted to be but never could... however Rust hot Linus Torvalds' support and made it into the kernel.
I have yet to check whether function completeness is mandatory for V's match on sum types.
At the end of the thread, medvednikov wrote this just before closing the issue:
> “Zero leaks when using autofree which will become the default in 0.3:”
I guess they did make autofree enabled by default in this release.
If they did not fix that issue it means that you still can not get leak-free programs with manual memory management, which contradicts my understanding of their claim:
> “For developers willing to have more low level control, autofree can be disabled with -manualfree, or by adding a [manualfree] on each function that wants manage its memory manually.”
You can disable autofree, but then you can not have a leak-free program no matter what you do. Now, that leak is at the end of its execution so it’s not a problem when using the program, but it is when developing it as those leaks will obscure any other that you might be trying to remove, or even notice.
I mean what it would be nice to have no forced leaks also when using the -manualfree command line option.
However, I just checked, and the 0.3 release does leak even without -manualfree!
lxc launch images:debian/bullseye test-v
lxc exec test-v bash
# Inside the container:
apt install build-essential git valgrind
git clone https://github.com/vlang/v
cd v
git rev-parse HEAD
# 74bb5ae17a4a0af8dda913ddb1ca9d8d4a590136
make
# ...
# Your `tcc` is working. Good - it is much faster at compiling C source code.
# V has been successfully built
# V 0.3.0 74bb5ae
./v examples/hello_world.v
valgrind --leak-check=yes examples/hello_world
# ... report about invalid read of size 1.
# ... reports about uninitialized values.
# ==5750== LEAK SUMMARY:
# ==5750== definitely lost: 0 bytes in 0 blocks
# ==5750== indirectly lost: 0 bytes in 0 blocks
# ==5750== possibly lost: 1,360 bytes in 5 blocks
# ==5750== still reachable: 0 bytes in 0 blocks
# ==5750== suppressed: 0 bytes in 0 blocks
# ...
# ==5750== ERROR SUMMARY: 144 errors from 17 contexts (suppressed: 0 from 0)
apt install wget unzip
rm v -r
wget https://github.com/vlang/v/releases/download/0.3/v_linux.zip
sha1sum v_linux.zip
# bb6f81630fe2ae4e7e283360f507be99f88f32bd v_linux.zip
unzip v_linux.zip
cd v
./v examples/hello_world.v
valgrind --leak-check=yes examples/hello_world
# Exact same result as above, just a different PID of course.
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.