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

221–230 of 336 posts

Re: V Language Review

#221

Post by spacechild1 »

yjftsjthsd-h wrote: post #103
longrod wrote: post #95

I never understood the motivations behind V. It's clearly not a hobby project started out by a developer who is genuinely experimenting with PLs and want to put out something unique. It feels more like a stunt or a flair to either extort money or become famous. All that would be perfectly okay if V did what it claims to do but the author fanatically makes exciting claims but implements only fluff to hide the underlyi…

> It's clearly not a hobby project started out by a developer who is genuinely experimenting with PLs and want to put out something unique. It feels more like a stunt or a flair to either extort money or become famous. Is that obvious? Yes, if I put on my cynical hat it pattern matches a money-grab or some other sort of fraud, but if I put on my charitable-interpretation hat V also perfectly pattern matches my idea o…

> when it comes to fleshing out every little detail correctly and fully

In the case of V it's not only about details. Memory management, for example, is a fundamental part of a programming language and not something you can do as an afterthought. It is still not clear at all how memory management works in V.

Re: V Language Review

#222

Post by spacechild1 »

Tozen wrote: post #195
super_flanker wrote: post #163

Earlier quoted context omitted.

Even when they are known to be scammers and frauds? V's author is paying others to write things in V (even when basic functionalities don't work as advertised). They don't want to improve the language, they want to create a showcase to attract more funding, that's about it.

From what I've seen, V's author (along with other contributors and sponsors) have been constantly improving the language. Of which, these efforts are applauded by V's users and supporters. As far as I'm concerned, V works as described in their documentation. As with any language, there are some specifics that are subject to interpretation or debate, but that is to be expected. And, V is not doing anything that other…

> 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?

Re: V Language Review

#223

Post by creata »

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.

But you can get away with that in most languages that are generally considered memory safe, so a sane interpretation of the term "memory safety" wouldn't care about that.

Re: V Language Review

#224

Post by amedvednikov »

lifthrasiir wrote: post #216
amedvednikov wrote: post #198

Earlier quoted context omitted.

Can you list here the extraordinary claims that failed please.

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

Re: V Language Review

#225

Post by amedvednikov »

ptx wrote: post #209
amedvednikov wrote: post #199

Earlier quoted context omitted.

V has global consts, they are immutable, but can be initialized with complex expressions, for example `const x = foo()` There's a bug that allows to trick the compiler and modify the const via another variable, it's a one line fix, and will be fixed today. Global mutable variables are only allowed with `-enable-globals` and are supposed to be used only in low level code, like drivers and kernels.

If I understand the example code correctly, it's modifying a heap-allocated struct that's pointed to by a global const. So the global const contains an address which is not modified, but the thing at that address is modified. Right? What does the intended behaviour (after the fix) look like? Are mutable fields in structs disallowed if the struct is pointed to by a const?

After the fix it's not allowed to do

`mut x := immutable_var`

Re: V Language Review

#226

Post by amedvednikov »

super_flanker wrote: post #200
amedvednikov wrote: post #169

Earlier quoted context omitted.

It wasn't vaporware back then, it isn't now. Here's a 1.5 year old demo of V's autofree working: https://www.youtube.com/watch?v=gmB8ea8uLsM

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?

Re: V Language Review

#228

Post by amedvednikov »

super_flanker wrote: post #189
haskellandchill wrote: post #175

Earlier quoted context omitted.

Really? I didn't catch that vibe at all. You're saying if you do this without involving the community it is trolling? I guess it is fair to run the article by the community somehow, but I'm not sure the best approach to that. I'm doing a similar thing for Nim so I would like to not be seen as trolling.

They call names to anybody who dares to ask a genuine question they don't like. It's a meme by now, how easy it is to get banned on V's discord server. I've a feeling that author tried to bring these issues on their discord server, got himself banned and then decided to write a blog.

> They call names to anybody who dares to ask a genuine question they don't like.

Made up nonsense without any proofs.

Re: V Language Review

#229

Post by tene »

amedvednikov wrote: post #180
unclad5968 wrote: post #66

Earlier quoted context omitted.

Mostly because the author completely scammed the shit out of people by promising a ton of things to garner patreon support before open sourcing what was essentially a hobby project at the time. I haven't followed it very closely, but last I heard about it was not delivering on the "autofree" feature. I dont really care about the language. I've tried it a couple times and it's nothing special (to me) so I moved on, bu…

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?

Re: V Language Review

#230

Post by Tozen »

spacechild1 wrote: post #222
Tozen wrote: post #195

Earlier quoted context omitted.

From what I've seen, V's author (along with other contributors and sponsors) have been constantly improving the language. Of which, these efforts are applauded by V's users and supporters. As far as I'm concerned, V works as described in their documentation. As with any language, there are some specifics that are subject to interpretation or debate, but that is to be expected. And, V is not doing anything that other…

> 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 must know what you are doing.

Autofree will not be the default until version 0.3 of the language. Autofree inserts free calls during compilation, and the rest is managed by RC. V will be giving users 3 choices: GC, Autofree, or manual. Those people that actually use the language, would already know this.

This is mentioned on both the website and in the documentation, and any confused users can simply ask on discord (https://discord.com/invite/vlang) or the GitHub discussion (https://github.com/vlang/v/discussions).

Post reply on HN