5 ms·

Thanks for linking Xe's blog here! It's a few years old and I've seen a lot of comments on HN that suggest V has improved significantly since 2019 so I thought

• Tozen 4y ago
  • mawfig 4y ago
    Every evaluation in my blog is fully reproducible from the version of V I linked to and I've included all the source code used as well. My post stands on it's own. Instead of insinuating I'm some kind of competitor or have a personal agenda, I would encourage you to respond to the actual points raised in my post.
    • Tozen 4y ago
      That's interesting or telling, because if you read what I posted carefully, I was not insinuating anything about your evaluation. Instead, the point was being made that you probably don't want to be associated with an old evaluation from 3 years ago, which is falsely accusing V of being vaporware, and where the author and the developer of V clearly have beefs with each other.
      • xena 4y ago
        Good news: I'm never going to write about V again: https://xeiaso.net/blog/against-toxicity-programming-languages https://xeiaso.net/blog/against-toxicity-programming-languag...
        • Ta2000 4y ago
          Well if you really felt that way I think you'd take any toxic programming articles down. They are etched into your GitHub at this point, so people will still reference them if eager... But at least taking that action of pulling such posts off your website will speak volumes about your character and standing by your words. Otherwise it's just more lip-service; not much different than Alex's lip-service you draw attention to.
        • yjftsjthsd-h 4y ago
          I don't see how that follows? That blog post basically says "don't be toxic about languages". Unless you're using a much broader definition of "toxic" than I'd expect, that doesn't mean you can't write about languages, including fair critiques and even comparisons. I mean, take... "old school" PHP. By all accounts, PHP used to have a lot of sharp edges (in the sense that it was easy to "cut yourself" on it and accidentally do something bad). This was a legitimate, valid problem. It didn't mean that PHP was irredeemably bad, it didn't mean that a dev was A Bad Programmer for writing PHP, but it was true. You can discuss languages, even comparing them to others and pointing out flaws where they exist, without being "toxic" about it.
          • xena 4y ago
            A lot of that post is actually me wanting to be sure that my legacy isn't one of perceived toxicity. When you are in as many minority groups as I am, then you end up becoming an unpaid existential ambassador and you need to be hyper careful to not look like an asshole or do things that could possibly make you look like an asshole because people will assume that being an asshole is a representative sample of those groups. It is not, but logic is not this species' strong suit. Plus, writing about how V is outright lying in its documentation gets boring because it's too easy. There's no real nuance or the like to it. It's someone overpromising and underdelivering, and then you also get the V cult going after you and sending so much hatemail. It's not worth it.
            • yjftsjthsd-h 4y ago
              Okay, fair; those are good reasons. I don't think those fall under the "toxic" label, but they stand on their own regardless. (Not meant as an attack. I suspect that I might be splitting hairs too finely here; I can be a little overenthusiastic about terminology. If so, sorry.)
            • delian66 4y ago
              Hate mail? Really? Care to post an example?
              • 4y ago
        • pwdisswordfish9 4y ago
          Implying here that any post about V is necessarily going to be toxic, because there aren’t any nice things to be said about it?
          • maleldil 4y ago
            Any post criticising V is seen as toxic by their supporters, apparently. You can see many examples of this in this thread.
      • theamk 4y ago
        What do you mean "falsely accusing"? Looks like Xe's blog was correct, V was vaporware back than. According to this post, it still kinda is.. At least the most interesting parts like unique memory management is 100% vaporware.
        • amedvednikov 4y ago
          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 https://www.youtube.com/watch?v=gmB8ea8uLsM
          • vlang1dot0 4y ago
            Your demo includes code that uses manual memory management because of autofree bugs. https://github.com/vlang/ved/blob/9b85e6291c9fe9135db1e300de6a1349dd5f1e6a/ved.v#L660 https://github.com/vlang/ved/blob/9b85e6291c9fe9135db1e300de...
          • super_flanker 4y ago
            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?
            • amedvednikov 4y ago
              Nobody bans for questions. And the video I posted proves that it works. Keeping saying "it doesn't work" is ridiculous.
            • amedvednikov 4y ago
              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?
              • 4y ago
      • super_flanker 4y ago
        And how did you conclude that author is "falsely" making any accusation? Is it similar to your last claim (1) that V doesn't have "null" (which has been debunked)? (1): https://news.ycombinator.com/item?id=31084446 https://news.ycombinator.com/item?id=31084446
    • jacknews 4y ago
      Are there any other language evaluations in your blog, or a plan for any, etc? I'd like to read other reviews, but I only see this one post.
      • mawfig 4y ago
        Sorry, not yet. New to blogging and this took quite a long time to complete to a level I was satisfied with so it will probably be a while before I complete another one.
        • _dain_ 4y ago
          It is a very good first blogpost! I look forward to reading more in this genre. I would particularly like to see similar reviews of the Nim, Odin, Zig, and Janet languages.
      • Tozen 4y ago
        • _dain_ 4y ago
          Do you actually have a substantive rebuttal? "The first and only thing he criticized is V" means nothing at all. What a childish thing to say.
          • delian66 4y ago
            It is a statement of fact. Everyone is free to make their own conclusions from that fact.
      • joshuamorton 4y ago
        For what its worth, the zig site has what is functionally this blog post for its own language: https://ziglang.org/learn/overview/ https://ziglang.org/learn/overview/. There's maybe a few spots where I think they could be clearer about some tradeoffs, but overall its very explicit about what the language can and cannot do, and if I were using this post's style, we'd end up with lots of green checks and 1-2 yellow squares, but nothing red. Which really is the issue here: v makes a big talk but doesn't do what it says on the tin, while other languages, generally speaking, do. There's a difference between goals and features, and Zig distinguishes those well.
    • delian66 4y ago
      > I would encourage you to respond to the actual points raised in my post. ok, here is the first thing that I noticed, reading your blog post/review. > No undefined values ... > C allows you to use an uninitialized variable which can result in Undefined Behavior. I’ll assume that’s what this means. ... > Typically, uninitialized values come from a memory allocation that hasn’t been written to. ... > Let’s see if we can get the V compiler to allocate memory for us without writing to it: fn main() { a := []&int { len: 1 } println(a) } That program segfaulted in the automatically generated string conversion method for the println() call (you created a 1 element array of pointers, and since each of the elements is initialized to 0, you got a 0 pointer, then println tried to show that, but the automatically generated string conversion method did not check for 0 pointers -> the segfault). TLDR: the autogenerated string conversion method has a bug, that will be fixed soon. Ironically, the cause is the opposite of what you intended to show - the memory for the new array was initialized to 0. I would have appreciated a bug report in https://github.com/vlang/v/issues https://github.com/vlang/v/issues , that could be properly tracked till resolution, but apparently people these days have an entire month to dedicate on writing a "review" with a "Rules of engagement" section, but do not have 5 minutes to submit a github issue ¯\_(ツ)_/¯ ... btw, if you instead of the above did: fn main() { a := []int { len: 1 } println(a) } the program (printing `[0]`) will have worked correctly. Edit: I've filed this in https://github.com/vlang/v/issues/14786 https://github.com/vlang/v/issues/14786
      • ptx 4y ago
        Hmm. So the claim article was examining here was "no undefined values", and you point out that the value is actually initialized to 0 and is thus not undefined. However, the vlang.io page also makes the separate claim (as mentioned in the article) of "no null". But you seem to be saying that the bug in this case was actually a null pointer?
        • delian66 4y ago
          Yes, it is a null pointer, produced by the initialization to 0, as you noticed. That is the current state - V wants to prevent setting pointers to arbitrary values, including 0, outside of unsafe code, but not all cases are checked yet, and you can get one. For example, you can also still cast numbers to pointers without unsafe{}: x := voidptr(0) println(x) ... and that will compile without an error, and produce `0x0`. You can also search the issues, and find other examples of code, that ultimately produced null pointers.
    • delian66 4y ago
      > No null > The V docs indicate V has references and “in general, V’s references are similar to Go pointers and C++ references”. The V documentation also has this: https://github.com/vlang/v/blob/master/doc/docs.md#structs-with-reference-fields https://github.com/vlang/v/blob/master/doc/docs.md#structs-w... > Structs with references require explicitly setting the initial value to a reference value unless the struct already defines its own initial value. > Zero-value references, or nil pointers, will NOT be supported in the future, for now data structures such as Linked Lists or Binary Trees that rely on reference fields that can use the value 0, understanding that it is unsafe, and that it can cause a panic. struct Node { val int left &Node right &Node } fn main() { n := Node { 123, 0, 0 } println(n.left) } This is also another example of a program, that would have been perfect as a bug/issue report, so thanks for that I guess. Edit: filed under https://github.com/vlang/v/issues/14785 https://github.com/vlang/v/issues/14785
    • delian66 4y ago
      > No undefined behavior You do have a point here, and we should update the site and the documentation. The current state of V, is that most of the undefined behaviors of C for numbers are also undefined in V too.
    • delian66 4y ago
      > Bounds checking fn main() { x := []&int { len: 10, cap: 0 } println(x[4]) } Again, a bug caused by the auto generated string conversion method for arrays of pointers, that does not check for nil pointers. Once https://github.com/vlang/v/issues/14786 https://github.com/vlang/v/issues/14786 is fixed, that will work too. It has nothing to do with bounds checking, as you can see if you just use `x := []int { len: 10, cap: 0 }` instead. > Allowing the user to control the len property is a really bad idea. Can you clarify what you mean by that?
  • super_flanker 4y ago
    You are not doing yourself any favor by harassing people, if anything it makes you look like a fan-boy. Do yourself a favor, read the article then present a constructive criticism, if any.
  • munificent 4y ago
    > Remember, the competition between various younger languages has become a bit fierce and dirty. As someone who works full time on one relatively young language, has created a couple more, and knows people working on many others, this is 100% wrong in my personal experience. Most young language teams work very hard to communicate accurately and to set appropriate expectations because they know that user trust is a hard requirement for adoption. V is the outlier here.
  • seebs 4y ago
    You say it "comes off as part of an effort ... to mount another attack". Maybe it does to you, but I don't know why. I've never heard of this "fierce and dirty" competition between young languages. I've never seen anything even a bit like that. I've only seen fierce fighting between advocates of large well-established languages. Xe's post struck me as accurate at the time, and having that context to compare with makes V look a little better now, because it at least establishes that progress is being made towards those claims. I don't know where you're getting the idea that this is based on some kind of sinister "personal agenda" other than "this thing sounds interesting, I investigated it, it seems less cool now", which is a pretty defensible position for someone to reach.
    • amedvednikov 4y ago
      It's not accurate. For example, measuring the performance of a debug build, with slow backend, without vlib cached, and with vfmt on. You can see that V is actually as fast as is claimed on the website: https://www.youtube.com/watch?v=pvP6wmcl_Sc https://www.youtube.com/watch?v=pvP6wmcl_Sc Same with other points from the author that publicly claimed that "V has to die".
  • delian66 4y ago
    > I see though that V supports closures. What are the rules for shadowing variables in closures? fn main() { x := 1 y := fn (x int) { println(x) } y(x) y(2) } I am not sure I follow - the `x` parameter for the anonymous function, is entirely different, than the `x` in the main function. For me, there is no way for it to be confused with the `x` inside main. ... y := fn [x] (x int) { println(x) } ... > Well, that seems like it should be disallowed. It makes sense that x can be captured but to then shadow the argument with the same name without error or warning doesn’t seem inline with the rest of V’s behavior. I see what you mean now, yes, that does seem like another good issue candidate. Filed in https://github.com/vlang/v/issues/14787 https://github.com/vlang/v/issues/14787 update: I've responded to the wrong comment, it should have been under https://news.ycombinator.com/item?id=31794565 https://news.ycombinator.com/item?id=31794565
• prirun 4y ago
  I'm always interested in new languages and loved your write-up & evaluation of V. I really don't get the purpose of someone exaggerating the capabilities of their language, to the point of outright lies.
  • dkjaudyeqooe 4y ago
    I think people think that's "marketing".
  • rurban 4y ago
    Unfortunately that's needed nowadays to succeed. Java, Rust and many other would not be successful without standing on the shoulders of its big lies
    • creata 4y ago
      What lies did the Rust developers make? (Also, "nowadays" must stretch out to many decades if you're including Java!)
      • davidkunz 4y ago
        The marketing sentence "A language empowering everyone to build reliable and efficient software." is not true.
        • deleted 4y ago
          [deleted]
      • rurban 4y ago
        The three securities they guarantee and cannot hold. Fearless concurrency. Java also promised memory safety. I still get Null pointer segfaults in Java code.
        • agluszak 4y ago
          > The three securities they guarantee and cannot hold. Could you elaborate? > null pointer segfaults They are not segfaults and are not related to memory safety. Segfault stands for "segmentation fault", not "runtime exception". https://en.m.wikipedia.org/wiki/Segmentation_fault https://en.m.wikipedia.org/wiki/Segmentation_fault
• ylluminate 4y ago