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

V Language Review

mawfig.github.io

Post reply on HN
Print view View original

231–240 of 336 posts

Re: V Language Review

#231

Post by spacechild1 »

Tozen wrote: post #230
spacechild1 wrote: post #222

Earlier quoted context omitted.

> As far as I'm concerned, V works as described in their documentation. Really? Can you explain to me how memory management works in V?

V (which is at 0.2.4) is using -gc boehm, which is presently the default. On present versions, you don't have to do anything to enable it. On older versions, you needed to enable -gc boehm. You can choose to use and enable Autofree (-autofree), which works, but you have to know what you are doing. Thus it's best to refer to examples of its usage. Then you can also manage memory manually, where of course you clearly m…

Can you point me to a source that explains how "autofree" is supposed to work?

EDIT:

> which works, but you have to know what you are doing

This does not feel very convincing...

Re: V Language Review

#232

Post by lifthrasiir »

amedvednikov wrote: post #224
lifthrasiir wrote: post #216

Earlier quoted context omitted.

Read correctly; I said extraordinary claims failed V . But the other reading doesn't seem to paint a pretty picture anyway. Every point made in the original article is a reasonable expectation by outsiders, and many of them are still unsatisfactory ("failed claims" if you like). What you should do now is to decide what to do with those points instead of arguing. If the decision is WONTFIX (okay to do, not everything…

Can you elaborate how language features failed V? And what claims were extraordinary? Like the language compiling itself in https://www.youtube.com/watch?v=pvP6wmcl_Sc

Look, you are doing what I've just said not to do. I have nothing to say because the OP did most of claims already, you should directly respond to the OP.

And you are slightly altering the very claim you've already said; the OP specificially tests the claim that "V compiles [...] ~1 million (x86 and tcc backends) lines of code per second per CPU core", which I can easily verify on my machine (1m_helloworld.v took 25.5 and 15.5 seconds to compile under the same settings). To be fair these test files are edge cases you can easily dismiss (ProTip: you can make your advertisements more accurate), but edge cases show the weakness of your design and you should not confront them.

Re: V Language Review

#233

Post by amedvednikov »

tene wrote: post #229
amedvednikov wrote: post #180

Earlier quoted context omitted.

you heard wrong, it's been delivering quite well https://www.youtube.com/watch?v=gmB8ea8uLsM no one has been scammed, whatever that means in opensource development

Oh, that's really cool to hear! I'm glad that they've turned around. So, where can I download the version of V with non-nullable references, no uninitialized memory, no mutation without call-site mutability annotations, that can compile 1M loc/sec, and a functional autofree?

All the features you listed are there, maybe with bugs, which is expected for a 0.2/0.3 version, but they are there.

Re: V Language Review

#234

Post by zaarn »

seebs wrote: post #220
thayne wrote: post #219

Earlier quoted context omitted.

