vlang1dot0

You're right but at the same time people also need to evaluate the state of the language with respect to the claims made on the home page.

- autofree not only leaks memory but in some cases causes double frees or use after free resulting in UB. Look at issues tagged autofree on their repo.

- No UB is claimed but the compiler does nothing to stop you from doing it and V is a very thin layer on top of C so it's trivial to cause UB. Signed integer overflow in V: instant UB.

- hot code reloading literally just overwrites the library in memory as the application is running. Better hope your compiler laid everything out exactly the same way or it will segfault and it usually does.

- Generics. Only one type argument is supported. The built in std types don't even use them because the implementation is so broken.

- option types: why have Some(T) | None when you can mix error handling in too and have Some(T) | None | Error(E)? That's right, option types three values. (Tri-state booleans anyone?)

- Compilation speed: V translates to C and then runs a C compiler. V isn't going to compile any faster than your C will. The only reasons that it's pretty fast right now are because most programs are very small and so is the std library and because they use tcc which performs no optimizations at all. If you want your C code to compile as fast as V does, just use tcc.

- Runtime speed: No rigorous benchmarks have been done. The claim of within 3% is a goal they have no idea how to achieve. Given their memory system relies on ref counting and optimizing out increments and decrements, they won't be able to hit that only taking memory management into account. Other design aspects have serious implications in terms of performance such as array copying being implicit. (b = a) copies all of a into a new array.

This is fine for a learning experience and I hope everyone involved is learning a lot but pitching this as some kind of project that people should learn and write real code in is crazy.

Bootstrapping the compiler isn't a sign of language maturity. V has changed pretty significantly both in terms of syntax as well as semantics since that release.

Regarding compile times, why do you claim less than one second when your own tracking shows 2.5 seconds and trending upwards? (fast.vlang.io) Aren't you concerned that as the compiler and language are actually implemented, compile times will continue to worsen? Have you considered that perhaps that's why there are so few languages that claim that kind of bootstrap time?

I think having actual documentation about how the memory system is supposed to work would do a lot more to answer questions than linking to the tests.

For example:

x = [1, 2, 3] // is this stack or heap allocated?

foo(&x) // how does the compiler know if x needs to be ref counted or not?

return &x // is this valid or UB or a compilation error?

All memory leaks in C are one line of code away as well (calling free() in some place).

Ok but then the author should not be claiming that.

The problem with V is that the author makes astounding claims and when people push back on that even slightly they get harassed. Even your comment nit-picks mine over technicalities while ignoring the obvious issues with the author's.

Given how many of the "features" of V are completely unimplemented or only work in the most narrow of edge cases, it's not clear to me why so much grace is extended to the author who's generally been unable to deliver his promises all while collecting a tidy sum on patreon.

Even garbage collected languages do not prevent leaking memory because doing so requires understanding programmer intent. For example, adding objects to a static hash map and never using them is a memory leak that no GC will fix.

V has the same issue and autofree will not be able to fix it.

Reference counting is also necessary even in entirely single threaded programs to handle some situations.

It's concerning you state things that are categorically false with such certainty.

Ah yes, you're totally right. I didn't realize there was quite a bit of additional content "below the fold" on that page.

Reading the Media Guidelines, I don't see how you came to that conclusion:

> TL;DR: Most non-commercial uses of the Rust/Cargo names and logos are allowed and do not require permission; most commercial uses require permission. In either case, the most important rule is that uses of the trademarks cannot appear official or imply any endorsement by the Rust project.

https://www.rust-lang.org/policies/media-guide

I don't really agree. The vast majority of applications are fine being written in whatever flavor of high-level, garbage collected, memory safe language you want. There are many nice options with pretty much any set of feature and style choices you could want.

The rest of these applications have either hard realtime or hard performance requirements or both. What I don't see in these apps, is for memory safety issues to be 'ok'.* It's 2020, using a memory safe language should be table stakes for new projects at this point.

----------

* The one exception I can think of is single player video games where the worst that can happen is basically just a crash to desktop. Multiplayer games are a different story especially with the trend toward paid DLC where these kinds of issues could result in anything from exploits in multiplayer matches (hurting the community and thus the game overall) or players circumventing DLC restrictions (resulting in a loss of profit).

dotnet and Rust are essentially neck and neck on plain text. On any benchmark that actually does work though, dotnet is nowhere to be found (less than half the performance of actix).

Apologies but as your comment currently stands, it reads to me like "in theory yes, but actually no".

LLVM has nothing to do with `const` evaluation in Rust. `const` evaluation happens at the MIR level which participates in incremental compilation.

Who outside of Microsoft is going to have experience with the Windows build system?

Is this like recruiters looking for 20 years of Go experience lol?

