71–80 of 86 posts
Earlier quoted context omitted.
Imagine thinking that GitHub stars are indicative of anything at all. You might as well measure popularity by how many times your webpage has been bookmarked.
my point is, who cares? if they like it so what?
Earlier quoted context omitted.
my point is, who cares? if they like it so what?
Who cares? These people seem to care https://twitter.com/v_language/status/1339223357800263682?s=...
Seems like you also care a big deal about these GitHub stars for someone who doesn't like the project and your name checks out too.
Earlier quoted context omitted.
Things have improved but it's not clear the author realizes the magnitude of what he's trying to do. The big ticket item is the autofree memory management system which promises near C/Rust performance and minimal overhead without the complexity of borrowing and ownership. To date, this system does not work and is "wip" as the vlang community likes to say. There are also no clear explanations of how it works beyond ju…
> Initially the goal was that this system would manage all memory for the programmer automatically, this goal has since moved to "manage 90% of objects in memory and use GC for the rest". I suspect we will see that number continue to drop as the author realizes this is intractable without whole program analysis (which they can't do and still hit their compilation time targets). A demo of autofree with zero GC/RC: htt…
V is shady AF. Steer clear of it.
Either that's slander, or it needs some explanation and, preferably, documentation.
[0] anyone with proper knowledge doesn't claim they can "avoid GC by automatically inserting calls to free"
Its disturbing how this shitfest even gets treated as real, even people who made reasonably good languages (crystal, nim, odin) did not get the hype this got.
Earlier quoted context omitted.
Do you have links to false claims about Nim?
I don't and to be fair, from what I recall, these were dropped from the V website as soon as the Nim community challenged them.
This can be verified via web archive.
This has been the only mention of Nim.
What claims are false?
You make very big accusations ("a lot of false claims about itself but also other existing programming languages", "a true example of how far pushing false promises and lies can get you and it makes me a bit sad about the world"), and yet you can't provide examples of such claims and lies.
Earlier quoted context omitted.
> Initially the goal was that this system would manage all memory for the programmer automatically, this goal has since moved to "manage 90% of objects in memory and use GC for the rest". I suspect we will see that number continue to drop as the author realizes this is intractable without whole program analysis (which they can't do and still hit their compilation time targets). A demo of autofree with zero GC/RC: htt…
You solved the memory management for one particular program written in exactly the style necessary to avoid leaks for the demo. You'll find as you fix other programs, you'll introduce UAFs into this one which is, I suspect, one reason your commit activity around autofree has basically dropped to 0 recently.
Nothing, as I expected.
Earlier quoted context omitted.
I get your point, but it doesn't look like this project would be ignored for some time, though it also makes some sense to market some features of the language with some demos, UI, GL and even an OS to show its capabilities. And if you ask me, it's very impressive that an OS can be written in V as well.
It's not terribly impressive when the compiler just outputs C and invokes TCC or your platform's compiler to do the actual work. V is far more like a different syntax for C than it is a real language. Perhaps one day that will change but currently V is to C as CoffeeScript is to JavaScript.
Coffeescript also gained popularity (perhaps until JS caught up and render CS not relevant anymore)
Earlier quoted context omitted.
I meant both V-lang making false claims about itself and making false claims about Nim.
Please get specific - not sure what you're talking about. I've only ever seen other folks coming in and attacking V really quite baselessly.
Earlier quoted context omitted.
It's not terribly impressive when the compiler just outputs C and invokes TCC or your platform's compiler to do the actual work. V is far more like a different syntax for C than it is a real language. Perhaps one day that will change but currently V is to C as CoffeeScript is to JavaScript.
hmm. IIRC, C++ also started by compiling to C. Typescript also compiles to JS. CMIIW. Coffeescript also gained popularity (perhaps until JS caught up and render CS not relevant anymore)
Earlier quoted context omitted.
You solved the memory management for one particular program written in exactly the style necessary to avoid leaks for the demo. You'll find as you fix other programs, you'll introduce UAFs into this one which is, I suspect, one reason your commit activity around autofree has basically dropped to 0 recently.
> Can you list items that don't work at all or are in alpha state? Nothing, as I expected.
Since you want it so much, here you go:
- "No undefined behavior" -> How does V prevent this? V currently can't even generate well formed C code for all valid V so how do you prevent UB in the generated C? As of now, for any reference x in V, *x and ******x are both accepted by the checker. int32.MAX + 1 is instant UB yet V does nothing to prevent this. What is your plan to prevent UB in the generated C?
- Generics -> The example shown in your own docs expresses how "wip" this is (https://github.com/vlang/v/blob/master/doc/docs.md#generics). Why is `T.name` allowed? `T` can be literally anything since there is no constraint on it. You're obviously deferring type checking the function until it's monomorphized which is far more like C++ templates than "generics". How do you plan to deal with template bloat slowing down compilations?
- -usecache -> Another one of the 20% implemented features. This was done to give V a huge boost in compiling simple programs but the implementation is so busted, you yourself disabled it on the benchmarking site.
- "go" keyword -> From your docs: "V's model of concurrency is very similar to Go's. To run foo() concurrently in a different thread, just call it with go foo()". At least you've documented it but have completely buried the lede that unlike Go, `go` spawns an OS thread not a green thread. Speaking of green threads, how do you propose to keep the efficiency you claim ("within 3% of C") while still having transparent C interop? Are you going to use segmented stacks to allow 100,000s+ green threads and then run into the same issues Go has calling into C or are you going to larger stacks to make C interop feasible which limits how many green threads you can run before using enormous amounts of memory?
- "immutable" references -> As shown on Discord, "immutable" references can easily by laundered into mutable ones by assigning the reference to a mutable variable and then assigning into that.
- native backend -> Can handle hello world and programs that use string interpolation. Given that it can't handle the average 100 line V program, you should not be extrapolating the performance of 1,000,000 V programs.*