Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

This language is not as advertised #35

Closed
gingerBill opened this issue Mar 20, 2019 · 62 comments
Closed

This language is not as advertised #35

gingerBill opened this issue Mar 20, 2019 · 62 comments

Comments

@gingerBill
Copy link

gingerBill commented Mar 20, 2019

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 appear to do very basic tokenization/lexing which you use to naïvely convert the code into C or C++ (through testing of the playground)
  • The converter program does virtually no semantic checking other than the most basic type checking
  • Name lookups do not respect nested scopes within functions and caused the playground to crash
  • There is poor checking for certain characters and tokens you disallow
  • Record types and their methods must be declared before use, the type before the methods
  • The playground was crashing frequently
  • The playground is extremely insecure

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:

  • All arrays are dynamic
  • println
  • Threads with go
  • Synchronization of threads with runtime.wait()
  • Automatic memory management

Things that are currently broken:
- Automatic imports 
- Interface method calls
- Interfaces have to be declared with `type Foo interface {` 
- Foo{a,b} syntax (use Foo{a:a, b:b}) 
- Closures
- a[i].field
- Locks (lock {}). Use sync.Mutex for now. 
- Enums 

Disabled features:
- Generics 

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:

  • Volt
  • Filey
  • Vid
  • gitly
  • Hot code reloading

Claimed C/C++ Translations into V:

  • DOOM
  • DOOM 3
  • LevelDB
  • SQLite

Claims from your "compare" page:

- No null

How would you handle pointers?! In your documentation, you demonstrate that pointers exist. This means that no null is false. Pointers also crashed the playground.

- Much stricter vfmt

And when you mean stricter, what does that mean? It was also failing quite often even on basic code in the playground.

- Cheaper interfaces without dynamic dispatch

So how do they work? Is it just static dispatch?


What you have promised does not even come close to what is delivered.

@SuperDisk
Copy link

How entitled do you have to be to scream at someone that his language isn't ready enough for you yet? Why is this a github issue?

@SuperDisk
Copy link

Yeah I get it, it just disheartens me to see such harsh rebuke, especially because he's repeatedly said it's a pre-alpha language and a lot of goals haven't been implemented yet. Seems to me like the playground was put out early because everyone was clamoring for it and his reward? A github issue decrying him as a scam artist. Like jeez folks, it's not like he stole your money or that much of your time.

@medvednikov
Copy link
Member

medvednikov commented Mar 20, 2019

Hi,