> These kinds of “wacky types” are things you can statically analyze but not really “compile” per se. That’s why it’s a good fit for being transpiled down to a language with no types at all.

> TL;DR, TypeScript is not really a “typed programming language”, it’s a static analysis tool. It’s not really designed to “run”.

I think you have an interesting point but you've come to the wrong conclusion. Assembly language doesn't really have any notion of types (there is some notion of sizes as some instructions operate on, for example, single words and some instructions like SIMD ones operate on multiple words at a time) yet we still consider C, C++, Rust, Pascal, etc to be "typed programming languages". It's really only languages that compile to some kind of VM which have a notion of types at the runtime level and even then, many VMs erase some of those details like the JVM and generics.

>> Nexus was a reasonably priced unlocked reference phone targeted to Power Users

Nexus One: $530 Nexus S: $530 Galaxy Nexus: $200 with standard 2 year contract (basically the same as any flagship phone at that time) Nexus 4: $300 Nexus 5: $350 Nexus 6: $650 Nexus 6p: $500 Nexus 5x: $379

Arguably Nexus 4 & 5 were the odd ones out with their relatively low pricing. The others (excluding the 5x) were pretty much on part with flagship phone prices at launch time.

My point still stands: is this UB or not?

    foo := charptr(0)
    x := *foo 

The "wasm" playground generates no compiler errors or warnings. In fact, the compiler seems happy to accept any number of dereferences as this

    foo := charptr(0)
    x := **********foo

compiles without error.

Yes, please continue unraveling this "Scooby Doo mystery", I'm sure it will be entertaining for everyone!

Do you think there's a coordinated campaign by(?) Coverity to get your open source project to use it? For what reason? It's surely not to make money considering Coverity gives open source projects a free license.

> I have nothing against Coverity personally - it may very well help the V code generator, but I hate being forced to use a product in such a way.

Yes, two random people telling you to consider using a static analysis tool is "forcing" you to use a product.

----

This is a great example why everyone should stay away from V. Industry standard best practices are treated as conspiracy theories by the developers.

It's fine for people to decide they want to make a new language; that's great! It's also totally fine for all of those people to have no idea what they're doing; that's how you learn. But at some point, you need to recognize that you don't know what you don't know. V is not anywhere close to the level of production ready-ness you yourself have repeatedly claimed.

The problem is that V claims:

- As fast as C - No manual memory management - No GC - Memory safety - Not hard like Rust

You have fundamentally conflicting requirements. Saying "we'll do it like lobster" does not solve that. Lobster is essentially region based memory management with fallbacks to reference counting at runtime. That fundamentally contradicts "as fast as C". You cannot do more work than C at runtime and still be faster.

Lobster is also a different language which had to forgo a number of features V has already embraced. It's unclear how that can be rectified.

> regarding lobster memory management:

> the scope of anonymous functions cannot outlive variables' scope they reference, however V plans full closure support

> lobster compiles whole codebase at once (so it can properly track data flow across module boundaries), however V plans incremental compilation support

> both points are direct consequence of lobster's choice for memory management, ie solving them would mean moving away from lobster's strategy as far as I undersand

https://github.com/vlang/v/issues/1247

Lobster's approach at least has some theoretical rigorousness to it. What V is doing is quite different both in terms of the implementation and the requirements from the language itself and they have never been shown how their version is sound.

There are certainly some good reasons to use C as your backend, but there are some huge downsides as well. The main one in my mind is that you're limited by restrictions placed on you by the target language. V claims no UB but C has lots of UB so extreme care must be taken while doing code generation not to run afoul of C's rules. A quick glance at V's issue tracker shows that is not the case. Nor does there seem to be any plan for solving this.

Other points in that document are frankly baloney:

- Writing programs that pass -Wall -pedantic, Clang analyzer, PVS, and result in zero Valgrind warnings/errors is a dream of any C/C++ developer. With V it's going to be guaranteed for every V program. (We are not there yet, but very close.)

Clang analyzer is not integrated at all so this is not "very close".

Valgrind tests are mostly disabled (especially with -autofree), this is baloney.

Author has yet to set up PVS or Coverity although it was suggested a few days ago on Discord. Again, baloney.

`-Wall -pedantic` Given V can't even compile valid V programs consistently without generating C _errors_ I find this extremely difficult to believe.

> Stability. New languages using LLVM directly are going to crash often. That's inevitable, and can be seen across all new languages using LLVM. The V compiler hasn't crashed once for me, and I haven't received any crash reports from other users.

