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

331–336 of 336 posts

Re: V Language Review

#331

Post by thomasmangin »

vlang1dot0 wrote: post #303
amedvednikov wrote: post #299

Earlier quoted context omitted.

It was fixed, but you keep fighting your fight. I'm sure there's another bug you can find to spread the "V is scam" message.

You only merged it one hour ago. https://github.com/vlang/v/pull/14805 Over promising (hardly a one line patch) and under delivering (well beyond your "it will be fixed today" statement) as usual.

The check to fix the issue is indeed 8 lines long, and not one, the bulk of the patch is updating the places where the compiler was relying on this behaving with unsafe blocks and the rest is adding tests.

The patch adds two consecutives if statements to forbid the behaviour and could surely be written as a 2 lines or one line patch.

Not checked the timeline. It it is a bit irrelevant, I am not here to score point for either author.

I have a test project of around 5k lines of V, taken from a prototype in Go. Using V has been much more pleasant than Go or Zig, but I like zig comptime features. V is a nice language syntactically. Go has better tooling and is mature. I also rewrote the same code in Zig which I would trust today for production. Finally, I really like zig (and Jai) build system, and Jai very logical design and meta-programming features (no, I am not in the beta).

Hopefully from that statement, everyone can see that I am rooting for the adversarial team and therefore you can all discard my commment as biased

While I would agree with many of the comments regarding how the V site is not clear enough on the level of maturity for each of the attempted goal, and very quick to celebrate work in progress, I feel that balanced comments on this thread are mixed with some which would probably trigger me should I have invested lots of energy in trying to make V successful. Thanksfully I only contributed one AST optimisation as curious bystander, so I can read this thread as most will do: noting how people are capable of listening without hearing.

All this discussion did was to radicalise even more both parties. I would hope V developers will take the time to review what was posted in this thread, when the minds have cooled down, and will try to understand the cultural differences which can exist between people when it comes to reviewing public claims made.

I attempted once to bring this exact topic in the discord channel but reading the room there was zero appetite for change, so I stopped as I felt I would be alienating people if I continued. I self censored to not damage my standing on discord ~ so why am I ruining it with this post: to say that asking people to meet you on your ground to discuss problems is not going to work (general statement) People with nuanced opinion will often shut up when the discussion hits up. When points are not understood, the tension rises and the quality of argumentation reduces very quickly.

My view, and feel free to disagree, is that the V community has been burned out and does not welcome criticism anymore, trust in other developers is broken, from here no constructive discussion can happen anymore and for some participants of this thread the same can be said the other way round.

Team Problem? If it is not communication, it is communication https://www.mtdtraining.com/blog/lencionis-five-dysfunctions...

Re: V Language Review

#332

Post by DeltaMetro »

Rochus wrote: post #59
mawfig wrote: post #45

Earlier quoted context omitted.

Nim and Zig are both pretty interesting to me as up-and-coming languages so I do have them on a short list of things to try. This post took about a month of effort in my spare time to write so I don't think I will get to those anytime soon.

> Nim and Zig are both pretty interesting to me as up-and-coming languages so I do have them on a short list of things to try. Then I take the liberty of doing some promotion for Oberon+ here too.

I had a look at the Oberon+ language definition and noted that one of the most annoying Oberon shortcomings (as compared to Modula-3) still remain: ...from the point of definition to the end of the scope... Oberon+ should have a look at Active Oberon 2019, not for its "active" aspect, but for its syntactical and semantic improvements, like the correction of the above problem.

Re: V Language Review

#333

Post by Rochus »

DeltaMetro wrote: post #332
Rochus wrote: post #59

Earlier quoted context omitted.

> Nim and Zig are both pretty interesting to me as up-and-coming languages so I do have them on a short list of things to try. Then I take the liberty of doing some promotion for Oberon+ here too.

