Why did you decide to not use V in production?

[dumblob]

Preferably use numbered bullet points to list the main reasons. Thanks!

[Wajinn]

First off, I would like to say that I find V quite useful and I do use it for making various non-critical programs. Like the language, syntax, concept, and direction.

Edited/Updated (2/2023)

Answers (4/2022 and original):

1) Not at 0.3 yet. Hoping it comes out this year; will re-evaluate at that point.

2) Autofree becomes more mature. GC is useable and you can go manual, but would like to have the other option too.

3) UI becomes more mature. The UI is useable, and there are other various libraries to pick from, but would like to see what a 0.0.5 or higher could offer. Has been frozen at 0.0.4 for a while.

I do think that if an experienced programmer is willing to manage the risk and possible updating, I could see them taking chances with what is available now.

"Don't Let the Perfect Be the Enemy of the Good"

Answers (2/2023):

1) Has reached 0.3, is definitively beta, more stable update frequency, and changelog.

Issue is more about syntax and language stability, than features, so less likely to be forced to rewrite previously working applications.

2) Optional GC is useable and you can go manual, but would like to have the other options too.

Not so much an issue, as default and optional GC, but more documentation and examples needed for autofree and manual usage.

3) UI not so much an issue, as various options (VUI, MUI, Isaiah's UI) becoming mature enough in usability. VUI is MIT now.

Still think experienced programmers can definitely move forward with what is available now, if they don't mind some risk over updating.

[tzSharing]

• The first release version is not yet announced.
• The standard library is not yet robust enough.
• Performance is not yet as good as advertised.
• The ecology is not yet established and lacks infrastructure in various fields.
• Lack of IDEs that work well.

But everything is on its way. . .

[pfeatherstone]

Could performance issues be improved by using LLVM backend? So rather than generating C code, have V generate LLVM IR.

[JalonSolov]

If you set your C compiler to clang (-cc clang), you're using the LLVM backend, so you can do your own tests.

V will not be changed to output LLVM IR directly - LLVM is too unstable, changes with almost every release, etc. It's simply too much hassle to keep up with, regardless of any (possibly very minimal) benefits.

[medvednikov]

I think 5% is massive if you're doing high frequency trading, audio processing, gaming etc. So it can't be used in these domains in productions. But it's very much suitable for a long term replacement for Go or Python where performance isn't the most critical aspect

This is false. 5% is within a margin of error, could be the result of the environment. Computers run lots of thing at the same time these days.

Besides, lots of games are written in stuff like C#/Unity, so saying V can't be used in gamedev because of this made up 5% is ridiculous.

[pfeatherstone]

So for Facebook a 2% performance improvement equates to millions of dollars per year. There is a great talk at cppcon about the motivation behind Folly's FBString object. I can appreciate this is an extreme case. But then again, in high frequency trading, they're chasing nanoseconds. I'm not convinced that 5% is within the noise floor of measurements. If that's the case people need to write better, more consistent and reproducible tests. I would need to re-read this thread to see where that number came from. I agree, that sounds a bit made up and not very precise. Finally, I wouldn't get so defensive about people's answers. This language is fantastic and I'm really looking forward to release v1.0 !

[medvednikov]

And yet they use tens of megabytes of client JS. Seems to work fine for them. Also how much slower is their version of PHP compared to C++? Yet they still use it. I wouldn't use Facebook as an example on performance.

V compiles to C, the developer has full control over the generated code. You can remove index checks, remove gc, etc. Thus the C performance is always achievable.

[bddrey]

Inability to optionally use parenthesis () around if/for/etc. conditions. E.g. if (x > 1) { x = 1 }. This is the only safety critical requirement we found V was blatantly lacking.

[medvednikov]

@bddrey would it be ok for you if this error was removed from the compiler but vfmt would still remove the unnecessary () ? Do you use vfmt?

[bddrey]

@dumblob It has not been released after many attempts, but I will ask again. The study had many languages, some compiled, some scripted. Data were gathered over years of work.

[bddrey]

@medvednikov, as to the languages, see previous reply.

I have tried to use vfmt, but it does not produce diff or output that is compilable.

My quick test case was fibronacci.v. and put () around every instance of if/for/... And see if any way to compile automatically. This always failed.

But, to your question, yes internally it is okay to remove them, but the programmer should not be forced to read that code or have warnings. Compiler flags are acceptable.

[medvednikov]

vfmt is supposed to work for any V file. We run it on every single file in vlang/v's entire 230k loc code base.

Please report a bug via github if vfmt doesn't work for you.

Ok, we'll move this if () { error from the compiler to vfmt, today.

[Wajinn]

Most modern languages (Go, Rust, etc.) don't need the parentheses in simple conditions (and some don't allow them to be used at all).
if x > 1 && (y == 1 || y == 2) {
if x > 1 && y in [1, 2] {

I have seen various languages (outside of C) that also allow for the parentheses, if (expression), and differentiate between if statements that don't have them. It could be a matter of confusion, if translating code from languages where they are more commonly used.

Just from my experience with it, I didn't have an issue with adjusting to V's way of doing it, because you can use parentheses in the more complex statements with multiple logical operators or in (as you have shown).

[davyzhang]

I am game server developer, currently with go and some rust. Here are the points stop me from using v for my next project. However I am very interested in this project and willing to try it.

• Proper concurrency support. Like go's routine or rust's async/await. V's current implementation is a bit primitive. I personally prefer go's way to rust's.
• Data race detection at compile time is a bless, or at least something like go's race detector and pprof to help me figure out memory issues
• IDE support, some basic hints and auto completion will do

Other than these above, V does a very good job striking the balance between go and rust, please keep up the good work.

"Premature optimization is the root of all evil." With my own test, go is fast and v is faster, that's more than enough to start a new server.

[medvednikov]

vscode with the vlang/vls addon provides autocompletion and hints.

[medvednikov]

Coroutines, Go style concurrency and data race detection are coming in 0.4.

[dedesite]

Hi,
I really enjoy writing V code, it feels really natural, I like the syntax, the concision allowed by some syntactic sugar etc.
However, I would not use V in production for some reasons :

• Compiler is still unstable : for example, I start to work on a little project and got at least 3 or 4 different compiler errors on some relatively simple code. The community is really reactive and some of the bugs was fixed in less than a day which is awesome, but it doesn't feel safe in a production environment.
• 0.3 is not yet there and I would never run a code in production that could potentially leak due to a problem in the language I use. I mean, for example if you use C, you know that you have to deal with your memory, so it's up to you to manage that. If you use a garbage collected language, you don't care. In V you are supposed to not taking care of that, but -autofree isn't by default. I know I can use boem, but again, for something in production it feels not good.
• Another problem for me is less technical but more about communication. I started V in 2020 and try to read all news I could find about it.
  I stop using V for a year or so, and there hasn't been any communication (like human readable changelog with explanation) on what's going on. For example, I would love to know about the current implementation problem for autofree, what approach do you use etc. I know it's a LOT of work to create such content, and maybe it too early and the community has to grow before being able to take time to explain what's going on an so. But again, for production, I'll feel reassure to be able to take news from a language just by reading official news, and not asking on discord or check some GH issue. In comparaison, zig last release note is enormous !
• standard library is not yet mature and feels like it needs some renaming (for example common_parse_uint2 is not a nice name)

I hope you will be able to take those remarks gently, I know that V is young, I know that you're all doing your best and really appreciate all the help I got on the discord. I was just honestly answering why I wouldn't use V in production.

[medvednikov]

Thanks!

We're working on launching the 0.3 release which won't leak memory by default.

The changelog will be updated and will be kept up-to-date for each release, this is indeed unacceptable.

Please report all compiler bugs via github, they will be quickly fixed.

[dedesite]

Thanks for your response @medvednikov.
I'm aware that V is still in development so all the remarks I stated above are not that bad.
Maybe the most important one is communication.
For example, when someone add a new feature or a change in the language or the vlib, we (I mean the V team) could ask him/her to write a small text describing the functionality.
Then this text could be post on v's blog, and added to the bi-weekly changelog.
From the outside, it seems very important to understand where you are at now and where you wanna go.
I know that writing article (even small) is not the same as writing code, so maybe other people can do that. I'm sure a lot of contributor on Discord would be pleased to write such content.
Just my 2 cents...

[dumblob]

I wonder how the recent new release V 0.3 affects adoption in production (if at all).

Feel free to share your observations here!

[Wajinn]

...from the discussions I had with Fyne devs some years ago (and clarified the motivation in vlang/ui#7 (comment) ).

It's great that you have been tracking this and adding technical suggestions.

I'm not so cynical on V's present way (though not saying there can't be technical improvements), additionally, I'm not at all completely sold on Go's Fyne. Rather, I think team V should keep an eye on it, as a reference or something that VUI can find ways to be more useful. Coderlyfe (YouTube) did some videos on building example GUIs with both VUI and Go's Fyne, and people could see that he found it awkward to deal with Fyne. He was even complaining how Fyne could have been more like VUI, in terms of convenience. Unfortunately, he removed that Go Fyne video. Wondering if he got harassed about it, because of voicing some displeasure or pointing out how VUI made more sense in certain areas.

I think that VUI can work, it's more about that nebulous direction that concerns me. Comparatively, V is definitely progressing down the right track, by establishing clearer road maps and goals. Just hoping that VUI could add more clarity, focus on convenience, and perhaps a form builder at some point.

[dumblob]

I totally believe Fyne feels weird for simple or small projects. That is the "curse of UIs". Every single surviving project has learned that - Qt, GTK, GDK, WPF, ... as well as big apps like Blender, Unity, ... and other (especially game-oriented) frameworks and studios.

UIs absolutely require first class support for dynamic handling - i.e. not callbacks, not objects with getters/setters, not putting the initial/default UI state into the programmers center view. But focus on data in time - streams (not single events!), continuous changes of data, etc. V UI has yet to reverse its course to become a serious UI framework. But please first finish V itself - as I said and fought for years ago when V got first published: "UI libs are as much work as a general purpose language itself, so make V UI have a strictly lower priority".

[Wajinn]

I totally believe Fyne feels weird for simple or small projects.

We are in agreement.

UIs absolutely require first class support for dynamic handling - i.e. not callbacks, not objects with getters/setters, not putting the initial/default UI state into the programmers center view. But focus on data in time - streams (not single events!), continuous changes of data, etc. V UI has yet to reverse its course to become a serious UI framework. But please first finish V itself - as I said and fought for years ago when V got first published: "UI libs are as much work as a general purpose language itself, so make V UI have a strictly lower priority".

Hmmm... Definitely V is the priority, but I don't think the project can afford to put VUI on the shelf. The competition will only get more fierce. As it is, Go people appear to be "shopping" for suitable and alternative UI frameworks too. And there are older languages with their solutions.

My counter-argument, would be along the lines of usability and being productive, versus perfect. “Don't Let Perfect Be the Enemy of Good” Even if one thinks VUI isn't following the best route, it is a route, to produce cross platform GUI apps. For many this is necessary, and not providing this stated and already given feature of the language, creates numerous issues as well.

A lot of people are not going to sit idly by, and wait years for a cross platform UI solution, if that's what they need. VUI was the right direction to take. As the result of need, people are likely to actively seek out other UI frameworks, or even other languages . Thus, for momentum purposes, it might be better that V has a solution (VUI), than no solution. Fans of a language can tolerate some inconvenience or imperfection, particularly if they feel things will improve later or can be retrofitted, but not necessarily no solution to their problems or something that appears abandoned.

Another thing, is arguably the need for a form creator. I've seen people discussing this as a knock on Go for GUIs, and is something that in no way should be underestimated as well. In talks with various IT and tech professionals that are/were new to programming, it was very interesting what they picked and sought out. For casuals, this can be huge, particularly with RAD or testing of evolving ideas.

[dumblob]

Yes, we are in 100% agreement. Especially because I know >50% of all UIs ever started (not necessarily finished nor maintained) are actually rather demos or very simple UIs. And that counts - specifically it vastly lowers the adoption barrier of the whole V ecosystem.

That is why I did not say "do not stop and wait (until V gets finished or whatsoever)" but "make V UI a strictly lower priority than V itself" 😉.

[Wajinn]

VUI to MIT, was a very good move. VUI, MUI, and Isaiah's UI are making significant progress.

[shove70]

Thanks for your efforts, V has made a lot of progress than a year ago. I have been paying attention to V for some time, but due to the incomplete infrastructure, I neglected it for about a year. Now the news released by 0.3 makes me start to pay attention to it again.

Through the test, I found that 0.3 has been greatly improved in all aspects, and I am also trying to use it in the production environment to build some server-side network applications, some automation tools for operation and maintenance, etc. In the process of trying, I feel constantly blocked, but in issues, the speed of feedback is very fast, the speed of review is also very fast, and the speed of merge is also very timely, which basically allows the work to continue.

But at present, there are problems that prevent me from using V more widely:

1. coroutine, await/async，parallels...

2. The net library is too simple and inflexible, and the network client program is difficult to write simply.

3. VLS is basically unavailable.

Everything will be better! I believe V will be stronger and stronger!

[dumblob]

@shove70 oh, I just noticed you already reacted here 😉. Either way I would like to resurrect the "parallelism and concurrency" discussion in #11608 . So feel free to chime in there. Thanks!

[neimanpinchas]

Any recent update?

If I am starting now a server app in V, can I expect to write here another comment? or if its silant here it means that the subject is already irelevant == everyone decides to use V in production.

[Avey777]

1. There is a lack of permission libraries similar to casbin.

[Avey777]

#23736
@neimanpinchas