Like the disclaimer says, the language is in the pre-alpha stage. I've been developing it in parallel with Volt, what works for me, a single developer, is certainly not going to work for thousands. There are major things missing/broken that I've just been avoiding (for example, you can't do foo[i].bar).

All arrays are dynamic
println
Threads with go
Synchronization of threads with runtime.wait()
Automatic memory management

All of these things are implemented and they do not require runtime with the way I implemented them. Threads right now are simple OS threads, runtime.wait() just joins them. Automatic memory management means the language inserts free() calls at compile time. Why do dynamic arrays require runtime? Same with println. The language looks at the type of the println argument and generates a call to str() during compilation.

The playground was crashing frequently

Of course it was, this is a pre-alpha release, being tested thousands of times in a span of one hour.

The playground is extremely insecure

Please file a report. I already found and fixed an issue with imports.

how could you have made any software in this language other than basic things?

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.

The compiler itself is written in V. The C/C++ translator is written in V. I think these are pretty complex applications.

How would you handle pointers?! In your documentation, you demonstrate that pointers exist. This means that no null is false.

No it doesn't. You can't have a null pointer in V, since they are required to be initialized by the compiler: a := &b. If you have a struct field with a pointer, and it's not initialized during creation, the compiler will automatically allocate memory for it.

V can work with C code, of course C has null pointers, so you can get null bugs there, just like in any language calling C code.

It [vmt] was also failing quite often even on basic code in the playground.

Report, and I will fix it.

Several other issues you mention (like "name lookups do not respect nested scopes") need literally a couple of lines of code. Do you really think I'm not going to fix those for a non pre-alpha build? :)

Software built in V isn't Software I would like to build in V.

See above. It actually is built in V.

I see you are the creator of Odin. Very strange to see a post from you with so many wrong accusations.

@zhaytee
Copy link

zhaytee commented Mar 20, 2019

@medvednikov Well handled!

Also, thanks for your efforts on V. Very much looking forward to seeing it grow.

@vlang vlang deleted a comment from Kelimion Mar 20, 2019
@vlang vlang deleted a comment from Kelimion Mar 20, 2019
@aedans
Copy link

aedans commented Mar 20, 2019

I don't think the problem is that the language isn't finished. As you stated, it's in pre-alpha, and it's unreasonable to expect the language to be completely bug free. I think it's even conceivable to write software like Volt in V if you use mostly simpler features; people often underestimate how much you can do with just functions and if statements.

The problem is that you claim that the language can do incredible things that only a very mature compiler should be able to do. Compiling the entirety of doom 3 in 0.5 seconds is the most offensive of these, but several others like hot code reloading and C++ translation are just as hard to believe. A compiler which can do these things should not also fail on basic examples.

Making this all even harder to believe is that everything is closed source. If you provided the source for doom3.v and other complex programs this would be a lot easier to believe, but right now it looks like you're making impossible promises and hiding it all behind, "coming in X months."

Overall, I don't believe you are straight up lying for traffic, but the disconnect between the way you are presenting V and what we can actually see makes me and many others extremely suspicious of what you are doing, especially when you have an active Patreon that you are directing people towards.

If you want people to believe you, unify your presentation with our view, either by presenting the language as it is (not how it could be), or by showing us a working implementation for these complex programs. We are not your enemy -- we want V to be everything you present it as and more -- but it is difficult trust you with the current state of the language.

Edit: deleting criticism is extremely suspicious as well.

Best regards.

@medvednikov
Copy link
Member

medvednikov commented Mar 20, 2019

like hot code reloading ... are just as hard to believe.

the home page literally has a link to a demo: https://volt-app.com/img/lang.webm

Compiling the entirety of doom 3 in 0.5 seconds is the most offensive of these

an article on translating Doom will be up in a couple of days

If you provided the source for doom3.v

I will, in the article mentioned above

deleting criticism is extremely suspicious as well.

I deleted 2 posts that were repeating the same points and contained misinformation. Now that I posted a response and addressed most of the claims, no more posts will be deleted.

@Kelimion
Copy link

Excuse you? In no way did my comments contain misinformation. And if the main thing that was wrong with them according to you was that they repeated things, you could've left them up.

Apart from which, speech tends to be countered by speech, not censorship.

@medvednikov
Copy link
Member

medvednikov commented Mar 20, 2019 via email

@Kelimion
Copy link

Asking for proof of questionable claims by you is not misinformation.

You keep claiming - yet again right now - that there are examples of complex applications written in V. Just stating that you've written a piece of software in this language doesn't constitute proof. Even so everyone here is supposed to believe that in the current state of the compiler, you cannot address a member of a struct in an array, but Doom3 can be transpiled to it and works?

Your hot reloading video has a conspicuous pause between saving the file and the color changing. It changes always when it hits a border, not in response to saving the file.

Is it also misinformation that you claim all these features and compare them against other languages as if they were already implemented? No, because that is what you do. You didn't call it a roadmap, did you?

And to address your remark to Bill, I see you are the creator of Odin. Very strange to see a post from you with so many wrong accusations.

Yes, it's almost as if they're not wrong?

@medvednikov
Copy link
Member

You keep claiming - yet again right now - that there are examples of complex applications written in V. Just stating that you've written a piece of software in this language doesn't constitute proof.

OK, again let's say I lie and I didn't write it in V. What's the plan, can you tell me?

Is it also misinformation that you claim all these features and compare them against other languages as if they were already implemented?

What features I compare against are not implemented? Point{x,y} syntax?

Yes, it's almost as if they're not wrong?

Yes, almost every single sentence is wrong, misinformation, or an outright lie (like 90% of features missing, AST being required, println requiring runtime (??), dynamic arrays requiring runtime (??), etc)

It also says

If most of these extremely basic features are broken, how could you have made any software in this language other than basic things?

Indeed, how could I implement everything without automatic imports and enums?

@medvednikov
Copy link
Member

Your hot reloading video has a conspicuous pause between saving the file and the color changing. It changes always when it hits a border, not in response to saving the file.

I recorded it a year ago. I don't remember the issue, but indeed I couldn't make the file watcher work correctly, and somehow forced the reload when it reached the edge.

I haven't been using hot reloading when developing Volt, because it's harder to make it work with GUI apps, but it's possible and I will fix it.

This is pre-alpha software, things aren't 100% stable, this is normal.

@medvednikov
Copy link
Member

Asking for proof of questionable claims by you is not misinformation.

You aren't asking for proof. You are making strong claims that are simply not true.

I can't give you proof right now: Volt is closed source, V and Vid will be released in June.

So you either believe me or you don't, we'll see who is right in June. But please don't call me a liar, scammer and spread misinformation.

@medvednikov
Copy link
Member

you cannot address a member of a struct in an array, but Doom3 can be transpiled to it and works?

V temporarily allows to insert C code with #. I hate this feature and have been slowly cleaning up all C code. The released version of V will not have # at all.

For missing/broken features I simply use # for now.

@Kelimion
Copy link

Kelimion commented Mar 20, 2019

Asking for proof of questionable claims by you is not misinformation.

You aren't asking for proof. You are making strong claims that are simply not true.

I can't give you proof right now: Volt is closed source, V and Vid will be released in June.

So you either believe me or you don't, we'll see who is right in June. But please don't call me a liar, scammer and spread misinformation.

And you'll note that I didn't call you a liar or scammer. I questioned why you make such strong claims about the current state of the language all over the website instead of addressing which of the features are aspirational. I question why you think it makes sense to benchmark an incomplete compiler against compilers that have actually been released and make it appear that V is better than them in both size-on-disk, compilation speed and features. Either those features you say outstrip other languages exist, or they don't. But if they're going to be available in the future, please don't make it out to be as if V already beats Go, Swift, et al.

I admit you list a number of features that are currently broken and that the package manager and V's own optimiser are future work, but that doesn't make all the other claims of V's competence you make any less strong. I asked that you update the website to reflect what is currently implemented and which parts of it are future work. This is not exactly a controversial thing to ask, I think.

Yet another example of how you make it appear V is ready for use is the website's footer reading Are you using V to build your product or library? Have it added to this list.

I'm not saying you didn't write this language, but you have to admit that at every turn you keep putting the cart before the horse.

@medvednikov
Copy link
Member

medvednikov commented Mar 20, 2019

And you'll note that I didn't call you a liar or scammer.

You keep saying that I didn't write all this software in V, than means I'm a liar.

I question why you think it makes sense to benchmark an incomplete compiler against compilers that have actually been released and make it appear that V is better than them in both size-on-disk, compilation speed and features

I benchmarked only compilation speed by calling println(a) 200 000 times. I explicitly mentioned that this is not a great test, but it can give a general picture. V can compile a program that calls println.

Regarding the size comparison. This is a good point. In the original HTML version of the site I had a side note reference saying that this isn't a very fair comparison, because the set of V's features is much smaller, but the size is still unlikely to be more than 1 MB. I'll bring that note back.

I asked that you update the website to reflect what is currently implemented and which parts of it are current work.

The site contains correct information. Please point me to the things that are not implemented.

Are you using V to build your product or library? Have it added to this list.

I added this for the future, just like the initial "install V by running gcc -o v v.c". Good point, I'll remove it as well.

@medvednikov
Copy link
Member

The only major feature missing is the scheduler/green threads. But they are not mentioned anywhere on the website.

@eterps
Copy link

eterps commented Mar 20, 2019

The site contains correct information. Please point me to the things that are not implemented.

cd doom3/
wc -l doom3.v     # 458 713
time v doom3.v    # 0.5s

Is this information correct? What is being timed at 0.5s in this example, the translation to C? If so, it might be good to add that information otherwise people assume it is about generating object code as the speed benchmark currently suggests.

@medvednikov
Copy link
Member

medvednikov commented Mar 20, 2019

Is this information correct? What is being timed at 0.5s in this example, the translation to C?

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.

@gingerBill
Copy link
Author

May I ask, what do you consider a runtime to be, @medvednikov?

@MaxGraey
Copy link

MaxGraey commented Mar 20, 2019

No, this is x64 machine code generation. In 0.5s you'll get a binary.

But just compiling is not meaning "compiling correct" and "run correct". Could we see (download) this binary?

@Kelimion
Copy link

Kelimion commented Mar 20, 2019

At no point did I say that you didn't write all this software. I reference your claims that you have written all of this software in V while simultaneously some very basic language features are said to be missing or broken. Asking you to address this is isn't exactly the same as calling you a liar, methinks.

I do hope V will turn out to be all you say it will be. We could use more good programming languages, and indeed I'm looking forward to Jon Blow's JAI.

I'll check back in June to see where V is at. I'd love nothing more than to see a language that lives up to this hype. I don't feel like the main concerns have been meaningfully addressed, but I have actual work to do, and I'll leave you to get back to improving the compiler as well. :)

