8 ms·

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 syst

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 just "it inserts calls to free() when you are no longer using a variable" which is ... extremely obvious. The more interesting question of how the compiler determines something is no longer being used in the face of aliasing and no borrowing system is completely unanswered. No one working on the project understands how complex that problem is. 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). Other items are very much in an alpha state if they work at all. Only in the last month have you been able to create a generic function with more than one type parameter, although V has been claiming support for generics since at least last year. There's still no ability to constrain the type parameter to something that implements an interface/trait/protocol. C2V, another wildly ambitious project that could literally be a PhD project in automatic language translation, was supposed to be released "this week" 5 weeks ago. It's currently in a very private alpha and no source has been released. Which is basically the state of most of the author's projects: huge promises in terms of features and performance with most of them little more than demos. I've come to believe this is an intentional strategy by the author to maximize his Patreon revenue. He makes big promises on social media and then delivers the easy 20% of the project to his followers before switching to another project. It would make far more sense to release a finished project before starting another massive one and yet he can't sit down and finish a project because he knows he can't actually deliver what's been promised.

creata 5y ago
Reminds me of this line by tom_mellior[0]: > I wish people stopped approaching language design from the point of view that the people who have been working on garbage collection for the last 60 years are all idiots who don't see how simple it all is. [0]: https://news.ycombinator.com/item?id=26765369 https://news.ycombinator.com/item?id=26765369
- Twirrim 5y ago
  Honestly, that describes a lot of the tech hype cycle. The classic example would be MongoDB and other NoSQL solutions etc. in the early days. We can be lightning fast compared to these RDBs! Clearly they're idiots, as is anyone that uses them! Oh wait, what? You mean it's hard to actually work with data durably, and that not doing so is the main reason we're faster... crap.
noobermin 5y ago
I remember the hubbub a year (or longer? another covid timewarp) ago when this first came out. It looks like now the dev of V is just pulling under 1K a month so it's not like he's making bank so if they're still just grifting it's not really working.
- ylluminate 5y ago
  No grifting going on. We have a vibrant awesome community that feels very Ruby-like in many ways. Good people.
- vlang1dot0 5y ago
  He lives in Sweden where the cost of living is quite a bit lower than most of the US and also has people contributing to him on GitHub. A quick Google search suggests it's quite possible to live on $1k a month in Sweden for one person but I admit I have no personal experience in that point. Edit: I was wrong about the location but that does not change my opinion.
  - ylluminate 5y ago
    No, he does not live in Sweden.
  - eberkund 5y ago
    The cost of living in Sweden is not quite a bit lower than most of the US. It may be less than Manhattan or SF but it's certainly not cheap, especially compared to most of the US. I visited Sweden a few years back and found most things to be very expensive and I just did a quick Google search now to confirm before writing this comment.
ylluminate 5y ago
These issues should / could all be addressed - if you're in Discord already, which it sounds like you probably are, feel free to talk about each point. The C2V source IS in fact, already available to many folks (v devs specifically, of which there are many).
- vlang1dot0 5y ago
  The last time I asked about how the memory management would work, the conversation was quickly shut down by a vlang dev (not Alex) who grilled on me on why I wanted to know how the language worked. I've seen this same reaction to other newcomers who dare to ask reasonable questions instead of simply drinking the Kool aide.
  - ylluminate 5y ago
    Strange, I'll mention it. There have been a lot of crazy trolls so a few folks are a bit thin on the patience front - especially a few who are crazy hard at work all the time on the language. I do have sympathy for them and they're great folks if you just try to understand the history and their own context a bit.
    - vlang1dot0 5y ago
      I think it would be more productive to direct the attention to https://github.com/vlang/v/issues/1247 https://github.com/vlang/v/issues/1247 which catalogues a number of issues with the proposed approach and yet hasn't had any activity in 9 months.
  - super_flanker 5y ago
    Ditto same experience, I asked if somebody could explain me the memory model of V; and all of sudden hell broke loose. I was asked why do I need to know how memory model worked, are you a troll, if you don't contribute to the lang you're not welcome here. Never asked a second question again.
    - 5y ago