I had a look at the Oberon+ language definition and noted that one of the most annoying Oberon shortcomings (as compared to Modula-3) still remain: ...from the point of definition to the end of the scope... Oberon+ should have a look at Active Oberon 2019, not for its "active" aspect, but for its syntactical and semantic improvements, like the correction of the above problem.

> ...from the point of definition to the end of the scope..

Not sure what you mean. Is it about the fact that all variables are declared in the header of the procedure, i.e. not somewhere in the body as e.g. in C# or Java? This is actually the same with Active Oberon and Modula-3. In case you mean that the order of declarations is relevant, Oberon+ assumes at least a two pass parser by design; a declaration sequence can contain more than one CONST, TYPE and VAR section in arbitrary order, interleaved with procedures, and the order of declaration is not relevant; see e.g. https://github.com/oberon-lang/specification/blob/master/The... and https://oberon-lang.github.io/2021/07/16/comparing-oberon+-w...

Re: V Language Review

#334

Post by DeltaMetro »

Rochus wrote: post #333
DeltaMetro wrote: post #332

Earlier quoted context omitted.

I had a look at the Oberon+ language definition and noted that one of the most annoying Oberon shortcomings (as compared to Modula-3) still remain: ...from the point of definition to the end of the scope... Oberon+ should have a look at Active Oberon 2019, not for its "active" aspect, but for its syntactical and semantic improvements, like the correction of the above problem.

> ...from the point of definition to the end of the scope.. Not sure what you mean. Is it about the fact that all variables are declared in the header of the procedure, i.e. not somewhere in the body as e.g. in C# or Java? This is actually the same with Active Oberon and Modula-3. In case you mean that the order of declarations is relevant, Oberon+ assumes at least a two pass parser by design; a declaration sequence…

Sorry, but I read in your documentation: The Programming Language Oberon+ .... 4. Declaration and Scope Rules .... The scope of an object x extends textually from the point of its declaration to the end of the block (module, procedure, or record) to which the declaration belongs and hence to which the object is local

Re: V Language Review

#335

Post by Rochus »

DeltaMetro wrote: post #334
Rochus wrote: post #333

Earlier quoted context omitted.

> ...from the point of definition to the end of the scope.. Not sure what you mean. Is it about the fact that all variables are declared in the header of the procedure, i.e. not somewhere in the body as e.g. in C# or Java? This is actually the same with Active Oberon and Modula-3. In case you mean that the order of declarations is relevant, Oberon+ assumes at least a two pass parser by design; a declaration sequence…

Sorry, but I read in your documentation: The Programming Language Oberon+ .... 4. Declaration and Scope Rules .... The scope of an object x extends textually from the point of its declaration to the end of the block (module, procedure, or record) to which the declaration belongs and hence to which the object is local

The spec is a work based on the original Oberon-2 spec; I tried to not change too much; in the referenced section I just replaced point 3 (pointer forward declaration) by "The order of declaration is not significant" and thought it was clear enough; apparently not, so I will add some clarifications. At some point I will have to re-write the whole spec.

Re: V Language Review

#336

Post by amedvednikov »

tene wrote: post #320
amedvednikov wrote: post #298

Earlier quoted context omitted.

> every time you're setting an array length in V, any mistake will not be caught by the compiler What mistake? Does this apply to literally every other language, like Go with its `make([]int, len)`. > If you think it's fine for V documentation and advocacy to overstate their case and not mention significant gaps in what they claim the language has Can you link to such examples in V documentation?

If you accidentally make a mistake when setting an array length in V, your program can read from uninitialized memory, as discussed in this article. This program, quoted from the article we're discussing, is accepted by the V compiler, and attempts to read from uninitialized memory: fn main() { x := []&int { len: 10, cap: 0 } println(x[4]) } In this case, the program crashes with a segfault, because the program is si…

> The specific problem is that V lets you directly adjust the array length without doing anything to ensure that the array capacity is at least as large as the newly-specified length.

This is false.

Post reply on HN