@medvednikov
Copy link
Member

At no point did I say that you didn't write all this software.

Please read what I wrote. I don't claim you claimed I didn't write all this software. You claimed I didn't write this software in V.

This is false. All of this software is written 100% in V.

@medvednikov
Copy link
Member

But just compiling is not "compiling correct" and "run correct". Could we see (download) this binary?

In a couple of days I will release an article on translating Doom 1 to V. It will have the resulting .v code and the binary.

@medvednikov
Copy link
Member

I will add more info to the doom3 example, explain what's going, and at what stage the C++ translator and x64 generation are.

@medvednikov
Copy link
Member

very basic language features are said to be missing or broken

What basic features are broken other than accessing fields of array elements? Please be specific. I debunked all false claims and I'm still getting these vague basic broken features from you.

@Kelimion
Copy link

At no point did I say that you didn't write all this software.

Please read what I wrote. I don't claim you claimed I didn't write all this software. You claimed I didn't write this software in V.

This is false. All of this software is written 100% in V.

I made no such claim at all, and I have screenshots of the posts you deleted to back this up.
I said:

"Let's be clear, the way thing(sic) have been phrased so far evoke a compiler much farther along in development than the demo confirms. It is one thing to make aspirational claims. It's another to state complex software has already been written in this language, make comparisons against compilers that have actually been released and claim superiority over them in every sense."