agumonkey 5y ago
who inspired who here ? musk or v-author ?
amedvednikov 5y ago
> 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: https://www.youtube.com/watch?v=gmB8ea8uLsM https://www.youtube.com/watch?v=gmB8ea8uLsM > Other items are very much in an alpha state if they work at all. Can you list items that don't work at all or are in alpha state? Generics missing some advanced features like protocols doesn't mean they don't work. And no I don't live in Sweden. You seem to get a lot of things about V wrong.
- vlang1dot0 5y ago
  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.
  - amedvednikov 5y ago
    > Can you list items that don't work at all or are in alpha state? Nothing, as I expected.
    - vlang1dot0 5y ago
      No reply to the autofree comment? Unsurprising. 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 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.*

creata 5y ago

Reminds me of this line by tom_mellior[0]: > I wish people stopped approaching language design from the point of view that the people who have been working on garbage collection for the last 60 years are all idiots who don't see how simple it all is. [0]: https://news.ycombinator.com/item?id=26765369 https://news.ycombinator.com/item?id=26765369

Twirrim 5y ago
Honestly, that describes a lot of the tech hype cycle. The classic example would be MongoDB and other NoSQL solutions etc. in the early days. We can be lightning fast compared to these RDBs! Clearly they're idiots, as is anyone that uses them! Oh wait, what? You mean it's hard to actually work with data durably, and that not doing so is the main reason we're faster... crap.

noobermin 5y ago

I remember the hubbub a year (or longer? another covid timewarp) ago when this first came out. It looks like now the dev of V is just pulling under 1K a month so it's not like he's making bank so if they're still just grifting it's not really working.

ylluminate 5y ago
No grifting going on. We have a vibrant awesome community that feels very Ruby-like in many ways. Good people.
vlang1dot0 5y ago
He lives in Sweden where the cost of living is quite a bit lower than most of the US and also has people contributing to him on GitHub. A quick Google search suggests it's quite possible to live on $1k a month in Sweden for one person but I admit I have no personal experience in that point. Edit: I was wrong about the location but that does not change my opinion.
- ylluminate 5y ago
  No, he does not live in Sweden.
- eberkund 5y ago
  The cost of living in Sweden is not quite a bit lower than most of the US. It may be less than Manhattan or SF but it's certainly not cheap, especially compared to most of the US. I visited Sweden a few years back and found most things to be very expensive and I just did a quick Google search now to confirm before writing this comment.

ylluminate 5y ago

These issues should / could all be addressed - if you're in Discord already, which it sounds like you probably are, feel free to talk about each point. The C2V source IS in fact, already available to many folks (v devs specifically, of which there are many).

vlang1dot0 5y ago
The last time I asked about how the memory management would work, the conversation was quickly shut down by a vlang dev (not Alex) who grilled on me on why I wanted to know how the language worked. I've seen this same reaction to other newcomers who dare to ask reasonable questions instead of simply drinking the Kool aide.
- ylluminate 5y ago
  Strange, I'll mention it. There have been a lot of crazy trolls so a few folks are a bit thin on the patience front - especially a few who are crazy hard at work all the time on the language. I do have sympathy for them and they're great folks if you just try to understand the history and their own context a bit.
  - vlang1dot0 5y ago
    I think it would be more productive to direct the attention to https://github.com/vlang/v/issues/1247 https://github.com/vlang/v/issues/1247 which catalogues a number of issues with the proposed approach and yet hasn't had any activity in 9 months.
- super_flanker 5y ago
  Ditto same experience, I asked if somebody could explain me the memory model of V; and all of sudden hell broke loose. I was asked why do I need to know how memory model worked, are you a troll, if you don't contribute to the lang you're not welcome here. Never asked a second question again.
  - 5y ago

agumonkey 5y ago

who inspired who here ? musk or v-author ?

amedvednikov 5y ago

> 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: https://www.youtube.com/watch?v=gmB8ea8uLsM https://www.youtube.com/watch?v=gmB8ea8uLsM > Other items are very much in an alpha state if they work at all. Can you list items that don't work at all or are in alpha state? Generics missing some advanced features like protocols doesn't mean they don't work. And no I don't live in Sweden. You seem to get a lot of things about V wrong.

vlang1dot0 5y ago
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.
- amedvednikov 5y ago
  > Can you list items that don't work at all or are in alpha state? Nothing, as I expected.
  - vlang1dot0 5y ago
    No reply to the autofree comment? Unsurprising. 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 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.*