That discussion was one of the weirdest flamewars we've had on HN, complete with an unseemly fight between programming language designers. If you're going to comment in this one, please follow the guidelines (https://news.ycombinator.com/newsguidelines.html) and take care not to repeat what happened there. Remain scrupulously respectful, regardless of how wrong you think someone else is or of how you feel about something. Then your points will be more convincing, and you'll be helping to sustain the community rather than harming it.
In case the author ever reads this: assuming good faith, the effort and intent is laudable, but you've put the cart in front of the horse by having multiple amazing claims that would take many, many man/years to accomplish by experienced developers, which is why they've been received with a lot of skepticism. Even assuming a great level of skill, the claims a priori are hard to take serious, even before taking into consideration the timeline. Now that (part of?) the code has been released, it seems to be little more than a transpiler from V to C, with allowed inlined C, with most advertised features stubbed out. Had you been claiming "this is my target, very much in progress", then the response to them would be less adversarial and more in the line of "there are multiple reasons all of these targets are not necessarily attainable simultaneously". Had you done that, your Patreon would also likely not have a monthly ~1000 USD support either, which is a big part of why you are in the receiving end of online backlash.
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.
> Now that (part of?) the code has been released, it seems to be little more than a transpiler from V to C, with allowed inlined C, with most advertised features stubbed out.
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.
Given that the claim was that V was a native code generator with the option for transpiling to C, I think that pointing out that it's only a transpiler is fair
> 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?
I wasn't around back then. But as far as I know there was never much inline C used, many C functions were wrapped sure, but that's necessary to use POSIX/WinAPIs.
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.
Oh, there are a lot more than this one line as well.
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.
>>Now that (part of?) the code has been released, it seems to be little more than a transpiler from V to C, with allowed inlined C, with most advertised features stubbed out.
>>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.
At least Perl 1 claimed to be a sort of replacement for awk and sed, and it worked great. Also Larry Wall was already known for his patch program even at that time.
Despite the immense neophobia of Hacker News, I'll jump forward and say I think there's a lot to love around vlang.
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.
That's the point of the project. It promises a very buzzwordy professional grade language to rival other languages built by full time teams of engineers. Of course it sounds like gold - unfortunately this is fools gold. We shouldn't be promoting projects like this that are raking in more money than genuinely useful in production open source projects by people who are too modest to hawk Patreons.
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.
Ideas are common goods. Virtually everything claimed by V was tried in at least one or other forms with varying degrees of success. As always the execution is hard.
I didn’t see any immutable data structures in V. I just saw disallowing assignment of variables. But I can still assign an object which itself is mutable, and mutate that elsewhere.
I knew nothing about this project until I saw rants here and on reddit the past week about it. I think many of us have been here; in my opinion (which is just an opinion) this guy got in over his head like we all did when we had limited experience in doing a particular project. I have often thought that I could finish a momentum task in x weeks because in my head it really was a few 100 simple tasks and that was it. In reality ofcourse, it turns out to be a 1000 of simple and not so simple tasks, many of which actually were not very simple. And more importantly; I had never done them before.
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).
So without having followed the story, some thoughts on designing large frameworks, where a programming language is possibly the among the most ambitious because design choices are so consequential.
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.
I'm a big fan of compact code, i.e. doing more with less... but I have been working on langauges for long enough to know that it takes surprisingly large amounts of code to do anything useful in this space.
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.000s
When I look at the great list of features, then actually look at all of this code written in V, I’m pretty underwhelmed. The code doesn’t look that much different from writing C, except it has more Go-like syntax. The language doesn’t seem to be assisting the writing of code very much, certainly not as much as claimed.
Extraordinary claims require extraordinary evidence. If the information presented on https://vlang.io/ had any hint of being aspirational as opposed to comparing it directly with existing languages, and the author had less confrontational interactions with skeptical people online, the reaction to this language would be different. Of course, without the extraordinary claims this code dump would also not receive the attention it has.
It's worth noting that the website now has "WIP" annotations on many of the claims. I'm not sure how recently these were added as this thread is my introduction to the language.
My 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.)
> It's worth noting that the website now has "WIP" annotations on many of the claims. I'm not sure how recently these were added as this thread is my introduction to the language.
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.
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.
It was presented as extraordinary. See the tables comparing V to GCC, Clang and others.. somehow the author managed to make a compiled that weighs nothing, requires no time and makes faster binaries ...
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.
A lot of people have been finding the development of the project on a monthly basis. The work that has actually been done might be unsettling to the patrons.
As a patron myself, I can confidently say you're way off base. The language has only existed for 3 months. It's going to take at least 2-5 years to get anywhere close to feature complete and another 5-10 years to get traction.
You can also mkdir vlib in whichever directory you're trying to run vc and it will generate that temporary directory automatically.
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.
Coming from an outside reference frame (I have zero knowledge of the - obviously contentious - backstory, and I am holding off on reading that backstory until I review this language on it's merits).
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).
If this project was trying to prove there is a space for a language with the features as described, it was a success. Many people want a magical compiler that has simple syntax, no calling overhead to C, and automatic memory management without the overhead of a garbage collector, etc. I really feel this is an indictment of both Rust, for its approachability, and Go, for its lack of common features. I love and use both languages but it has been difficult for me to get other developers to want to use either for anything more than a utility.
There is a problem space and a solution space of programming languages. We all love to have a language is performant and expressive and maintainable simultaneously, and that is a problem description. We have no definitive answer how to achieve that though. We haven't explicitly ruled out that it is plain impossible, but it is evident that no single person is likely to deliver such a language.
> automatic memory management without the overhead of a garbage collector
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.
Okay, I did and I was able to compile the `vc` compiler from the C source. The REPL in `vc` seems to work (at least for the basic printing I tried) and running `./vc -o v .` worked as well. But the new `v` compiler segfaults with:
EDIT: however, if I understand it correctly, it was not the instructions after all, that resulted in everyone having segfaults...
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.
Normally we would, but this case is a little subtler. The project had a big thread a few days ago: https://news.ycombinator.com/item?id=20229632. The issue arose there that the language was not open source yet. Submitting this commit must be a response to that.
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.
It's pretty unclear what its purpose is. The examples look somewhat like go (including something that looks like goroutines, right down to being called with `go`). So, what differentiates V from go, I guess? (Or whatever other language it views itself as competing with, if not go.)
Global state is a feature, not a bug. It's absolutely necessary for a number of application domains and disallowing it by design makes the V language totally unsuited for them
Singletons still require globals. I haven't really dug into V that much, is there a mechanism to make a singleton? If so, how can they claim "no global variables?"
POSIX signal handlers don't take an argument other than the signal code, so if you want to handle them gracefully in a stateful app you need a global to communicate the trapped signal to your main loop.
Closures could be used to implement this use case, provided that they can be exported/represented as native C function pointets, e.g. via a trampoline that captures the necessary captured context)
How would you implement the trampoline without a global? And would the captured context not count as a global?
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.
We have to distinguish what the given language exposes to its users and how the code such language generated works on the underlying hardware (along with constraints due to compatibility with other languages, most importantly C which is the de-facto system interface nowadays).
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.
Global logging in libraries is not uncommon, especially if you need to trap signals (which can only interact with global state).
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.
Ericsson predicts 18 billion IoT devices by 2022. Those all need code written for them. Do you still consider embedded programming a "niche"? Maybe it's one specific case, but it's relevant and ought to be "part of the discussion".
GCs are good for some things and bad for others. I wouldn’t want to write an OS with a GC but I also wouldn’t want to write a web server where I have to manually allocate and free memory. It’s all a trade off.
You shouldn't be manually allocating memory anywhere if you malloc and free. I feel quite strongly about the use of C in modern systems code: The "C" way of doing things can often be very unsafe or at least prone to being unsafe (No fault of the programmer, but if you don't provide RAII and things like that by default it becomes too easy to double free or leave bounds unchecked)
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
Game programmers and also people who seem to think that Garbage Collection involves burning babies and the hundreds of academics and engineers working on it are somehow doing it out of spite.
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
It is not in my opinion. With modern development tools/frameworks providing memory leaks detection I have completely forgotten when was the last time that my programs leaked memory. And I write complex high performance game servers that run for months non stop. You just have to acquire certain culture/behavior when writing code.
All the code I write at the moment is GC-free (By circumstance), but it's clear that not using a garbage collector is a tradeoff between runtime nondeterminism and the complexity of the code (How many of Herb Sutter's talks on smart pointers could have been eliminated if C++ had a garbage collector available, for example) or compiler/language complexity
for c/c++ I use Visual Leak Detector and Valgrind. For Delphi/FreePascal/Lazarus there are built-in tools and also MadExcept . Behavior/patterns are different depending on task/language but generally when writing code if I want to allocate anything I first write deallocation code.
Also, Garbage Collection can be extremely fast when done properly: The Decision to use a garbage collector could be done on performance grounds as well but Garbage Collectors are generally harder to tune than reference counting.
Valgrind (Which also has a bunch of other stuff like cachegrind, which can be a godsend if you are getting telltale cache/branch prediction issues but you can't find where etc.).
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.
The name is good, the language has very cool features on the roadmap. I'd find it interesting even if it was just a concept with no implementation at all, so I don't get what people complain about it. Where do all these naysayers come from? Do they hold personal grudges?
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.
I did not have time to really look at it but if at some point they will accomplish everything in their roadmap it will be one heck of a development tool. Love it.
After going through the source code, I can tell for sure that it's an insecure C transpiler.
- 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 have to agree from the snippets of your reports, the tone of those reports were needlessly antagonistic and superior.
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, too, would delete needlessly aggressive issues on my open source projects if I didn't end up editing them to make them actually usable. Either way, it'd definitely be a ban so the user wouldn't edit them back or escalate with more aggression in other issues.
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.
It's amazing that one person can do all this. It really takes a huge amount of dedication, knowledge and high IQ to invent a language from scratch alone. I think he is trying to Rustify Golang which is a thing I always wanted to do before giving up entirely on Golang.
When I saw your "Rustify" I assumed V has a borrow checker, which it turns out not to have.
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
Dan, it seems like you're referring to me, and I don't appreciate this food fight characterization. In society it is the duty of everyone to call out scam artists to protect each other and that's exactly what happened in that thread. At the time, it was a scam, since the author was collecting money from people on false claims. Respect is not only contained in tone of voice, but also in how honest one chooses to be.
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.
Not only you! and fair enough, I've removed food from my comment above. The previous thread was still an unseemly flamewar, with gratuitous drama of the sort we definitely don't need on HN. It caused a universal WTF among the HN staff. I gather that in some cases this drama was being imported from internet rumbles elsewhere. Those need to stay elsewhere, and people here need to follow HN's guidelines: https://news.ycombinator.com/newsguidelines.html.
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.
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.
Andy - We don't know each other but I follow your works and have a lot of respect for it. Please don't let yourself get distracted and brought down into insults on others, even if it MAY be true. There's literally nothing to be gained, and a lot to lose in doing so.
Thank you for correcting that and the other 4 false claims I noted in that HN comment. I'm glad you are no longer deceiving people about what V can do.
By the way, shelling out to curl and mkdir also counts as dependencies.
It's pretty obvious that this person has essentially lied: they have not implemented the complex features they claim while they hype benefits like compile time and lack of non-zero cost features that will have to disappear when they have implemented what they promised. But I think what's more interesting, more telling, is the level of vitriol over 12k/year in patreon subscriptions. Funding in open source is so absurdly unequal that people are outraged over someone earning table scraps.
EDIT: No idea why this was flagged, I don't understand the norms of this strange website.
An indication of why you might have been flagged and a pointer to the norms of this strange website are given in dangs request to us not to post as you have done, some time before you submitted the post.
You seem like a really unpleasant person and it doesn't really seem worth my time to interact with you, but I want to point out that your post actually contains no relevant information: "to post as I have done" is a tautological reference to my violation, as "to post as I have done" describes the entire sum of my post and behavior. This provides no insight, and seems mainly an opportunity for you to be smug.
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.
You're assessment of me as a "really unpleasant person" and other critics here as "internet nerds" also indicates a lack of understanding of the site's rules.
Please refrain from personal insults and take the time to read the guidelines before commenting further.
Not in general, but many open source developers do hard work and do sometimes not even get praise, so they don't like it when someone who they feel
did not work so hard or not at all and just promised unrealistic things, get's the money.
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.
It's not about founding or donation, it's all about false promises. How you can give false assumptions about something which does not exists and it's not provable. I'm thinking here about all the optimistic features the author is acclaiming. As some of the commenters mentioned practically is impossible to build a product (a new programming language) in solo and having only a couple of thousands of LOC.
You need to stop. There are no false promises or false assumptions going on here. If there were, then the negative coverage over the past three days would include outrage from his patreon subscribers and his patreon donations would have gone down considerably. Neither of these things have happened.
Funding programming language development via Patreon is relatively new that it might be a reasonable characterization. I do think that many PL projects are underfunded and should have better BMs to sustain itself, and one positive aspect of V is that it showed you can actually have a good chance of sustainable cash inflow with proper marketing (more generally, [1] is a good start).
Not a hater, but what was delivered was a 4K line parser and some wrapper functions over the C standard library. I know the author has said he’s got a lot of TODO work, and the source code says as much, but as a compiler writer myself, the current state of this is maybe a step ahead of an undergrad final project in imperative language implementation. It has some of the buzzwords of languages as of late, like Rust and Go, but it’s quick to see that the stated features are quite shallow (e.g., no participation of an advanced runtime like Go, or an advanced compiler like Rust’s).
This was supposed to be originally posted on Dang's post. Evidently, criticizing the mob-boss isn't allowed now.
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.
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. )
I'd happily respond, but this comment is like a greased pig: there's nothing to latch onto. Well, there's one thing: nothing about that project affects YC or HN or us, and we haven't conspired to "lessen the impact". The sinister specifics people come up with!
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.
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.
Of course! But the benefits aren't small and sneaky, they're large and open. HN is valuable to YC simply by being an interesting place on the internet. The most-interesting HN is the most valuable-to-YC HN, the one that is most in YC's business interests. So curiosity is what we're optimizing for:
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.
Wow, did dang really remove all the replies to his comment? Here's what it looked like a few hours ago; it was still open in my browser. https://u.teknik.io/pD724.png
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.
No, the subthread was just detached and marked off topic. Scroll down a bit more to find it: https://news.ycombinator.com/item?id=20251706. This is a common moderator action on HN.
We might eventually change the software to provide links to things like previous children and previous parents, for those who like to follow these things. But it isn't clear to me how to do it without complicating the UI, which would be a cost that exceeds the benefit.
That discussion was one of the weirdest flamewars we've had on HN, complete with an unseemly fight between programming language designers. If you're going to comment in this one, please follow the guidelines (https://news.ycombinator.com/newsguidelines.html) and take care not to repeat what happened there. Remain scrupulously respectful, regardless of how wrong you think someone else is or of how you feel about something. Then your points will be more convincing, and you'll be helping to sustain the community rather than harming it.