Nowhere does that say you didn't do so. It strongly questions whether the way the language is presented on the website matches the its current state. You're familiar with "extraordinary claims require extraordinary evidence?"

What basic features are broken other than accessing fields of array elements? Please be specific. I debunked all false claims and I'm still getting these vague basic broken features from you.

Honestly? You listed a raft of broken features on the playground and call a reference to broken features vague? You wrote that list yourself.

@medvednikov
Copy link
Member

All of these were written by you:

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.
It's another to state complex software has already been written in this language
Software built in V isn't Software I would like to build in V

@mayadapples
Copy link

I'm interested to see what the language is like, if it doesn't live up the features promised I think that's still perfectly okay; one can have a functioning language that people hopefully can use and then gauge interest, which probably will help adding some of the features that were promised.

@dotbmp
Copy link

dotbmp commented Mar 21, 2019

I agree that it's fine if it doesn't live up to the hype @mayadapples, the problem though is that the claims have been worded as though the language is already living up to these things, and the creator is accepting donations. As @Kelimion pointed out, if these are aspirational goals that's fine, but in that case it should be clear. If they're objective claims (as they are written) and they're not true, then it's fraudulent to accept money on that basis.

I'm not claiming that they aren't true, but I am highly skeptical because some of the claims are hard to believe, and seem to have been watered down as compared to the original ones made at the time of V's announcement. Some of the claims are contradictory, which is why if the author is well-intentioned I hope that he will look into topics such as what defines a runtime, what defines reflection, and correct those claims. For example, there is no way to serialize data structures at runtime without some kind of runtime type information, the use of which is definitionally a form of reflection. So the claim that the language features reflectionless serialization, with an example that shows the use of runtime utilities, is objectively false. This is just the most obvious example that jumps out at me from looking at the website, there are others that have been brought up as well. It's my hope that this is a misunderstanding or misuse of terminology and not an intentionally misleading attempt to draw undeserved attention to the language in order to raise money on Patreon, but it's definitely important for these issues to be addressed because whether intentionally or by accident they are misleading.

@medvednikov
Copy link
Member

@bpunsky

For example, there is no way to serialize data structures at runtime without some kind of runtime type information, the use of which is definitionally a form of reflection. So the claim that the language features reflectionless serialization, with an example that shows the use of runtime utilities, is objectively false.

Please link to an example where serialization uses runtime information.

This is just the most obvious example that jumps out at me from looking at the website, there are others that have been brought up as well.

Please name at least one.

@mayadapples
Copy link

@medvednikov Not trying to be aggressive here, but what is the design aim or purpose of not having a runtime library?
Also I'm sorry if this question was already asked.

@medvednikov
Copy link
Member

@bpunsky @Kelimion

You write walls of text with misinformation, but when I ask you to give one actual example, you disappear.

@paralin
Copy link

paralin commented Mar 22, 2019

They assert that they can compile Doom to x86 in 0.5 seconds. This claim alone should invalidate the rest.

@medvednikov
Copy link
Member

If you say so.

@paralin
Copy link

paralin commented Mar 22, 2019