V issue tracker has lots of instances of the V compiler crashing. "I haven't received any crash reports from other users" is a verifiable fabrication. ([1](https://github.com/vlang/v/issues/6310), [2](https://github.com/vlang/v/issues/6263), [3](https://github.com/vlang/v/issues/4730))

> Simplicity. LLVM is a huge C++ dependency, meaning that both developers of the language and the users are forced to install it. Calling C++ is not easy from V/C, so C wrappers have to be used, increasing the number of dependencies and complexities.

But you need a C compiler. `v -o` requires either clang (and thus LLVM) or GCC both of which are massive dependencies. This logic rings hollow.

> 1. Option/Result are unified into a single type, ?T.

This is not a positive. Option<T> and Result<T, E> have semantically different meanings. This is like saying integers and strings have been unified into a single type: string.

It's not about the author being a CS major or how the parser is implemented. It's about the author being completely wrong and unwilling to admit it ("parsers are why compilers are slow" -> v 0.2 gets a parser) and being completely ignorant of the basics of writing a compiler.

My generous side says this might just be a language or communication issue but my cynical side says $900 a month on Patreon has a lot to do with it.

However, my pet peeves with the project basically just boil down to the half-truths or outright lies on the home page:

> No null

From their own docs: https://github.com/vlang/v/blob/master/doc/docs.md#calling-c...

we see

    error_msg := charptr(0)

and a use 5 lines later with no "unsafe" or other escape hatches in sight. Looks to me like you have null, you just don't have a keyword for it.

> No undefined behavior

What's the behavior of

    error_msg := charptr(0)
    *error_msg

How are they guaranteeing no UB? The compiler works by generating C via string concatenation. Where does the compiler validate the C generated is free of UB? If it's true via construction, then how do basic issues like [this](https://github.com/vlang/v/issues/6290) [keep](https://github.com/vlang/v/issues/5912) [happening](https://github.com/vlang/v/issues/6206)?

> Pure functions by default

https://github.com/vlang/v/blob/master/doc/docs.md#pure-func...

    https://github.com/vlang/v/blob/master/doc/docs.md#pure-functions-by-default

You're telling me I can read a file off disk in a "pure" function? Wat?

> Generics

Generics only work if there's 0 or 1 type parameters. Support for generics in general is "alpha" quality at best. [Lots of correct code just segfaults the compiler](https://github.com/vlang/v/issues/6263). (If the language has no UB and has bounds checking, why does the compiler seg fault?)

Array.map and Array.filter are not regular library functions with a generic type, they're special cased in the compiler with special syntax.

> V is written in V and compiles itself in under a second.

That's not what fast.vlang.io says: 2080ms.

They could just say that it compiles very fast and link to their benchmark site.

I'm not even going to touch the "no dependencies" claim when you need a C compiler (and often two if you want optimizations).

> C translation (wip)

WIP is overly generous. A very broken version of c2v was released for v0.1 and never updated for v0.2.

> V can emit (human readable) C, so you get the great platform support and optimization of GCC and Clang.

Hopefully you consider C files over 100,000 lines to be readable.

> Powerful built-in web framework > Built-in ORM

Maybe focus should be spent instead on completing the memory management story which is still a TODO item?

[The author doesn't seem to even understand what he's trying to do.](https://github.com/vlang/v/issues/1247#issuecomment-51346731...)

When asked what the plan is there, all the community says is that it will be similar to Lobster's (searching "Lobster" on their Discord will show numerous results). However when the reasons why that can't work with V as is currently exists are pointed out, [there is silence](https://github.com/vlang/v/issues/1247#issuecomment-68018256...). Meanwhile, V has already [promised no breaking changes for at least 5 or 10 years](https://github.com/vlang/v#stability-guarantee-and-future-ch...). Perhaps that should have been done after deciding how memory management would work?

You'd think this would be pretty much the top priority at the moment but the handful of buggy commits say otherwise:

- https://github.com/vlang/v/commit/bffa100aa6fbf4842aa6b4f442...

- https://github.com/vlang/v/commit/db51ee08ea269b17bec97fb102...

- https://github.com/vlang/v/commit/b74c1805d72df8fd6e30cc236a...

- https://github.com/vlang/v/commit/e0d20eadff113b3f36fb96226b...

If look closely, you'll see lots of code under the "autofree" path is commented out. I guess you can't have use after free if you never free?

You'll also notice the author has a consistent pattern of committing commented out code, uncommenting it in a later commit and then recommenting it again because it never worked in the first place. This is probably why the author refuses to go use the PR process for themselves and instead pushes directly to master often breaking CI and the project for everyone else.

The problem with V in my opinion is not that it has high aspirations, it's that doesn't distinguish between aspirations and the mostly unimplemented barely functioning reality of the present. Only the happiest of happy paths currently work which is probably only 10% of the effort required to make a serious programming language. You'd think from their website and their fanatics that they're nearly there when they have yet to even realize how much work hasn't even been started yet.