If you know of a case where rust code violates memory safety without the use of an unsafe block, file a bug and it will probably be fixed within a release or two. "Fearless concurrency" is more subjective, but rust code (again with the caveat that there isn't unsafe code, or unsafe cose upholds all unvariants) dows eliminate certain classes of concurrency bugs. Although, dreadlocks are definitely possible, and certai…

Someone pointed out an obvious one: You can open the file "/dev/mem" or equivalent on many Unix systems and break things horribly, and rust can't tell that you're doing it or stop you. Someone used this to write an unsafe-free transmute, which is probably at least two different war crimes. I doubt the rust team will try to "fix" that.

How would anyone go about preventing you from doing that?

Keep in mind /dev/mem is just a convention, I can just mknod it at any place in the filesystem I want. I can even put a FUSE overlay on it that would turn it into a regular file instead of a device node, so you wouldn't have any possible way of telling what you're about to do.

There is no "defense" against /dev/mem, that's just something you don't do as a sane programmer.

Re: V Language Review

#235

Post by rad_gruchalski »

rurban wrote: post #147
creata wrote: post #132

Earlier quoted context omitted.

What lies did the Rust developers make? (Also, "nowadays" must stretch out to many decades if you're including Java!)

The three securities they guarantee and cannot hold. Fearless concurrency. Java also promised memory safety. I still get Null pointer segfaults in Java code.

You most likely get NPEs, not segfaults. I have never seen a segfault in Java and the first Java version I used was 1.5.

Re: V Language Review

#236

Post by xena »

shakow wrote: post #186
xena wrote: post #24

Earlier quoted context omitted.

To be honest having a person's name be the same as their nominative case pronoun is kind of cool from a whole different perspective than you normally get to see. By doing this experiment I get to see how bad of an idea it is to do that. So far the xe/xer pronouns don't seem to stick as well, but it looks cool so I'm gonna keep up the experiment. I'm also quite seriously an ordained minister.

> To be honest having a person's name be the same as their nominative case pronoun is kind of cool The whole point of a person's name is to sufficiently differentiate them from the other persons. Using pronoun as name (or vice versa) just totally negates this goal.

To be fair, the name came first. Then I found out it conflicted with people's pronouns and I sat on the idea for a while. Now I'm throwing science at the wall to see what sticks, and this is a fairly amusing experiment. So I'm gonna keep it going.

Re: V Language Review

#238

Post by tene »

amedvednikov wrote: post #233
tene wrote: post #229

Earlier quoted context omitted.

Oh, that's really cool to hear! I'm glad that they've turned around. So, where can I download the version of V with non-nullable references, no uninitialized memory, no mutation without call-site mutability annotations, that can compile 1M loc/sec, and a functional autofree?

All the features you listed are there, maybe with bugs, which is expected for a 0.2/0.3 version, but they are there.

If someone advertises their language as having no Null, no reading from uninitialized memory, and no mutation of immutable values, then I really do expect to be able to rely on those being completely absent. It is dishonest and shameful to say "No null" on the front page of the website when the developers are well aware of ways that their system fails to actually prevent null references.

If I'm buying a sandwich advertised as "no cockroaches", then I think it's appropriate to be pissed off about there being bugs in my sandwich, especially when it's clear that the sandwich shop knows all about the bugs in the sandwich and they just prefer to falsely claim their absence.

I would have no complaints if the developers would just describe these things as ambitious goals they haven't actually accomplished yet, instead of declaring that they've completed work they know they have not completed.

Re: V Language Review

#239

Post by Tozen »

somethingor wrote: post #237
hunam wrote: post #211

Adding a mention that V is still far from 1.0 in the title or at the beginning would have been honest.

V’s Github description from October 2019 would have disagreed https://web.archive.org/web/20191020121218/https://github.co...

Hopefully what is not being suggested is that creators of open-source programming languages are not allowed to revise their release schedules, underestimate, or change the number of features it will have.

Languages such as Nim have took 11 years before reaching 1.0, so V is still doing comparatively well. V's pace of development has been quite fast and substantial. More comparable languages such as Zig and Odin have yet to hit 1.0 as well, and are many years older.

Yes, the pace of development is getting faster and user patience less, but V should still be afforded some leeway in this regard.

Re: V Language Review

#240

Post by super_flanker »

amedvednikov wrote: post #226
super_flanker wrote: post #200

Earlier quoted context omitted.

Again!! Same video you've been throwing on whoever asks about "autofree", knowing very well that it doesn't work. I asked this question before and was banned on discord, do you have control flow graph analysis anywhere in V? If not, how do you suppose your autofree engine would work flawlessly?

Also, we now have an operating system Vinix, which uses autofree. Does that work as a proof for you or is that also not enough?

And that's why vinix [1] is full of manual free calls? That tells how good autofree is, isn't it? Can you compile v compiler with autofree? Last time I checked, you can't.

[1] https://github.com/vlang/vinix/search?q=free&type=code

Post reply on HN