@medvednikov This may be an issue of semantics. If you're compiling from V to C code, this is transpilation, similar to Coffeescript or TypeScript. You mention runtime.join a bunch of places so it must be that you are doing something like this.

The only other thing I can imagine is that you maybe are compiling to naiive hand-written x86. This is a nightmare for sure.

@Kelimion
Copy link

Kelimion commented Mar 22, 2019

I didn't disappear. I said that you hadn't actually addressed the meat of my concerns and that I had real work to do, so I'd check back when the compiler is actually released.

But again with calling legitimate technical concerns misinformation. Or is it the disparities in the description of the language other than that? I called out examples and you said you'd correct them. Clearly you must've felt those weren't misinformation.

One of the things I kept saying was that what you presented didn't match the demo. You've now closed the playground and show this message: Due to inconsitencies between the documentation and this pre-alpha build, the playground has been disabled until a more stable release and an updated documentation.

So I was right then that the state of the compiler didn't match the information given.

In your answer to @eterps you say 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.

Giving a timing example for Doom 3 (at the time) and admitting it doesn't even work "at this stage", but people calling out disparities we see are peddling misinformation, even when you then later address some of them on the website. Right, so it's not misinformation to make up a timing example from whole cloth, but when people complain that a lot of information on the website just doesn't make sense that is misinformation. I see.

You've also still not addressed @gingerBill's point about the runtime, I see.

I can only speak for myself, but I do see others who also have no beef with you and want to see the language live up to its stated goals. Calling everything misinformation but at the same time updating the website to address some of those very concerns is honestly disappointing.

And I do have actual work to do, so forgive me if I don't go through the website with a fine-toothed comb and point out every single thing that appears to me to be wrong or misleading. It occurred to me that as someone who had written both the language and the website, you'd know in full detail which parts of it were wrong - like the Doom3 timings and the inconsistency between the playground and documentation - and which were correct.

@medvednikov
Copy link
Member

@Kelimion I asked you a simple thing 4 times, 30 messages later you still haven't answered.

You claimed that it's not possible to write complex software in V because it's missing basic features. For the 5th time: please give me an example of one missing basic feature that makes you confident it's not possible to use V to write complex software.

Are you seriously using this runtime argument? This definition of runtime is absolutely useless, because this way every single compiled language has one. So complaining that V uses runtimes is like complaining it uses RAM or electricity.

I think it's pretty obvious that I compare it to languages with a heavy runtime like JavaScript, C#, Java, Python, arguably Go.

@medvednikov
Copy link
Member

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.
It's another to state complex software has already been written in this language
Software built in V isn't Software I would like to build in V

or

For example, there is no way to serialize data structures at runtime without some kind of runtime type information, the use of which is definitionally a form of reflection. So the claim that the language features reflectionless serialization, with an example that shows the use of runtime utilities, is objectively false.

or

This language does not do over 90% of what is advertised.

misinformation, which it clearly is.

@thebirk
Copy link

thebirk commented Mar 22, 2019

@medvednikov

Are you seriously using this runtime argument? This definition of runtime is absolutely useless, because this way every single compiled language has one. So complaining that V uses runtimes is like complaining it uses RAM or electricity.
I think it's pretty obvious that I compare it to languages with a heavy runtime like JavaScript, C#, Java, Python, arguably Go.

Well then you should probably advertise your language as having a lightweight runtime, instead of saying it has no runtime.

@medvednikov
Copy link
Member

medvednikov commented Mar 22, 2019

@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
Copy link

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
Copy link
Member

medvednikov commented Mar 22, 2019 via email

@MaxGraey
Copy link

MaxGraey commented Mar 22, 2019

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
Copy link

Kelimion commented Mar 22, 2019

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
Copy link

dotbmp commented Mar 22, 2019

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
Copy link

paralin commented Mar 22, 2019

I'm just sitting here wondering how he got clang to compile anything in 0.5 seconds to x86.

@MaxGraey
Copy link

MaxGraey commented Mar 24, 2019

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
Copy link

ghost commented Mar 24, 2019

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
Copy link

Francesco149 commented Mar 24, 2019

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
Copy link

paralin commented Mar 25, 2019 via email

@vlang vlang locked and limited conversation to collaborators Mar 25, 2019
@medvednikov
Copy link
Member

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); 
}

@medvednikov medvednikov reopened this Jun 2, 2022
@medvednikov medvednikov reopened this Sep 19, 2024
@medvednikov medvednikov converted this issue into discussion #22260 Sep 19, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests