The V Programming Language
vlang.io
vlang.io
I want to imagine that you just got way over your head, underestimating the effort needed to accomplish all of your goals, but at some point it takes a bit of naiveté to think that well-funded teams in other languages haven't tried to fulfill some of your goals before. I'm very much intrigued by the "Space required/Build time" table, particularly how you think the comparison makes sense or is fair in any way, as you're comparing compilers for established languages with extensive standard libraries, implemented and battle tested features and a decades of man/year effort to your solo project.
Looking at the project it is really hard to come away with an opinion that isn't one of "this is a joke", "this is fraudulent" or "this is a well intentioned inexperienced developer that has no idea how high the target they've set for themselves is". I hope that if it is the latter.
This is a little off-topic but I feel it needs to be discussed. The term "transpiler" that you've used here is a little belittling, not only to V but to other languages which are translated to C. I don't think its fair nor accurate to characterize compilers which translate code to C as "transpilers". It's valid when languages of the same level of abstraction are translated to each other, but not when one language (C) is low-level and the other is high-level.
All this being said though, V does seem to lean very heavily on inlined C inside its standard library and compiler. So that assessment is totally fair.
If you don't mind me asking, how heavily did Nim rely on inlined C inside it's standard library and compiler when it was only 3 months old? Or did you guys do something different that early in it's development?
Nim has always had a "everything should be implemented in pure Nim" philosophy. So much so that the stdlib is even separated into "pure" modules[1] (implemented in Nim completely) and "impure" modules (those that depend on external C/C++ libs). Nowadays major things are implemented in Nim, for example we don't use libuv/libevent but instead have written our own epoll/kqueue/IOCP implementation.
This is completely false. Why are competing language developers so willing to spread misinformation? :)
There are 0 lines of C in the compiler.
The vlib has about 500. So that's 500 out of ~14k.
Most of it was added last spring when V just didn't have the necessary features. All of C code will be removed this month.
Here it is: https://github.com/vlang/v/blob/978ec58fe300929555786fdf58ca...
Please explain the use of `#include <pthread.h>` then, because as far as I can tell, this is a C header...unless I'm missing something here mate.
It would be one thing if he apologized, but instead playing the victim makes the whole situation worse. I wonder how long until the patreons drop below 800.
https://news.ycombinator.com/item?id=19610971
https://github.com/vlang/v/issues/319 (issues are being deleted https://mobile.twitter.com/boy_edgey/status/1142507034446876... )
https://www.reddit.com/r/programmingcirclejerk/comments/c3t3...
Searching on twitter you'll find some light roasting.
>>Looking at the project it is really hard to come away with an opinion that isn't one of "this is a joke", "this is fraudulent" or "this is a well intentioned inexperienced developer that has no idea how high the target they've set for themselves is". I hope that if it is the latter.
You would be very interested in seeing the source code of Perl 1.
Edit: The author has redacted the binary release and says will release the binaries with the source on July 22nd [1], thus, this post is invalid at this point as nothing is released.
[1] https://twitter.com/v_language/status/1141625734953390081
Go is an amazing language and my go-to language for most backend tasks these days, but often when jumping back from Python, it feels needlessly cumbersome.
Now don't get me wrong, I'm not talking about any "magic", Go is exactly as great as it is, because it's so simple and barebones. I'm talking about some basic comfort that costs mental energy but zero complexity or execution speed. The things the Rust community calls "zero cost abstractions". But the core language developers seem to be pretty opinioated and _of course_ a set can be logically thought as just a map of empty structs, so you don't need two concepts in a language. But it's something I have to teach to every developer starting out.
And although Rust gets a lot of things right, it's too complex for my choice. The performance/simplicity ratio of Go is just right, so that's what makes me hopeful about V.
Vlang introduces so many concepts I just would have loved in Go. Native Enums. Immutability by default. In operators. The list goes on and on and on.
At this point, it's absolutely overpromised and pretty much unusable without a stdlib, an ecosystem and GC. But my best case scenario would be the CoffeeScript case. A language that so beautifully covers another major language's warts, that it drives the major improvements back to the origin.
Go 2 devs, please listen. 90% of the ideas in V are pure gold.
I'm all for toy projects and beginners writing their first langauge. I object to inflating a project well beyond what the author knows they can deliver while collecting money from people who are hopeful that the project isn't a joke. This is an example of how to take a passion project in the wrong direction. Open source from the beginning, be open with your intentions, don't over promise, don't accept money until you have something of value people can use, don't flame people who are critiquing you when listening to advice could make your project better.
That is not malice, it is just inexperience and this guy really looks inexperienced because he knew this would not hold up when he was pressured to release the source. Keeping optimistic and thinking that he is further than he is even though it is quite provable that he is not, is also a symptom of this programmers disease.
It is related, I think, to the 80/20 rule which fresher programmers do not even want to admit to; this is even more extreem as the 80% has not been reached yet, but the author thinks he is actually past the 80%.
I could be wrong and it could be malice, but reading his responses and everything I read the past days about this, I would say it's the same as what I had when I was a teenager going with my father to where he worked and claiming that there must be something wrong because why did it take so long to program these computers while I could 'write code really fast'. 30 years later I still can 'write code really fast' but I know that has not much to do with finishing a project (in time or at all).
It is insane what he set out to do really; write a language to write a moving project in, including docs and examples etc. For me, if he would've been more realistic about the deliveries/timelines (just take a few years man!), I would've actually sponsored him and if he turns out to not be a fraud I still might. We have not so many people who dream big; we do need results though...
Edit: I described the Dunning-Kruger effect; forgot the name. I grew over it by getting more experience (I got into some pretty hairy and complex projects when I hit 18 and that taught me that reality really is very complex).
Just like you can no longer charge for compiler, I don't think it's possible in the future to not publish the source. The truth is, there are plenty of actual open source alternatives to C (zig, et al.), what makes some shadowy language a reasonable alternative?
For the kind of features that you wanted in your language, not just generics, requires a form of AST (abstract syntax tree), and if you language does not have an AST, which is technically possible, then you cannot have a lot of the features you have been advertising.
You should have framed your question as follows: those features can be implemented without an AST, but an AST is a standard and reasonable way to do them and not using an AST would require a strong rationale. So what's that rationale? (And amedvednikov, this is my question for you.)
V simply generates functions for every type they're used with.
So you have a "template" function as written in the source code and a list of actual functions generated. You can either generate them as a final step or on the fly as you encounter; in either ways you probably have a mapping from the function name to the function body or something similar. How is that stored?
In my iterations of learning to do this (in the open source machine learning space), there have been always five phases:
i) Ingest - use existing tools for years, try to build things and understand the subtleties of their limitations.
ii) Build something - if you were right about the limitations and identify ways to overcome them, people will recognize that and want to use what you build.
iii) Maintain and learn how your assumptions live up to user realities.
iv) Realize very likely that your first attempt at greatness wasn't all that yet, even if it becomes popular. Popularity is not a sign of what you building being well designed, just that the need for it may be great.
v) Build something based on the combination of your initial hunches and taste which got you into it to begin with, and your experience on building something large.
Iterate, and given enough talent and sweat, you might create something that is just right.
Being a computer scientist but not a programming language geek and looking at this, the project looks like a first attempt at ii), but is selling itself as a late iteration of v). Tech communities have very high standards and taste on design, so overselling is deadly.
$ find . -name '*.v'|xargs wc -l|sort -n
...
314 ./glm/glm.v
330 ./time/time.v
338 ./builtin/utf8.v
339 ./examples/tetris/tetris.v
490 ./os/os.v
630 ./compiler/scanner.v
644 ./compiler/table.v
712 ./gg/gg.v
814 ./builtin/string.v
845 ./compiler/main.v
848 ./compiler/fn.v
3216 ./compiler/parser.v
12573 total
If you discount the lexer and parser, it's like 8-9K lines of code, and it's hard to imagine much being done there. You can make a "toy" in that much code, but the gap to a production compiler is very wide (e.g. a minimum of 50K or 100K lines of code).
There is also this translation which is not in the repo:
$ wc -l v.c
15099 v.c
Also, this bootstrapping part looks pretty slick, except I get a core dump (on Ubuntu 16.04 with default GCC):
$ time cc -w -o vc v.c
real 0m0.553s
user 0m0.517s
sys 0m0.035s
~/git/languages/v/compiler$ time ./vc -o v .
Segmentation fault (core dumped)
real 0m0.095s
user 0m0.002s
sys 0m0.000sMy assessment (not a language designer) is that this is something that shows some promise as a transpiled language for people who want a Go-like language without some of the common pain points and are OK with having no GC.
I would add that people who do design languages seem to think it's going to be considerably harder to deliver on the WIP elements than the designer of V thinks. In particular, I note that "direct machine code generation" is a planned item (which would be required for the faster compile time that V promises), but doesn't (as of this source code release) seem to be started - could be wrong about that. Obviously you can promise whatever you want, but writing an entire machine code compiler that will run faster than GCC and equal it in performance is a difficult task.
The goals of the project remind me a lot of Nim, and I'd have preferred to see a comparison with it rather than Rust. While I don't have a use for it myself, the designer does seem sincere about their efforts. (My "ideal" language would be something closer to a lightweight version of Rust that was simpler to use, even if it slightly ate in to what you could do with it.)
Indeed, many of these have been added just today. But even with the WIP tags many of these claims still seem false, for example, the author asserts that "V compiles ≈1.2 million lines of code per second per CPU core." but below that notes that "direct machine code generation" is still a work in progress. For this particular case it sounds a lot like the author wrote a very bare bones code generator that was over-optimized for that benchmark to produce these numbers.
And indeed, as you mention, writing a machine code compiler is no easy task.
> The goals of the project remind me a lot of Nim, and I'd have preferred to see a comparison with it rather than Rust.
It reminds me a lot of Nim as well. As a core dev of Nim I find the hype surrounding it very interesting (and perhaps a little disheartening).
For what it's worth, there used to be a comparison, and in fact we discussed it in our forum[1]. Sadly it didn't seem particularly fair and it seems that V's author has decided to remove it after our debunking.
2 days ago, but yes, very recently. Something I should have done from the start.
> Sadly it didn't seem particularly fair and it seems that V's author has decided to remove it after our debunking.
Araq's rude response didn't debunk anything. All points still stand.
I removed the comparison because it's useless, and only encourages flame wars.
Except that AFAIK he didn't claim that the native generated code will be as optimised as what gcc or clang produce..
I expect that this native code generator is useful for the debug build where code compilation speed matters more than optimised code generated.
Sure in some cases you need the performance even for debug build then you'll need to spend more time compiling..
Work on x64 generation started back in August. I'll publish it very soon. I haven't touched it in a while, and it simply doesn't compile at the moment.
As parent, I did look at the code to see, but I don't see anything. I'm under the impression that it's a thin transpiler, hence the 100x compile time increase.
Correct me if I'm wrong.
ps: also, about the personal/social implication of these threads. I wish no harm to v author, I find it admirable that he managed to produce the whole thing on his own. But it was seriously misleading.
Languages are a marathon, not a sprint.
EDIT: Not needed anymore
Unfortunately, that doesn't seem to be enough to actually generate output (or I just can't find the output file).
EDIT: The generated C code gets put in /var/tmp/vlang0.0.12/v.c and compiling it gives me a new compiler which outputs slightly different C, so it seems to work. The description in the README doesn't mention that manual compilation step, so something seems to have gone wrong.
EDIT2: It works if you have clang installed, which I didn't. The compilation step should probably default to cc instead.
wget https://vlang.io/v.c
Other than that, the design of the language looks nice and I will give it a spin at some point. Maybe I'll convert some HPC benchmarks to V and see how they perform.
I think J. Blow commented in one of his videos that he might be able to put some optimization on the x64 compiler (such as dataflow optimization) when the language is mostly complete. Although builds will be slower because of this, I still trust Blow that he will make a faster compiler than GCC/Clang, because the compiler will be specialized to its language rather than being all-purpose. (Also, C++ takes ridiculously lot to just parse everything, while Jai is must simpler to parse). Maybe V's developer will also work on some optimizations after the basic compiler's finished.
On the other hand, the reason they tend to be slow in large c/c++ programs is the module model basically meaning “behold as every file in your project parses and interprets large portions of the host platform’s standard library”. All modern languages know to avoid that - honestly if you want masochism I’d be curious to compare the time-to-execute for modern js engines, simply because they have incredibly large amounts of pressure to get to running code as fast as possible.
On my examination it looks like a very interesting transpiler. I suspect that like most languages it will bloat as it attempts to achieve it's goals, especially with the size of the standard library that is going to be included by implication.
However if it's goal was to be a useful C transpiler for the modern age I would be more excited, and more interested. Things like hot reloading, easy to use REST access, nice syntax, and the ability to fall back to C are all nice features. For a certain class of application (notably the author's Volt application, and video games) this would be very useful.
I would warn the author of throwing away what they have for going down the rabbit hole of language implementation. It is nowhere as simple as they seem to imagine. An anecdotal story, when using LLVM one will regularly come across required parameters that seem like they should be optional and don't seem important. And yet once one starts thinking about compatibility, errors, ABIs, they realize there are hundreds of edgecases that must be accounted for. For example structure returns on the windows ABI change the ordering of function call arguments depending on the size of the structure, and additionally require redundant memory operations (and failing to do both will cause your compiler to work for some libraries but not others).
I’d also love magic, but you can’t just wish it into existence. That’s a hard problem that V doesn’t solve yet. One should be open minded, but what’s the evidence V can solve this? TLDR: not very compelling; just examples of existing techniques, and wild promises.
What docs show(fn1), and doesn’t even work according to reports, is an easy example of an existing technique — escape analysis, something that JVMs implement. It’s also hard enough to do properly, and it’s taken pretty long for HotSpot to handle some trickier cases. I also wonder how you’d implement the hard cases without an AST. And there’s no citation to the scientific literature, so you could fear the author just figured the basic idea, and thought the rest was easy. But escape analysis can’t handle everything, so usually you need a GC. Nobody knows how to avoid that, a solution would be novel research. So, what does V bring to the table?
> For more complex cases manual memory management is required. This will be fixed soon.
Ah, so you’ll just “fix soon” an open research problem? Wow. Not very compelling. Also:
> V will detect memory leaks at runtime and report them.
But... if you could avoid manual management, wouldn’t leak be impossible? So why would you do both? Unless you want to report the leaks that automated memory management doesn’t fix — memory that is reachable but never going to be used. But never seen anything good at detecting those leaks.
Also, wouldn’t you you need (an optional) GC or refcounting to do even that basic reporting? Sure you can, but doesn’t that add to the implementation complexity?
Developer here. The release was messed up by me having serious git troubles. I had to destroy the repository twice, as the result and old README file with the wrong instructions resulted in everyone having segfaults.
Everything will work as expected in a couple of days. Launching such a big project for hundreds (thousands?) of testers is not easy.
I followed the instructions on the GitHub and yes, I'm getting segfaults.
coudlnt create file "/var/tmp/vlang0.0.12//vrepl.v"
Segmentation fault (core dumped)
EDIT2: okay, so I redownloaded the whole thing and yes, you fixed that now. But it still segfaults sometimes. For example if I try to pass a `-h` flag.
It's going to be much, much more stable in the coming days.
The standard library and package manager + packages will make or break V.
[edit] ow, not open source yet.
The compiler has ZERO dependencies, as stated on the website. You can build it with `clang v.c`.
Do you really think the compiler needs glfw or freetype to function? It's for the graphics library to build things like the tetris.v example.
As for clang, It was made very clear that V compiles to C in addition to emitting native code, and that it's much more stable at the moment.
Hot code reloading will be available on June 22.
Cross compiling already works, and you saw this on twitter. How can you claim it's a lie? https://twitter.com/v_language/status/1137537130887077890
What the heck, so you have claimed that it's just a readme or source cleanup but that was actually a huge missing feature. You said that you have high standards [1], but you don't seem to have high standards on what you say.
[1] https://blog.vlang.io/post/13/Why-isn't-everything-already-o...
Do you ship the compiler with those libraries that require those packages? If yes, then the compiler is not 400kb. The compiler nowadays never means only the compiler executable, it means the complete environment it ships with.
The modules can have gigabytes of dependencies, this doesn't make the compiler depend on them.
Note: some of the comments on that issue have been deleted by the v-lang creator as they were criticizing the claims made.
However, advertising a product can do something and then releasing it stating it cannot do it yet, is one thing, but accepting money for a product that does not what is advertised, is fraud.
If the features were advertised as goals, that would not have been an issue. But these features were advertised as existing and ready to use.
Please do not give this individual money!!!
-----
If you want to support new languages that do as advertised, please support my language Odin or Andrew Kelley's language Zig.
Both are very good languages as alternatives to C but with different philosophies behind them.
Odin: https://odin-lang.org/ Zig: https://ziglang.org/
Oh my. This is alarming. I have never thought that the author was already getting that much money out of this incomplete piece of software.
How does this even get voted so high here? Just on the claims?
The source of V or any substantial V project haven't been released, and the author making inaccurate claims about the compiler (and taking donations on Patreon, by the way.) Why should we accept without skepticism that (closed source app) was written with (closed source language)?
000000010001dc30 g 0f SECT 01 0000 [.text] _f_1
000000010001eba0 g 0f SECT 01 0000 [.text] _f_10
00000001000219a0 g 0f SECT 01 0000 [.text] _f_100
[...snip...]
000000010004bae0 g 0f SECT 01 0000 [.text] _f_462
000000010002a430 g 0f SECT 01 0000 [.text] _f_463
0000000100037940 g 0f SECT 01 0000 [.text] _f_464
000000010001f2f0 g 0f SECT 01 0000 [.text] _f_465
0000000100020220 g 0f SECT 01 0000 [.text] _f_47
0000000100020240 g 0f SECT 01 0000 [.text] _f_48
00000001000202b0 g 0f SECT 01 0000 [.text] _f_49
[...snip...]
00000001000182a0 g 0f SECT 01 0000 [.text] _string_add
000000010001a110 g 0f SECT 01 0000 [.text] _string_all_after
000000010001a020 g 0f SECT 01 0000 [.text] _string_all_before
000000010001a090 g 0f SECT 01 0000 [.text] _string_all_before_last
0000000100019ef0 g 0f SECT 01 0000 [.text] _string_at
0000000100018540 g 0f SECT 01 0000 [.text] _string_clone
0000000100018aa0 g 0f SECT 01 0000 [.text] _string_contains
0000000100018610 g 0f SECT 01 0000 [.text] _string_cstr
0000000100019470 g 0f SECT 01 0000 [.text] _string_ends_with
0000000100018b30 g 0f SECT 01 0000 [.text] _string_eq
(I had to rewrite the reply because I later realized that the binary was packed with UPX, I should have thoroughly inspected strings. Sorry for inconvenience.)
https://www.patreon.com/vlang is the one in question
but he also has https://www.patreon.com/voltapp
Nice scam.
Delete everything and run away with the money? Kick down the can and delay source release once more? Apologies? ("but but it's pre-alpha software!")
now other language designers need to learn from this project
keep your language simple, keep dependency list tiny, make clean syntax, focus on efficiency and small file size, and you win patrons
but people often then bloat their project, with uneeded features, that makes language harder to read, and harder for tooling to support it
edit:
i love Zig, i'm not using it, but i plan to once package manager is ready and vscode plugin with autocomplete and debugging is available
please make it happen, open bounties if you can't
We mark follow-up posts as dupes unless they contain significant new information (https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...). In this case, the significant new information is the open-sourcing, so I think it makes sense to leave up.
V is very similar to Go, and these are the things it improves upon:
- No global state
- No null
- No undefined values
- No err != nil checks (replaced by option types)
- Immutability by default
- Only one declaration style (a := 0)
- Much smaller runtime
- Much smaller binaries (a simple web server written in V is 65 KB vs 7 MB in Go)
- Zero cost C interop
- No GC
- Much faster serialization using codegen and no reflection
- Precompiled HTML templates unlike html/templates that have to be parsed on every request
- Fearless concurrency (no data race guarantee at compilation)
- Enums
- Generics (in July)
- String interpolation: println('$foo: $bar.baz')
- Stricter vfmt to ensure one coding style
- Centralised package manager
In C the only memory available to a function is its arguments and data with static duration. That static storage is synonymous with global state, if it isn't known at compile time.
A C-compatible closure basically requires an executable chunk of memory that captures the state along with the istructions to push it to the parameters area (based on the architecture's calling convention) and then jumping to the actual function.
This is not global just because it's scoping the state with the function. On the other hand it becomes global the moment it gets installed to a global handler table (because there can only be one such handler).
However a language that limits globals (and forces people through this kind of hoops in order to deal with cases where singletons are really needed) encourages a coding style that makes it easier to test your code in isolation.
Just move "global" (aka: main() ) up 1 function. And then, run everything in that function. Hell, it could be a try-catch loop equivalent.
COM APIs expose a global class factory as the main interface to a shared libraries.
Embedded systems and drivers require globals in one form or another.
"Globals are evil" comes from the fact that globals have side effects, and side effects make things hard, especially in modern software that utilizes asynchronous/concurrent logic. That just makes them unwieldy, not unnecessary. Especially when interacting with legacy systems that require globals.
Yeah, state sucks. But sometimes, you need a starting point, and diff from that. And, that's state.
One of the safe ways of handling global vars, is by having only a single non-interruptible function that can mutate global. And you have best make sure your global-mutating function is fast. You don't want to miss IRQs that might fire off but are blocked.
https://www.ericsson.com/en/mobility-report/internet-of-thin...
A kernel doesn't really need a garbage collector, but keep in mind that some modern GCs can literally be tuned to have ms pause times on absolutely enormous heaps which given that reference counting can have unbounded pause times too can make them an enticing option.
The real reason to avoid garbage collection is typically memory usage in my experience
There are reasons not to use a Garbage Collector but 99% of the time they are absolutely fine if you understand what your particular GC does and does not do
Clang/GCC both have suites of sanitizers which are usually excellent and easy to grok, these are also available in many language frontends based on LLVM (and maybe GCC?)
You can just throw every tool you can find at your CI if you're paranoid, too.
I also think it's natural for people, both language creators and users, to react badly when they see that someone is essentially succeeding by lying to people in a space where there are honest alternatives that already work.
[1] https://github.com/vlang/v/issues/35 (For example, there are ways to implement generics or interfaces without AST, much harder but a possible endeavor.)
https://news.ycombinator.com/item?id=20231484
Calling me a scammer because "V requires glfw and freetype". I have no words.
Don't tell me that it is a pre-alpha and will be updated on 22 June, that reads like a sure way to instantly kill your reputation. Always make sure that what you have presented (not what you will present) and what you have said align to each other.
You say "also". What else?
So it is your hard dependency. Describe so.
> You say "also". What else?
If you think that they are spreading the misinformation because some of claimed dependencies are actually for stdlib, you should think again. A substantial subset of HN users would think that "zero dependencies" promise extends to stdlib, as it is technically possible to have out-of-box UI and graphics in the stdlib and especially Go was famous of its independent crypto and network libraries. Your statement was not clear enough.
Next?
There are three problems. The first is that closed languages die [0]. V is not Free Software, which is disappointing but not atypical; however, V is not even open source, which precludes a healthy community. Additionally, closed languages tend to have bad patterns like code dumps over the wall, poor community communication, untrustworthy binary behaviors [1], and delayed product/feature releases. Yes, it's certainly embarrassing to have years of history on display for everybody to see, but we all apparently have gotten over it. What's hiding in V's codebase? We don't know. As a best guess, I think that the author may be ashamed of the particular nature of their bootstrap.
The second is that V's author makes promises and claims which are then retracted, falsified, or untestable. Most notably, source for V's toolchain has been teased repeatedly as coming soon, but has never been released. Without an open toolchain, none of the claims made on V's front page [2] can be verified.
Finally, because we can't not talk about it, V isn't a very compelling language. At best, it could be seen as an iterative improvement on Go. If V were more open, then we could make more sincere and complete comparisions, but as it is, V's author alone gets to control the comparisons [3] and benchmarks [4]. Maybe the best argument to be made is that there is room for a series of languages which focus on compile speed, where languages like Go, Jai, and V compete based primarily on how quickly they can transform zero-cost abstractions into low-level code in a single pass.
...But if that's the game, then it's only a matter of time until one of them rediscovers FORTH...
[0] https://blog.golang.org/open-source
> Most notably, source for V's toolchain has been teased repeatedly as coming soon,
It hasn't been teased repeatedly. It's been "coming in June" since February.
Why lie?
Can the V toolchain translate C++ to V? It could in February [0] and May [1]. You had only to document it [2]; will the feature be available at the end of the week?
[0] http://web.archive.org/web/20190226163127/https://vlang.io/d...
[1] http://web.archive.org/web/20190520021931/https://vlang.io/d...
Now, waiting for your reply on my previous question about the deadlines. Why lie?
I'll address all their claims and lies in a blog post after the open source release on June 22.
How far does the 'linux' specification go. Say I want to run a V program on AIX what kind of libraries will I need?
What about the 'windows' specification. Do the redistributables support windows 2000/7/Vista/8/8.1/10
We have a lot of different systems on our clients, mac as well. It would be nice to read concrete requirements for running to really see how much effort rolling out a V application would be.
[1] https://forge.rust-lang.org/platform-support.html#tier-3
macos was out, but got pulled.
If it included an optional GC, version 1.0 of V would probably be my favorite language and I'll definitely follow its future development.
transpiring to c means you can sneak it in at work, which is nice
No global variables
No undefined values
No undefined behavior
No variable shadowing
Bounds checking
Option/Result types
Generics
Immutable variables by default
Pure functions by default
Immutable structs by default
me> Wow. That's a good feature set to have !
[1] https://twitter.com/8vit_devel/status/1141573808320647168
This language can claim to be very close to C/C++ in terms of runtime performance characteristics because it compiles to C.
I'm reading the comments, clicking the links to GH issues, reading websites and blogs and comments and you seem to have a following. A loyal one. A vested one. Sure there are detractors, but if you step back and look; all your detractors are fueled either by your inaction, or your lack of transparency. All your supporters trust you, which is what you want. So all you have to do to take the wind out of the sails of your detractors is come clean, stop setting arbitrary forcasts mere hours into the future (pointless, sloppy, rude to your paying supporters), and just be straight. People paid hundreds of dollars for vlang. Do you think they care if there are a few hacks holding it together? They WANT to help you with this, and you claim to "want" their help and support.... SO LISTEN TO THEM!
There are hundreds of comments in this thread (many of which from shills and throwaways) that you could chop off at the knees by simply not jerking everyone around. Do yourself, and vlang, a favor and either embrace open-source (and all that entails) or don't. Just do something to stop all the drama. I haven't been able to learn ANYTHING about vlang (and I don't know if I want to) because of all this bullshit.
This breaks the site guidelines. Please review them and follow them when posting here.
I also broke the rules intentionally by using caps instead of asterisks. For that I apologize, but regardless of HN rules there is something going on in this thread. More than simple honest discussion.
To pick just one possible explanation, sometimes people feel so strongly about a topic that they are propelled into making a new account where they had previously been lurking. I don't know which account you're referring to, so I don't know if that's the case here. However, you don't need to "call" them anything. You can respond if you want to, as long as you do so thoughtfully and substantively and without personal swipes.
https://news.ycombinator.com/newsguidelines.html
Edit: if you mean https://news.ycombinator.com/user?id=kingkong2022, we banned that account for egregiously breaking the site guidelines. A better way to express your frustration would have been to flag the egregious comments (see https://news.ycombinator.com/newsfaq.html). That brings them to moderator attention. You could also have emailed us at hn@ycombinator.com, which would have brought it to our attention sooner.
Someone who says no first then yes later is a "good guy."
- Most things call just out to C.
- A lot of examples don't even compile.
- Some things use CLI curl or mkdir, this is /INCREDIBLY/ insecure.
- Many things are unimplemented.
- Dev banned me off org when I opened issues about these and deleted issues. I was unnecessarily rude on some which I apologize for, but deleting them and calling me a troll was uncalled for.
I wrote about them here: https://twitter.com/boy_edgey/status/1142504580074344448 (thread)
Starting a report with "You idiot" or "Oh god this is a fucking goldmine" should get you banned, even if the issue you are reporting is real. Such reports aren't trying to contribute to the project; they are trying to boost the reporter.
I wouldn't say troll, but you still come out as rude-ish in this comment.
"- Some things use CLI curl or mkdir, this is /INCREDIBLY/ insecure."
Not anymore than tons of established projects that use the same...
Say that you have a website that relies on downloading content from URLs supplied by users. A user can send a "specially constructed" URL ("anything;commandgoeshere") and run any command they'd like on your server.
Honesty I don't see why the hype behind Vlang and why so optimistic comments here.
Vlang feels worse than a pre alpha software with a good marketing team that is just trying to make money. It does not even have the features it claims it has. But just look at its patreon, it gets much more than odin lang, which IMO is much further into development than vlang is.
That said, it would not be so bad if the developer did not make false claims and just say that this is pre-alpha software, but instead he makes bold claims and fights for them aggresively (see issue by gingerbill linked elsewhere on this page), which can now be seen that all of them have been lies.
Edit: (posting my comment from below) https://support.patreon.com/hc/en-us/articles/204914235-How-...
People with patreon accounts should report this guy.
No it doesn't. You can build the compiler with `clang v.c`
> But the readme says that the UI package does not run on Linux, so how can Volt be written in Vlang?
The UI package is not available for everyone on Linux yet. Doesn't mean I can't use it.
> hot code reloading is not present
It will be on June 22.
Why do you spread lies and even ask to report me based on these lies? Are you the developer of Odin, who started a similar thread 3 months ago?
p.s. It says in the docs that its name is not vlang. That's just the web domain.
If so, all the single letter languages are getting stomped by Go, which is already used for a verb, noun and a preexisting programming language [0].
The technology to pick new and easily searchable names has existed since it was invented in 2005 by computer scientist Randall Munroe of xkcd. Language designers should use it. There are still unique 4 letter combinations available!
Having immutable variables, no null type and option types is not enough to make a language Rust-like IMO because dozens of languages have those things.
ADDED. Now that I know more, I see you have a point: V and Rust are the only 2 languages I know that have immutable variables, no null type, option types and no automatic memory management (i.e., garbage collection): https://vlang.io/docs#memory
However, since then, two things have happened:
1. The source has been provided.
2. The website has been updated to note which features are unavailable.
So, this is now my position which I have stated elsewhere:
> Now that the website has the "WIP" label to communicate which features are not available, and the source is released, I no longer consider this project to be fraudulent. The information is available to everyone, and people who donate on Patreon are making an informed choice.
> I'm genuinely glad it turned out this way. Good luck on your endeavor, and welcome to the programming languages club.
Calling someone else a scam artist and their work a fraud is an example of this and is obviously not respectful, however honest it may be. Moreover, if you begin by turning the knobs up to 11 ("This guy is a complete fraud"), there's nowhere else left to go, which explains why the discussion after that was so lousy—not that it excuses any other commenter.
I've detached this subthread from https://news.ycombinator.com/item?id=20251393 and marked it off-topic.
Edit: in case it isn't clear, I'm not taking a side about the technical issues. I haven't looked closely at them (or at all), and these points about the site guidelines hold even if one side was 100% right and the other 100% wrong, or vice versa.
https://news.ycombinator.com/item?id=20230351
And then you proceeded spamming this on Twitter, GitHub, Hacker News, and Reddit. Maybe even more platforms I didn't notice.
https://github.com/vlang/v/issues/292#issuecomment-504281727
By the way, shelling out to curl and mkdir also counts as dependencies.
> I'm glad you are no longer deceiving people
This is a passive-aggressive way of continuing the same flamewar. Please stop.
What this revealed to be is a bit more than a university Computer Languages assignment.
A toy project if you want.
EDIT: No idea why this was flagged, I don't understand the norms of this strange website.
My suspicion is that people object to calling this persons' claims essentially a lie, which is just the truth. It is dishonest to use the performance numbers of an incomplete project while listing the features of the complete project, which will certainly decrease performance. The website is replete with obviously absurd claims, like a completely baseless claim about throughput that assumes compile time is linear in code size.
But what's actually pathetic in this affair is the anguish and upset of a bunch of internet nerds over a project that has received, in its 3 months of existence, less than $2500 USD. This is peanuts, but everyone is outraged over a "scam" because the real scam is open source getting a bunch of people to work for free, hoping at a chance of getting peanuts like this.
Please refrain from personal insults and take the time to read the guidelines before commenting further.
(not judging about that case here)
If you do a search in these comments for people who have actually given him money, I think you'll find that none of us have done so under the pretense that all the features he listed on the website are finished.
We're also not "buying" anything. We're supporting a developer who is writing a language we would like to one day use. How else is it going to get written? Do we expect somebody to toil away in obscurity for no pay for 5+ years first?
I would consider it money well spent even if he never finishes it. I'm voting for the language I want with my wallet.
Yes, this opens me up to making me feel like a sucker if he is a scam artist. But, he's delivered things in the past and he's delivered things even since the last conversation. Most frauds don't ship.
Why is it so many people online can't admit when they're wrong? "I'm sorry. I was wrong." Is that really so hard to type?
[1] https://www.kalzumeus.com/2014/04/09/what-heartbleed-can-tea...
Surely people would have been a bit pissed if a strange project got backers, but the problem here was snake oil PR.
"It's amazing, better than anything else, just give me a bit of money and I'll give it to you when it's finished"
There is no longer any reason for separate scripting languages.
There is no longer any legitimate reason to write C code.
Rust had better watch its back.
I may soon begin to resent C++.
AndyKelley never ever forget why Ycombinator runs a "news" site.
YCombinator is a propaganda and VC funnel for upcoming projects that might make them money. The convenient excuses of tone policing is to not scare away upcoming companies and orgs that might be reprehensible to the public, but fit into the idea of (0) Moloch.
The SEC only requires significant transparency to Public corporations, which YC doesn't primarily work with. So, they can be as opaque and 'fake news'-ish as they wish. And they do, via "Hacker News". HN/dang has removed and/or modified and/of split off threads to lessen the impact of projects that affect them. And my guess is that V is one of those projects that caught their eye.
Instead, you'll see dang and similar giving edicts from above dismissing and ignoring legitimate complaints. Why? It all boils down to money. And YC wants more. Is that really surprising?
Now, why aren't I posting under my usual username? Because bans, hellbans, and other 'bad user' flags are a thing. And YC would never approach such transparency. They won't even try for the GDPR, and that's saying something.
(0) https://slatestarcodex.com/2014/07/30/meditations-on-moloch/
-------------------------------------------
(My response, since you flagged it:
If we listened to anything you've taught us, you don't do something you're good at for free.
So, why do you run a news site? It's certainly not out of the goodness of your heart. My not-so-dark-idea is it benefits Ycombinator in a significant way. )
What catches my eye is flamewars on Hacker News, because part of being a janitor is mopping those up. Our deep dark purpose? To have an internet forum that doesn't suck. Unless you have plumbed my unconscious and know my thoughts better than I do, that's all we're trying to achieve. That alone is plenty valuable, so it's all we need to optimize for.
p.s. Nobody flagged your reply. It got caught in a software filter, and moderators unkilled it, as we often do.
So, why do you run a news site? It's certainly not out of the goodness of your heart. My not-so-dark-idea is it benefits Ycombinator in a significant way.
https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
There's simplicity on the other side too: YC just optimizes for the number of great startups it can fund. How optimizing HN (by keeping it interesting) benefits YC (by helping it fund more great startups) is left as an exercise to the reader [1].
The reason we don't mess around with local optimizations is that they're a bad trade. What matters is the global optimization. Think of the goose that lays the golden eggs. If you have the goose, why focus on an egg or two? Focus on the goose.
[1] Actually I'd better not, or someone will make up something nefarious. The reason is that some HN users end up founding YC-funded startups. And many are startups that might not have gotten started otherwise.
Sure, it's paranoid. It doesn't make it false.
Those comments were generally respectful; I saw no reason to remove them. Seems over-zealous to get rid of any disagreement with a moderator's decision.