Impressive, I'm looking forward to seeing more of this project. Did you draw inspiration from Talon? There are a lot of similarities when it comes to the voice commands.
Thank you! I only found this thread today. I was inspired by talon but all I really wanted was some phrases that worked everywhere and to use normal tools like vim and a tiling window manager, and hoped it could all be foss. I think talon's more about app specific phrases and trying to take the role of your text editor and window manager.
Last time I looked at Blazor it only had two options, which were both equally horrible for public websites.
You either had to ship a big and bloated WASM file, which was at least 10x the size of competing JS frameworks, and in some cases 100X the size. Or you had to render all dynamic parts of your website on the server, which made latency a huge problem, since your website feels sluggish between each interaction.
I don't know when it was the last time you took a look at Blazor, but Blazer server is extremely fast. I built some big corporate apps with it and never had any latency problems.
Were they internal or external apps? Because latency was the problem last time I looked, and it won't be super noticeable if you have the servers that close to you.
Does it affect your vision when using them for many hours? Whenever I use VR headsets for more than 1 hour I tend to get blurry vision once I take them off, since my eyes have adjusted to having the screen so close to them.
I am super interested in getting the nreal glasses for work. But I'm also a bit hesitant due to this.
I think everyone experiences them differently. I can tell my eyes have a bit of "lock-in", but the level of lock in is tiny compared to staring at a laptop screen or phone for the same amount of time. It's definitely not in the realm of other VR products I've used.
I'm not sure where you get the impression that people who would benefit from this tool have no friends. That requires some quite absurd mental gymnastics.
I don't have any experience with vim or other alternatives, but after reading that article or seems like kakoune is way better in practice. I wonder why Lapce didn't go with "object -> verb".
I think many would agree that object-verb is the better way, but the vim way is old and more established. I would imagine the sheer number of users would be far more for vim’s model.
That said, it’s a mode that could be introduced in the future as kak-mode I suppose.
It sounds like Serenade.ai would be more useful to you. It is more of a complete product, with the ability to add custom commands on top of it. Plus it's open source.
I'm not trying to steal the spotlight from Talon/Cursorless though, they are amazing and super useful. But it is definitely a much more fragmented ecosystem which requires more work.
I think I looked at that briefly at one point. I passed by it quickly because it lacked support for both my usual editor and language.
But I've recently revisted VS Code and found it improved enough to be usable for me. My hands have also improved enough that I can do a reasonable amount of typing now too, so perhaps adding language support would be an option. Hm...
V looks interesting, and I wish it the very best. However the attitude of the lead developers toward criticism or negative feedback (even if it's not valid) is highly off-putting imo. Everything negative that people say appear to be taken as an "attack", and as far as I've seen they are quick on the trigger in regards to banning or blocking people that they disagree with. And at the very least they just completely disregard all negative feedback as lies, scams, conspiracies, etc.
The responses I've read by the devs are in stark contrast to what I've seen in other languages I use, such as Rust. I hope that as the language evolves, the developers will start reflecting on the way that they interact with others and how it impacts people's view of V. I could never justify using a language like V in production if I couldn't even trust the lead developers to be level-headed during criticism.
I'm sorry for ranting, I really wish the best for V and its maintainers.
> I'm sorry for ranting, I really wish the best for V and its maintainers.
I appreciate you posting this. I like the premise of V and really want for it to suceed, but this is a good summary of why I think so many people dislike V: the lead dev and community do not engage criticism in good faith.
I'm sure V receives its fair share of unwarranted criticism, but a lot of legitimate criticism and questions are either met with a) hostility or b) incredulity, which causes people to dislike the language for fundamental reasons.
Both the creator and community members gaslight (for lack of a better word) and act as if they're happy to receive questions or feedback, but even in this thread you can see people being treated like I mentioned above.
I mean, the article linked at the top is just outrageous - just read through it. For instance, it claims that V misleads by claiming that it has no null. But really what the author has done is found a bug in V that allows a variable to be set to null. A bug that unintentionally leads to creation of null is wildly different than V not supporting non-nullability at all. It'd be like using FFI in Rust to set a non-nullable variable to null and claiming that meant Rust had no type safety. It's absurd.
OP kicks a conversation in poor faith with "Wanna know something funnier also posted in previous thread?" about a V bug - which HN turns a blind eye to - and then suddenly the HN community pounces on the V maintainer when he gets frustrated in return? What?
> OP kicks a conversation in poor faith with "Wanna know something funnier also posted in previous thread?" about a V bug - which HN turns a blind eye to - and then suddenly the HN community pounces on the V maintainer when he gets frustrated in return? What?
I specifically linked to the_duke's comment offering some good-faith feedback.
---
But I digress. My intention isn't to argue that V is bad, just to provide context to why it's such a divisive topic.
> I specifically linked to the_duke's comment offering some good-faith feedback.
My point with this thread is it follows a common pattern. A HN user will post something in bad faith. The maintainer will respond with annoyance. Then someone like the_duke will moralize about how the maintainer shouldn't be so antagonistic. Then GP will put it in a list and say "the lead dev and community do not engage criticism in good faith."
There are some repeating thought patterns on some hot topics in this forum that makes me question whether it's work of trolls or naive people asking the same questions that end always the exact same way.
When it happens, it feels like living in Groundhog Day.
See any Brave post. There's a comment about BAT stealing money, people debunking it and the same arguments over 10 comments. Just below that someone mentions Eich's history at Mozilla, same pattern.
See any Urbit post.
See any V post.
See any foone post.
In these threads you find always the same archetypes of comments and posturing it makes me wonder if we're really living in a simulation of not very good AI. Or that a group of people is collectively pretty dumb and more predictable than you'd think.
The maintainer is the face of the product in certain ways. We would never defend a corporate CEO responding in annoyance to their free/paid users because it's unprofessional and puts the brand in a negative spotlight. In the same way, if you're leading/promoting a project you are held to a higher standard. You can choose to ignore bad faith comments, or respond in a positive way to bring the discussion to a higher level of civility.
Yes, it's annoying to have people give bad faith criticisms. But if you want a product to succeed and you want to foster a positive community, you should always elevate the level of civil discourse. So I disagree with your sentiment that other users are moralizing here.
If I'm going to engage with a product, it gives me much higher confidence knowing that the maintainers conduct themselves in a professional manner, even when a user is unprofessional.
> A bug that unintentionally leads to creation of null is wildly different than V not supporting non-nullability at all.
You have the "badness" ordering here totally the wrong way around. Soundness is about trust.
A known-unsound system is not necessarily bad. I use C and Python. I know the tooling can't give me very many guarantees, and that I have to do the book keeping myself. "Caveat emptor".
In a much, much stronger sense: there is absolutely nothing wrong with a sound system with explicit escape hatches. Bothing. I use sorry in Isabelle and admit in Coq. I do type casts in Java. I know where I can and cannot trust the tooling, and there are clear flags where I need to do my own book keeping. FFI in Rust is an explicit escape hatch.
I can't think of a single system that doesn't have some sort of explicit escape hatch from soundness. As long as it's explicit and understood and above all intentional, this is a feature rather than a bug.
But it's very hard to justify using a system that's supposed to be sound and isn't! I don't know where to trust the tooling.
And the blog's examples are not contrived. They are actually very straight-forward mistakes as far as type systems go... most production type system bugs are much subtle.
> But it's very hard to justify using a system that's supposed to be sound and isn't! I don't know where to trust the tooling.
At the point V was version 0.2. Of course it has bugs - even bad bugs.
The article went through each feature of V, found one bug per feature, and claimed that V failed to have that feature.
There are constructive and non-constructive ways to start a conversation about bugs in a language. One constructive way is to open Github issues. Writing an article claiming that a language fails to have those features at all is one of the least constructive ways I can imagine.
> There are constructive and non-constructive ways to start a conversation about bugs in a language. One constructive way is to open Github issues. Writing an article claiming that a language fails to have those features at all is one of the least constructive ways I can imagine.
Github issues vs. articles must be a generational thing; I have never used Github's issue tracker even for FOSS projects (admittedly not because we had better alternatives). I'm not even particularly old, but I am old enough to pre-date GH issue trackers as the de facto FOSS issue tracking solution.
Certainly, I would reach out to the author of a project -- especially a personal not-for-profit FOSS project -- before putting them on alert with a highly critical blog post. Except in exceptional circumstances (eg intentional spyware or backdoors embedded into the project).
But I don't think of articles as better or worse than GH issues in terms of form.
This kind of reminds me a tame version of the "disclosure debate" in security in the 90s/00s, I guess. Just because a lot of that debate was claimed to be about protecting users but was actually often about protecting egos (and "look how smart I am" zine articles that weren't entirely written in good faith or professional ethos). Except, of course, that in this case I think a simple cultural difference could explain a lot without any ill intent on either side.
(FWIW I'm not saying either of us is right or wrong. Perception is inherently subjective and all culture is relative. But I think I better understand how this project became so controversial...)
I think what was being referred to was any V GitHub posts, which would involve the V community. The V community has nothing to do with nor have any control over blogs and websites owned by others.
As for Cadey, it appears the person is continually self promoting, to include odd accounts continually linking to old and outdated blog posts on its website, at the expense of the V language and any chance given (see almost any HN post on V).
Cadey (or under various names) was the one that started off smearing V's author and the language with things like "V is vaporware", "V is lying", "recommend against using it for anything", hoping V would die off type nonsense, etc... Mind you, the attacks started against the very first released Alpha, as if it was supposed to be instantly production ready (and that is very much not how programming languages work).
So other programming languages are given the benefit of the doubt of even after say 5 or 10 years of development, while V was supposed to be a finished polished language from day 1? Just plain ridiculousness and clear bad intentions.
Xe/Christine never claimed V had to be polished on release. That's patently ridiculous. What they said was: the original features were not called out as being goals, so they took them as features that (obviously) didn't work. Those claims were eventually marked as "WIP" or whatever, which is exactly what Xe wanted. No one is claiming an alpha/beta doesn't have bugs, but V promoters like yourself claim any reminder of V's prior actions are saying that.
IMO, V has made great strides since the initial release, but none of Xe's claims were inaccurate. All Xe's first post ("V is for Vaporware") did was call out the website as being misleading.
Sure, people could see that it's a 0.x release and know it's an alpha/beta, but that's not the point! It didn't say that the features were WIP until after Xe's post. Compare vlang.io two days before Xe's post[0], and the day after their post[1] (notice the addition of "WIP" markers and a new paragraph about 1.0 above the fold).
It also doesn't help that any time a post about V comes up, people try to explain these things, but the author and people like you refuse to acknowledge it. What most people want is for V to admit the website was misleading at the beginning, but it is now a bit more clear. What we get instead are conspiratorial claims of brigading to destroy V. Unless people can point to some Discord or Reddit group that actually does conspire to destroy V, it's a hoax. As much as the author wishes, posting negatively about V because of its past is not a conspiracy.
And here we are again, like it's one the movies of Groundhog Day or Edge of Tomorrow, where somebody keeps hard pushing Cadey/Xe/Christine (and whatever other connected names) old blog posts to promote the website at V's expense.
V is an open source programming language. Of course the V developers and contributors are going to have continual discussions among themselves and then make changes to their goals, roadmaps, features, and timelines. To include make mistakes and have to do corrections. This should be common sense and understood, but apparently not, or least not when it comes to discussions involving the V language.
It's insanity to continually run through the wayback machine on any alpha version of a programming language's website and run around: "Why is there a change in this language feature?" or "But, you said the language would do this before." or "Why you changed the date?". What is more relevant is the present website and present version of the programming language, because things continually change and that's how development works.
In regards to your conspiratorial claims, lets check the previous posts:
1) Mst made a claim that somebody named Cadey was mistreated by the V community.
This looks to be false. Doubtful if anybody in the V community even knows who Cadey is. Furthermore, the "V community" is not in control of random blogs, websites, or posts on the internet or their content. If you are going to refer to the "V community" it needs to be at least somewhere officially recognized by them (like V's GitHub) or at least where one can prove they significantly congregate at.
2) The V creator didn't know who in the world Mst was talking about and asked for a link as proof.
3) This was then used as an opportunity by an odd account from 2010 (Neven) with only a few posts (really odd) to then re-push and promote upon us again the Cadey/Xe/Christine website.
Which drudges up 3 year old mostly non relevant crude, that nobody really cares about except V detractors that seem to get off on it, that is pushed on every HN thread involving V that I've seen.
Note- And it's such a repeating pattern, of what V detractors do (even without mentioning the downvoting, flagging, trolling, and gaslighting), that others are noticing it too. Among them, sph and johnfn, and check out their posts above.
I'd note that my attempt at "I'm not actually mad at you, but here's an explanation of why your current attitude is counterproductive" (with the obvious caveat I may've been complete wrong) got flagged to death rather than argued with.
Which is the original repeating pattern, I'm afraid :(
I don't really agree. V seems to attract a much larger than normal swath of people who enjoy trying to score points off of technicalities. e.g. people claiming the entirety of V is an unsafe language because they found a single bug in the compiler, etc. Languages like Rust never garner this sort of point scoring in the comments.
> as far as I've seen they are quick on the trigger in regards to banning or blocking people that they disagree with
Do you have any source for this claim? Without a source this simply reads as another person trying to sow uncertainty and doubt. I haven't seen anyone banned or blocked on Github.
That's because V already lied once about its memory management, see https://news.ycombinator.com/item?id=31947048. Any highlighting of that fact is met with deflection and dodging.
V is still making dubious claims: his newly invented autofree isn't stable even today after years and users are encouraged to use garbage collection instead. It's hard to trust that when we've been lied to already.
V is not 1.0, so why so bothered that autofree isn't stable enough? Especially if the person is not even using V. Clearly the majority of V supporters and users are not bothered, and are finding V useful to them.
Autofree exists and somewhat works (https://youtu.be/gmB8ea8uLsM), it's a matter of perfecting it so that it requires minimum user knowledge about memory management. You can enable Autofree and use it, but the user must understand what they are doing and reference examples of code and programs that do use it.
So in the mean time, the V developers decided to experiment with and select GC as an alternative memory management method. That should not be a problem for a language in Alpha, nor for anybody "outside looking in", that understands language development. GC usage worked out great for them and the users, so they made it the default. Autofree and manual, would be the other options that users can choose, but they must enable those.
Furthermore, other languages like Nim, have multiple memory management options. I don't see people on HN getting so hot and bothered about that, just for some strange reasons, they seem oddly bothered by V adopting and having multiple options (GC, Autofree, and manual) instead of one.
What? "After years and years"... It's version 0.3. Not even stable 1.0. The conversation you had with the maintainer puts you in a worse light than him, in my opinion.
He's already promised something too good to be true and it turned out to be a lie. From wayback machine https://web.archive.org/web/20190520021931/https://vlang.io/...: "(Work in progress) There's no garbage collection or reference counting. V cleans everything up during compilation. If your V program compiles, it's guaranteed that it's going to be leak free."
I was excited for that. We were all excited for that. Then it wasn't true. I would forgive him but he seems to be continuing.
Then he walks that promise back, pretends he never said it and suddenly invents this magical "autofree" system but gives no details on how it works. Rust was never that secretive, it was based on published theory.
He claims it removes 90% of reference counting but if that was possible then Swift or Python or anyone else would have done it.
If it was based on solid precedent, or there was any research, or he published anything about how it works, or he didn't take donations, or it wasn't advertised on the website, it would be fine. But that's not the case.
Let me get this straight. Someone is running an open source project. They said they are working on some ambitious feature. Said ambitious feature hasn't materialised up to your standards, and now you feel like you've been cheated or lied to?
So are we saying that open source programming languages are not allowed to make changes to their goals, features, or roadmaps?
And if they do make any changes, then people should go to the wayback machine and hold them accountable to what was in the past, and not what they are showing and saying in the present?
Seems to be very unrealistic, and more of a personal grudge or pet peeve.
These aren't mutually exclusive. What isn't captured in individual posts about V is the historical context of previous discussions.
I think many people feel scorned or resentful towards the attitudes, which means they're more likely to speak negatively of it in the future.
When V was first announced, there was a lot of hype about "Volt": a cross-platform Slack app written in V (https://web.archive.org/web/20190315173156/https://volt-app....). It was slated to be released 'soon', but months went by and there was nothing. When it eventually did release, it was nowhere near as complete or polished as people were being lead on to believe. Same thing with V itself, and people were attacked for pointing this out.
There's a long history of over-promising or hyping things that don't exist, and not handling constructive criticism well. So there's a number of people who actively dislike V.
I think the problem initially was that people accused the creator of malice for no reason other than not being more specific about which features were a work in progress. I agree that it's not good to treat every criticism as an attack, but sometimes criticism of V (as an outsider, I've never used it) feels more like anger towards the creator rather than a helpful suggestion. For example, there's a difference between saying "I've found a bug in an advertised feature" and "You're a liar", which is how much of V's critics sound to me.
As you can see the website claimed that its compiler is "200x faster" than C compilers, while neglecting to mention that it merely translates V code to C, so you still have to
run a C compiler.
"400 KB compiler with zero dependencies" (apart from a C compiler and libc).
"As fast as C" - a lie.
Apart from deceptive marketing, there were serious issues with the code quality of the compiler:
>"As fast as C" is not a lie. It literally translates to C.
No, just because it outputs C it doesn't mean it's as fast as hand-written C. Using that logic, every language that outputs machine code is as fast as assembly, which is obviously not true.
If you look at the C that's generated using -keepc flag, I think you will be hard pressed to find any glaring inefficiencies to "hand coded C"; especially none of which GCC optimization wouldn't handle with -prod compiler flag. Even if there were, for the very large majority of users who are not highly proficient in C (which is becoming more and more common these days - Grey beards are rare), the V way is going to outperform novice to intermediate-skilled C programmers hands down.
FWIW, my view is that even the best programmers don't always have perfect non-programming skills and it is better to give them specific objective feedback via bug reports/technical comments etc and not focus on how they are not doing the expected thing or behaving in an expected manner. Focus on and encourage their good work if possible.
> However the attitude of the lead developers toward criticism or negative feedback...
I disagree about that, because there is a major difference between submitting a bug or disagreeing about a claim or feature versus outright trolling, smearing, instigating drama, or trying desperately to create negative public perception.
Issues and discussions can be brought to V's GitHub (https://github.com/vlang/v/issues, https://github.com/vlang/v/discussions), but instead what various competitors and detractors do is create drama filled smear blogs or bad joke posts (on various websites) against the author or language. That's not any attempt at being helpful or constructive, that's more about slander or to create such negative sentiment in the hope of killing off the language.
When issues and discussions are brought peacefully to V's GitHub, they are discussed and debated intelligently. If any such issues have any validity, then they are usually fixed.
> Everything negative that people say appear to be taken as an "attack"...
That's simply not true. What does happen, is various competitors and detractors do specifically attack and smear the language or author, and who have no intention to want to be helpful or make any improvements. To include engaging in downvoting or trolling those who appear to be V supporters.
Such attacks and smears are not about fixing anything, their point is to be destructive, create negative publicity, and dissuade others from using a rival language.
If there are those that don't think that is the case, then simply ask yourself why many of those engaging in such attacks and smearing who claim to be technically knowledgeable or interested in using the language are not making their case on V's GitHub? That's where a person can go to improve V and get it production ready. Continually engaging in smearing is not about fixing, improving, nor reaching out to V's developers or community.
Not to mention that the landing page says absolutely nothing about what it is. Just saying that it's a framework means nothing. A framework can be a lot of different things.
I agree with you, the landing page is very poor, if they are trying to sell the framework to someone it need to have more clear information. Maybe they can learn from next.js, remix.run and redwoodjs landing pages.
I agree. We will do that once we shift focus on marketing/website, which is when we are out of alpha. Currently its a pragmatic low time-budget site that has only as purpose to tell that this exist, not to sell it like the companies you linked.
I'm not the same person that you responded to, but I feel much less secure in TS than in C# due to the fact that typing is not a requirement, and that type definitions might differ from the actual library/framework code. It's still a big improvement over plain JS though.
Vue 3 has excellent Typescript support. It's even built in Typescript. What exactly are you referring to when you say that it's "poor"?