Closed gingerBill closed 2 years ago
medvednikov
commented
5 years ago @thebirk see this discussion
https://news.ycombinator.com/item?id=15903584
There's historically been a fairly big gap between "very little runtime" and "more runtime", so "no runtime" and "runtime" are what people say.
I agree with this definition, and I'll make it clear on the website to avoid confusion.
Kelimion
commented
5 years ago I'm not calling everything misinformation. I'm calling claims like
Not only that, software purported to have been written in this language or transpiled to it, far exceeds the complexity of even the simple things that failed in the playground.
Like this you mean? An assertion of mine which was later backed up by you yourself when you stated this:
No, this is x64 machine code generation. In 0.5s you'll get a binary. At this stage it's not going to work with such a complex application like Doom 3, so I'll change it to a simpler app.
Look. I don't assume ill-intent on your part. From what I've seen you appear rather a bit overenthusiastic and relatively inexperienced compared to say @gingerBill or myself. That's okay, we all had to start somewhere. It also looks to be the case that you have a different view of certain definitions than are orthodox in the compiler construction community and its theory.
It is however disingenuous at best to take a novel definition and assert it's the people who use the traditional meaning of those things as the basis of their observation who have it wrong. And finally, after much hand-wringing on this subject, you listen when @thebirk says Well then you should probably advertise your language as having a lightweight runtime, instead of saying it has no runtime.
As for questions by myself and others about complex software written in V, you countered this by pointing to your editor (among other projects): Volt (volt-app.com) and Vid editor, my primary editor for the last 1.5 years (github.com/medvednikov/vid) are written 100% in V. That's more than 100,000 lines of code.
Would it surprise you to learn that a repository with just a README file for an editor that's been in use for 1.5 years isn't exactly a compelling way to debunk such questions? I hope you can see that it hurts your credibility when you delete comments and call things misinformation when they are clearly not.
Again, I'm not assuming ill-intent, but I hope you can see that there's a large gap between the way you presented the language and its maturity and the actual verifiable proof you provide. We're not trying to attack you. I know I'm not, at least. I am however - as said previously - interested in low-level languages like V.
I wish it to succeed and live up to your goals for the language, very much so. I also believe it is fair to ask that the description of the language is congruent with its state and vice versa. You have started to address some of these points and I commend you for it.
So to summarise let's take it as read that you're not the bad guy. Neither are we. Maybe you could lay off terms like 'misinformation' and 'debunk'? Especially seeing as you've acknowledged and addressed some points made already. The way you've handled things so far only increases scepticism in the casual observer, I would think.
medvednikov
commented
5 years ago This is about x64 compilation, which is at an early stage. All the software I referenced was compiled by clang/mingw. So you still haven’t provided anything meaningful to prove that it’s impossible to write all this software in V.
Would it surprise you to learn that a repository with just a README file for an editor that's been in use for 1.5 years isn't exactly a compelling way to debunk such questions? I hope you can see that it hurts your credibility when you delete comments and call things misinformation when they are clearly not.
And we are back. What should I do then? The source is not released yet. Volt is closed source.
This is a complete waste of time. The language will be released soon, you’ll see for yourself. For now you can doubt and call me a liar all you want.
Tons of people were saying the same thing before Volt was released. “It’s impossible to have a 200 KB Slack client. You are a scammer.”
I should just ignore such people and keep working.
On 22 Mar 2019, at 13:05, Jeroen van Rijn notifications@github.com wrote:
I'm not calling everything misinformation. I'm calling claims like
Not only that, software purported to have been written in this language or transpiled to it, far exceeds the complexity of even the simple things that failed in the playground.
Like this you mean? An assertion of mine which was later backed up by you yourself when you stated this:
No, this is x64 machine code generation. In 0.5s you'll get a binary. At this stage it's not going to work with such a complex application like Doom 3, so I'll change it to a simpler app.
Look. I don't assume ill-intent on your part. From what I've seen you appear rather a bit overenthusiastic and relatively inexperienced compared to say @gingerBill https://github.com/gingerBill or myself. That's okay, we all had to start somewhere. It also looks to be the case that you have a different view of certain definitions than are orthodox in the compiler construction community and its theory.
It is however disingenuous at best to take a novel definition and assert it's the people who use the traditional meaning of those things as the basis of their observation who have it wrong. And finally, after much hand-wringing on this subject, you listen when @thebirk https://github.com/thebirk says Well then you should probably advertise your language as having a lightweight runtime, instead of saying it has no runtime.
As for questions by myself and others about complex software written in V, you countered this by pointing to your editor (among other projects): Volt (volt-app.com) and Vid editor, my primary editor for the last 1.5 years (github.com/medvednikov/vid) are written 100% in V. That's more than 100,000 lines of code.
Would it surprise you to learn that a repository with just a README file for an editor that's been in use for 1.5 years isn't exactly a compelling way to debunk such questions? I hope you can see that it hurts your credibility when you delete comments and call things misinformation when they are clearly not.
Again, I'm not assuming ill-intent, but I hope you can see that there's a large gap between the way you presented the language and its maturity and the actual verifiable proof you provide. We're not trying to attack you. I know I'm not, at least. I am however - as said previously - interested in low-level languages like V.
I wish it to succeed and live up to your goals for the language, very much so. I also believe it is fair to ask that the description of the language is congruent with its state and vice versa. You have started to address some of these points and I commend you for it.
So to summarise let's take it as read that you're not the bad guy. Neither are we. Maybe you could lay off terms like 'misinformation' and 'debunk'? Especially seeing as you've acknowledged and addressed some points made already. The way you've handled things so far only increases scepticism in the casual observer, I would think.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vlang-io/V/issues/35#issuecomment-475595813, or mute the thread https://github.com/notifications/unsubscribe-auth/AAp_fHDiP2AXySYkALDAqX7nJyVpAfQBks5vZMbygaJpZM4b9dhj.
MaxGraey
commented
5 years ago Actually Volt takes 354 KB (btw compressed in dmg) on Mac, 2.1 MB on Windows and not exists on Linux. Most apps have fat sizes because: 1) They use fat libc or similar runtime libraries, icu4c for unicode by default 2) They use a lot of third-party dependencies 3) They use cross-platform GUI framework
Basically if you will drop std ([no_std] in Rust) and replace it to musl or own simple and lightweight runtime, switch to lightweight memory allocator (like wee_alloc in Rust which using for wasm), will use own binding for OpenGL or use some low-level system api specific for target platform, avoid svg, png, custom fonts, and other assets you could produce similar binary size. So I absolutely do not see the merit of the language itself here. Rather, it is his limitation.
Most users need to write fast, cross-platform and reliable applications and not 4K/400K demoscenes
Kelimion
commented
5 years ago And we are back. What should I do then? The source is not released yet. Volt is closed source.
Maybe not link to it as proof positive of complex software written in the language when people can't evaluate the language on this basis? That's not people necessarily doubting the veracity of your claims.
I don't begrudge you listing this software, but it's rather sad to see you attacking people when they see something they can't verify and point out the claims can't be evaluated, and that perhaps claims made should be limited to that which can be independently verified or the disparity between what was observed in the playground and the things we can't yet verify clarified. That is literally what the entire thread has been about.
This is about x64 compilation, which is at an early stage. All the software I referenced was compiled by clang/mingw. So you still haven’t provided anything meaningful to prove that it’s impossible to write all this software in V.
Seriously... The timing example shows 0.5s for doom3.v, still. At the same time you've acknowledged that At this stage it's not going to work with such a complex application like Doom 3. Do you understand that when you say yourself that complex software such as Doom 3 doesn't work at this stage, that confirms my observation? Further, using doom3.v as a timing example to show why V is fast when you state it doesn't yet work with such complex examples is in direct contradiction.
I agree it's a waste of time when you continue to cherry pick, backtrack, dodge and suggest people are calling you a liar and scammer for having the audacity to point out that some of your claims aren't verifiable and others like the doom3 timing example don't add up. They aren't and they don't.
I'll say again that I don't think you are lying or intend to use this project as a scam. I never called you a liar or scammer. I suggested it was premature to open up donations when would-be donors can't objectively verify things and they clearly can't. How is that controversial or suggestive of a scam? The only one here who's used pejoratives or imputed intent has been you with usage of loaded claims like 'misinformation', 'such people', 'debunk', 'liar' and 'scammer'.
It should however be clear to anyone who's followed the thread so far that for whatever reason the title of this issue, 'This language is not as advertised', is very much applicable.
dotbmp
commented
5 years ago Nobody is calling you anything, we're simply pointing out that your materials around V are inconsistent and not backed up by any evidence, and some of your claims are hard to reconcile with reality. With you accepting donations for this project, surely you see how that raises legitimate concerns. Nobody is lobbing accusations at you, we're suggesting ways that you could provide a more solid foundation for public trust, by clearing up any misinformation, backing up your claims, and/or holding off on making some more lofty claims until there is something publicly available to back them up.
However, I'll be direct and say that without these things, it's an open question whether or not any of this is in good faith. I don't know you and I can't judge based on your character, all I have to go on is the available materials about V. So in pointing out to you how someone could take some of your inconsistent, erroneous or hard-to-believe claims and assume bad intentions, I'm hoping to give you the benefit of the doubt and allow you to clear things up, not antagonize you about the state of an unfinished project. I think everyone in this thread will agree that that is the hope here.
As to how you can automatically serialize data structures to, for instance, JSON at runtime without RTTI, frankly I'm baffled that anybody would fight me on that claim. It's self-evident. Without runtime type information - e.g. a form of reflection - a program absolutely and definitionally cannot understand the layout of a data structure in order to convert it to another format. You might have some clever and unique system, sure, but no matter how you slice it if you have runtime serialization that doesn't have to be coded by hand for each and every type, you are using reflection. It's like saying you've come up with a new way to distill alcohol without using chemistry - yet distillation is a fundamentally chemical process.
The same with the runtime thing. If the compiler is inserting mallocs and frees into your code in order to implement a form of automatic memory management, that is by definition a runtime. And if you're linking to the CRT malloc and free, you're literally using C's runtime.
There's nothing wrong with having a form of reflection nor having a runtime. In fact, to an extent these are desirable qualities in a language. However if you're going to dispute that these claims are self-evidently false given your own testimony as to the language's features, it's going to hurt your credibility.
paralin
commented
5 years ago I'm just sitting here wondering how he got clang to compile anything in 0.5 seconds to x86.
MaxGraey
commented
5 years ago Also author mentioned V is self-hosting compiler. Rust for example started in 2006 on Ocaml and only after 4 years could compile itself. For compiling itself the compiler must be truly mature.
ghost
commented
5 years ago The only other thing I can imagine is that you maybe are compiling to naiive hand-written x86. This is a nightmare for sure.
I guess he's doing that, but who knows?
Francesco149
commented
5 years ago from what i've seen, the V compiler is supposed to be simple and non-optimizing at the moment and to be used for fast (as in fast compile time) debug builds. for optimization you would transpile to C and compile with gcc/clang. site says optimization is planned for the future.
I think it's a very plausible claim for a simple non-optimizing compiler, and i actually like the idea but i can see why the way it's presented could rub people the wrong way
paralin
commented
5 years ago Why not just say that then.
On Sun, Mar 24, 2019, 4:13 PM Franc[e]sco notifications@github.com wrote:
from what i've seen, the V compiler is supposed to be simple and non-optimizing at the moment and to be used for fast debug builds. for optimization you would transpile to C and compile with gcc/clang. site says optimization is planned for the future.
I think it's a very plausible claim for a simple non-optimizing compiler, and i actually like the idea but i can see why the way it's presented could rub people the wrong way
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/vlang-io/V/issues/35#issuecomment-476011313, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgpZ_ik6_VV01uuIGAyF5ba44u3X4_Nks5vaAZ-gaJpZM4b9dhj .
medvednikov
commented
5 years ago One final message to address some things.
from what i've seen, the V compiler is supposed to be simple and non-optimizing at the moment and to be used for fast (as in fast compile time) debug builds. for optimization you would transpile to C and compile with gcc/clang. site says optimization is planned for the future.
Why not just say that then.
This is correct and is literally what it says on the home page.
Actually Volt takes 354 KB (btw compressed in dmg) on Mac, 2.1 MB on Windows and not exists on Linux.
In that 354 KB binary almost half is used by the macOS icon. It's 2.1 MB on Windows temporarily until I remove the libcurl dependency. Linux version is going to be released tomorrow.
Also author mentioned V is self-hosting compiler. Rust for example started in 2006 on Ocaml and only after 4 years could compile itself. For compiling itself the compiler must be truly mature.
V is written in V. You'll see in June once the source is released.
I'm just sitting here wondering how he got clang to compile anything in 0.5 seconds to x86.
Clang compiles 200k lines of sqlite.c in 1 second.
As to how you can automatically serialize data structures to, for instance, JSON at runtime without RTTI, frankly I'm baffled that anybody would fight me on that claim. It's self-evident. Without runtime type information - e.g. a form of reflection - a program absolutely and definitionally cannot understand the layout of a data structure in order to convert it to another format.
V doesn't need runtime information to decode JSON, because it achieves it via codegen. All information about types is known at compilation time.
For example, if we have struct User { name string; age int; }
V generates the following for decode_json(User, js_string) (I'm copy pasting resulting C code):
Option jsdecode_User(cJSON* root, User* res) {
// Error handling skipped
res->name = jsdecode_string(js_get(root, "name"));
res->age = jsdecode_int(js_get(root, "age"));
return b_ok(res);
}
This language is not as advertised
This language does not do over 90% of what is advertised. Most of what is advertised is not coherent with most of the claims you have stated. With the new release of the playground, most of the examples in the docs fail, even many of the extremely basic ones.
You have previously claimed that the V compiler uses no AST. However, most of the features that you claim would require a form of AST to even work, including generics and interfaces. An AST is an abstract syntax tree, which means that it just stores data about the syntax that is in a tree-like format. It's pretty much impossible to not have unless you have a very basic language or doing naïve transformations into another similar language.
You claim that the language has no runtime but the following require a runtime:
printlngoruntime.wait()Why was the playground lacking a lot of basic functionality? If most of these extremely basic features are broken, how could you have made any software in this language other than basic things? -- e.g. Fibonacci examples.
Software claimed to be built in V:
Claimed C/C++ Translations into V:
Claims from your "compare" page:
How would you handle pointers?! In your documentation, you demonstrate that pointers exist. This means that
no nullis false. Pointers also crashed the playground.And when you mean stricter, what does that mean? It was also failing quite often even on basic code in the playground.
So how do they work? Is it just static dispatch?
What you have promised does not even come close to what is delivered.