I really don't get the purpose of someone exaggerating the capabilities of their language, to the point of outright lies.
(Also, "nowadays" must stretch out to many decades if you're including Java!)
Fearless concurrency.
Java also promised memory safety. I still get Null pointer segfaults in Java code.
> 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
"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 certain kinds of race conditions could potentially exist. But I don't know of any claims that concurrency bugs are impossible in rust.
and looking at their compiler it's clear why. stack-allocation of vars is fine and dandy, but comparable to vlang's famous unbounded autofree system. alloca() is dangerous for a reason.
unsafe vec, really?? mutexes in threads, really?? concurrent blocking IO in this decade??
also read their docs about their unsafeties, and concurrency deficiencies. compare that to the docs of real safe languages. you won't find such chapters, because safe languages are safe, not just almost-safe.
First of all, most of those erorors are about stack overflows in the compiler not the compiled program. And secondly, stack overflow isn't a memory safety issue like, say use-after-free, uninitialized variables, data races, etc. If you allow recursive function calls, you can't really prevent stack overflows.
> alloca() is dangerous for a reason
Rust doesn't have an equivalent of alloca.
> unsafe vec, really??
I'm not sure what you are referring to here.
> mutexes in threads, really??
What does this have to do with memory safety? The only language with threads I know of that doesn't have mutexes is Erlang. And rust Mutexes are better than mutexes in most other languages because you can't access the data protected by the mutex at all, unless you have a lock. And the lock is automatically freed when it goes out of scope.
> concurrent blocking IO in this decade??
Again, what does this have to do with memory safety? And for many applications blocking IO is fine. You don't always need the performance of async I/O which adds complexity. And if you do need async i/o, rust has options there too (just not in the standard library).
> also read their docs about their unsafeties, and concurrency deficiencies.
The Rust Programming Language book has one section of one chapter on "unsafety", and that is specifically on using the `unsafe` escape hatch. Yes, there is a separate book about how to write a `unsafe` code that maintains rust's safety garantees. but that is limited to `unsafe` blocks, which in many cases you can just avoid using. As compared to c or c++, where the entire language is full of potential safety problems.
> compare that to the docs of real safe languages. you won't find such chapters, because safe languages are safe, not just almost-safe.
What "real safe languages" would those be? Can they be used in all the same domains as rust?
https://github.com/vlang/v/issues?q=is%3Aissue+is%3Aopen+sta...
I've never had one in 3 years.
edit: ah, you meant Rust
I doubt the rust team will try to "fix" 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.
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.
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.
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.
(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.)
1. They don't post it, and get accused of lying.
2. They post one of the tamer examples, and get accused of overreacting to nothing.
3. They post a median example, and get told that people reacting with vigour is normal and it's not about them.
4. They post a very strong example, hurting some readers and get responses claiming that you clearly can't take threats at face value.
5. They get accused of making it up, anyway.
6. They don't include personal details, so you can't do anything, anyway.
7. They include personal details and get accused of doxxing or making it personal.
There's just no good outcome from your request.
Especially after writing "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."
=> xena does acknowledge, that most people will assume that the whole V community is hateful, and even then, used terms like "V cult" and "hatemail".
Accusing an entire community of people of hate, for the actions of a single one, is not nice at all, especially, when it is done without evidence, with just vague descriptions.
Have you considered, that in all these, it may be the V developers, that are in the minority???
According to this post, it still kinda is.. At least the most interesting parts like unique memory management is 100% vaporware.
Here's a 1.5 year old demo of V's autofree working:
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?
The resulting executable however does segfault - try it with:
./v -autofree -o x cmd/v
./x version
Doesn't give lot of confidence that it works, does it?
> You seem to talk a lot about things, that you are not well informed about.
Unlucky for you, it's not discord, you can't ban me here. So freaking deal with it.
Letting them speak and reveal how vile they are is better in my experience.
And the video I posted proves that it works. Keeping saying "it doesn't work" is ridiculous.
https://github.com/vlang/ved/blob/9b85e6291c9fe9135db1e300de...
fn main() {
x := []&int { len: 10, cap: 0 }
println(x[4])
}
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?
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.
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.
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)
}
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 , 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)
}
Edit: I've filed this in https://github.com/vlang/v/issues/14786
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?
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)
You can also search the issues, and find other examples of code, that ultimately produced null pointers.
You would think that someone taking that long to do an evaluation of claims would reach out to the V developers in some way. Like via bug report, e-mail, discord, or discussion... If a person doesn't want to give the appearance of doing an attack or "hit piece", you would think they would at least create some plausible deniability for themselves, by taking in account the perspective or response of the language developers.
I'm glad you are taking the time to do counter points and add issues on GitHub (https://github.com/vlang/v/issues), as this situation can be turned to being helpful for V. Whatever is in the evaluation that has some validity, can then be corrected or V developers can point how the evaluation was in error or mistaken.
The V documentation also has this: 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)
}
Edit: filed under https://github.com/vlang/v/issues/14785
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.
You can see that V is actually as fast as is claimed on the website:
https://www.youtube.com/watch?v=pvP6wmcl_Sc
Same with other points from the author that publicly claimed that "V has to die".
fn main() {
x := 1
y := fn (x int) {
println(x)
}
y(x)
y(2)
}
... 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
update: I've responded to the wrong comment, it should have been under https://news.ycombinator.com/item?id=31794565