5 ms·

There are 0 false claims about language capabilities on the website or in the docs. If you can link one, that'd be great, and it'll be fixed. I've spent a lot

There are 0 false claims about language capabilities on the website or in the docs. If you can link one, that'd be great, and it'll be fixed. I've spent a lot of time verifying all claims are valid. For example there was the "functions are pure by default except IO" which caused lots of criticism and memes. I simply changed the wording to a more verbose but correct phrase. So we do admit shortcomings and not make up excuses "for each of them" We do not delete criticisms, we actually welcome them and any kind of feedback: https://github.com/vlang/v/discussions/7610 https://github.com/vlang/v/discussions/7610

paskozdilar 4y ago
So you're sticking with "people are evil and hate me"?
- amedvednikov 4y ago
  So can you list the "false claims about language capabilities" here?
  - paskozdilar 4y ago
    You're reading my words, but you're not trying to understand what I'm saying. Unless you demonstrate an honest effort to understand, I will not continue this pointless argument.
    - amedvednikov 4y ago
      You said there are false claims about language capabilities, I asked you to list them. It's a reasonable request. I don't want to have false claims on the website.
  - defen 4y ago
    Saying "no undefined behavior" when what you really mean is "We define our language's behavior to be the same as C's" (in other words, you just punt undefined behavior to the C compiler) is deceptive at best. I'm specifically thinking of signed integer overflow here, but that makes me think there may be other cases as well.
zamberzand 4y ago
In my opinion, the current documentation on the autofree engine [0] constitutes a false claim about language capabilities: > Most objects (~90-100%) are freed by V's autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via reference counting. > The developer doesn't need to change anything in their code. "It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything or expensive RC for each object. [0]: https://github.com/vlang/v/blob/master/doc/docs.md#memory-management https://github.com/vlang/v/blob/master/doc/docs.md#memory-ma... So, I am not entirely sure the best way to quantify whether this is true. However, I thought a fun test would be recreating "my first memory leak" -- the first memory leak I can remember fixing in code that I wrote. Specifically, I was essentially leaking some bespoke heap-allocated iterators I had created (inside of an infinite game loop). So here is my little test: struct Iter { mut: pointer int } fn main() { my_array := [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ] for true { // simulated game loop mut iter := &Iter { 0 } // heap allocated iterator for iter.pointer < my_array.len { print(my_array[iter.pointer]) print(" ") iter.pointer += 1 } println("") } } I compiled this with -autofree -gc none, with V 0.3. Checking it with valgrind, it continuously leaks memory. So, from what I can tell, this description of the autofree engine in the documentation does not accurately describe the existing functionality available in V. I am curious where the 90%-100% figure comes from. It is such a specific number that it implies to me, as a reader, that it comes from an empirical measurement of an existing system. But, there is no link to where this measurement was taken. In my opinion, the documentation should include some details about how these figures were generated.
- amedvednikov 4y ago
  No, it describes it absolutely accurately: > until V's autofree engine is production ready.
  - zamberzand 4y ago
    So, to be clear, is the intended reading of the documentation as follows? > Most objects (~90-100%) are freed by V's autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via reference counting. > The developer doesn't need to change anything in their code. "It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything or expensive RC for each object. > These points are both currently untrue, and should not be relied on in code. I'm hoping I don't come off as flippant here. I just don't see any way to interpret these claims as an accurate description without adding that third bullet point.

paskozdilar 4y ago

So you're sticking with "people are evil and hate me"?

amedvednikov 4y ago
So can you list the "false claims about language capabilities" here?
- paskozdilar 4y ago
  You're reading my words, but you're not trying to understand what I'm saying. Unless you demonstrate an honest effort to understand, I will not continue this pointless argument.
  - amedvednikov 4y ago
    You said there are false claims about language capabilities, I asked you to list them. It's a reasonable request. I don't want to have false claims on the website.
- defen 4y ago
  Saying "no undefined behavior" when what you really mean is "We define our language's behavior to be the same as C's" (in other words, you just punt undefined behavior to the C compiler) is deceptive at best. I'm specifically thinking of signed integer overflow here, but that makes me think there may be other cases as well.

zamberzand 4y ago

In my opinion, the current documentation on the autofree engine [0] constitutes a false claim about language capabilities: > Most objects (~90-100%) are freed by V's autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via reference counting. > The developer doesn't need to change anything in their code. "It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything or expensive RC for each object. [0]: https://github.com/vlang/v/blob/master/doc/docs.md#memory-management https://github.com/vlang/v/blob/master/doc/docs.md#memory-ma... So, I am not entirely sure the best way to quantify whether this is true. However, I thought a fun test would be recreating "my first memory leak" -- the first memory leak I can remember fixing in code that I wrote. Specifically, I was essentially leaking some bespoke heap-allocated iterators I had created (inside of an infinite game loop). So here is my little test: struct Iter { mut: pointer int } fn main() { my_array := [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ] for true { // simulated game loop mut iter := &Iter { 0 } // heap allocated iterator for iter.pointer < my_array.len { print(my_array[iter.pointer]) print(" ") iter.pointer += 1 } println("") } } I compiled this with -autofree -gc none, with V 0.3. Checking it with valgrind, it continuously leaks memory. So, from what I can tell, this description of the autofree engine in the documentation does not accurately describe the existing functionality available in V. I am curious where the 90%-100% figure comes from. It is such a specific number that it implies to me, as a reader, that it comes from an empirical measurement of an existing system. But, there is no link to where this measurement was taken. In my opinion, the documentation should include some details about how these figures were generated.

amedvednikov 4y ago
No, it describes it absolutely accurately: > until V's autofree engine is production ready.
- zamberzand 4y ago
  So, to be clear, is the intended reading of the documentation as follows? > Most objects (~90-100%) are freed by V's autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via reference counting. > The developer doesn't need to change anything in their code. "It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything or expensive RC for each object. > These points are both currently untrue, and should not be relied on in code. I'm hoping I don't come off as flippant here. I just don't see any way to interpret these claims as an accurate description without adding that third bullet point.