I certainly did feel some of that in the past, but not anymore. I started using V for this project fully expecting it to go wrong, experience no end of issues, bugs, memory weirdness, edge cases etc., based on the many articles targeting V. But like with everything, I also tried to stay as objective and unbiased as possible, and that just... Never happened. If anything as my experience and exposure with the language increased, so did my enjoyment, and confidence that V was just the right choice for the project, and for me.
I'm in a weird position, where I have no personal bias or stake towards V, I just like using it, but I frequently get attacked or questioned for making a choice that people find offensive or incomprehensible. It's almost like they see my not choosing something they like, like Rust, or Zig, etc., is my way of attacking them for choosing it for their own projects. No, not at all. In my opinion, the more languages that exist the better, the better the range of choice. This isn't a war guys, holy or otherwise. Let's just try and stay in our lane. There is work to do, we just need to get it done.
I didn't mean to accuse you of being biased, I was just calling you not to be in case you were. I am sorry it came across otherwise. Your point of view is just as valid as anyone else. Also the editor project is completely separate to the main V team, I suppose I help with V itself in my own small way by finding occasional issues and raising them with the core team, but I am not equipped nor frankly interested in putting my own efforts into the language dev itself, it seems pretty well staffed over there atm.
This AI answer is mostly referencing sources between 2020-2023. The only exception is an article written from last year, which itself admits "Anyone evaluating V for use today should obviously make judgement based on the language's current state.", but doesn't actually do that, it itself regurgitates points from other sources made multiple years ago. I think the recommendation I give is my staple "ABCs". Assume nothing, believe no-one, check everything.
I've not found any issues with using v for this project, please try and be unbiased and objective and I urge you to try and write a non trivial program and let the results speak for themselves. Up to you!
They said years ago, when they last took a look. Just a thought, maybe just let all this go, people are complicated, you'll never please everyone. It's not worth the time trying. If anything you're giving them more ammo to prove them right about your attitude to negative takes. I'm not taking sides, just my opinion! :)
I've been finding it perfectly suitable for this and other projects. Have you updated your point of view after recently attempting to write and profile a non trivial program?
Haven't heard of this, thanks! I'll definitely be taking a peak at their buffer implementation. Zig was a no go for this project for me due to the lack of concurrency.
This is a good POV. For a while there they did think they had a chance at finally figuring out how to solve the halting problem. They of course haven't, and had no chance to do so, but they wanted to discover that for sure, for themselves. So I admire them for trying. These days autofree handles about 95% of allocations, but what's left dangling is pruned by their very low cost tight cleanup looped GC. If you really need to you can do manual memory management, from my fairly substantial usage of the language so far I've been a satisfied customer for sure. I've found compiler bugs, strange behaviour, edge cases etc., yes the team are blunt and to the point, but they're the most professional language team I've ever interacted with, often responding within hours, one time a compiler fix was released the next day.
Thank you everyone for commenting and sharing your thoughts regarding my project! I'm aware of the history of V and it's less than stellar reputation in the beginning. I really hope this comment section doesn't devolve into yet another stream of people regurgitating blog posts from over 5 years ago. I evaluate languages and their suitability for projects by just my personal experience using them. Does it do what I need, and does it do it now? That's it.
Yes pretty much. Admittedly that's all the README needs to say. When I first wrote the project README LLMs were still relatively new for public use, it was much harder to detect back then. Thanks for the feedback.
The goal of this project is to show that it's easy to make your custom window manager, that we dont need to waste GBs of ram when showing windows and to provide a window manager that you can understand by looking at the code (so that you can shape it according to your needs or create your own entirely).
A very big motivation for this project is to show that it is simple to do your own things and that we can make simple and lightweight software. Simple and lightweight often go hand in hand. Dont hesitate to try to do your own things, it may be scary because the existing well known projects have enormous code bases but we dont need this much to make a simple wm (tinyvvm.v ~400LoC).