vlang1dot0

Yeah, it's absolutely wild. Even the main contributors don't really know what they're talking about, they just regurgitate the party line.

http://imgur.com/a/hUXR6s3

For instance, when asked how the memory management system works, here you see a team member give the standard response: the compiler inserts calls to free when it detects the variable is no longer used. This seems reasonable to anyone who hasn't thought much about PL/compilers before. But when pressed further, you see Alex admit "most stuff is simply cloned ATM" which is in stark contrast to the "autofree handles 90-100% of objects for you" on their homepage.

Or this where Alex shows he has no idea what UB is?

http://imgur.com/a/mbLtASH

UB is a property of the language's abstract machine. Common C UB like dereferencing a null pointer or signed integer overflow has well defined semantics on basically any commodity hardware manufactured in three decades and yet it is still UB not because of the runtime properties but because the C abstract machine says it can't happen and compilers are free to optimize based on that assumption. For a language that compiles to C and claims no UB, the author should have a much better understanding of this.

Most of us also don't splash it all over hn/reddit like it's the second coming of Christ.

Is gitly supposed to be solid code?

Calling this "a really great"web app is a significant stretch. It's an extremely bare bones clone of GitHub. Another case of over promising and under delivering from the V team.

Given that those people are Linux kernel devs, that's great!

Firefox has explicitly used unstable Rust features for years. Their build system opts into this behavior knowing these features are not guaranteed to be stable in future versions. It's 100% unsurprising that using unstable features means your code might break with a future compiler.

Can you explain how a conservative garbage collector solves all leaks?

No reply to the autofree comment? Unsurprising.

Since you want it so much, here you go:

- "No undefined behavior" -> How does V prevent this? V currently can't even generate well formed C code for all valid V so how do you prevent UB in the generated C? As of now, for any reference x in V, *x and ******x are both accepted by the checker. int32.MAX + 1 is instant UB yet V does nothing to prevent this. What is your plan to prevent UB in the generated C?

- Generics -> The example shown in your own docs expresses how "wip" this is (https://github.com/vlang/v/blob/master/doc/docs.md#generics). Why is `T.name` allowed? `T` can be literally anything since there is no constraint on it. You're obviously deferring type checking the function until it's monomorphized which is far more like C++ templates than "generics". How do you plan to deal with template bloat slowing down compilations?

- -usecache -> Another one of the 20% implemented features. This was done to give V a huge boost in compiling simple programs but the implementation is so busted, you yourself disabled it on the benchmarking site.

- "go" keyword -> From your docs: "V's model of concurrency is very similar to Go's. To run foo() concurrently in a different thread, just call it with go foo()". At least you've documented it but have completely buried the lede that unlike Go, `go` spawns an OS thread not a green thread. Speaking of green threads, how do you propose to keep the efficiency you claim ("within 3% of C") while still having transparent C interop? Are you going to use segmented stacks to allow 100,000s+ green threads and then run into the same issues Go has calling into C or are you going to larger stacks to make C interop feasible which limits how many green threads you can run before using enormous amounts of memory?

- "immutable" references -> As shown on Discord, "immutable" references can easily by laundered into mutable ones by assigning the reference to a mutable variable and then assigning into that.

- native backend -> Can handle hello world and programs that use string interpolation. Given that it can't handle the average 100 line V program, you should not be extrapolating the performance of 1,000,000 V programs.*

CoffeeScript was popular until Typescript came along and actually added something useful to JavaScript instead of just changing the syntax.

Who cares? These people seem to care https://twitter.com/v_language/status/1339223357800263682?s=...

Imagine thinking that GitHub stars are indicative of anything at all. You might as well measure popularity by how many times your webpage has been bookmarked.

It's not terribly impressive when the compiler just outputs C and invokes TCC or your platform's compiler to do the actual work. V is far more like a different syntax for C than it is a real language. Perhaps one day that will change but currently V is to C as CoffeeScript is to JavaScript.

Yep. Very telling when no one on the server can explain it and anyone who asks is silenced.

You solved the memory management for one particular program written in exactly the style necessary to avoid leaks for the demo. You'll find as you fix other programs, you'll introduce UAFs into this one which is, I suspect, one reason your commit activity around autofree has basically dropped to 0 recently.

I think it would be more productive to direct the attention to https://github.com/vlang/v/issues/1247 which catalogues a number of issues with the proposed approach and yet hasn't had any activity in 9 months.

The last time I asked about how the memory management would work, the conversation was quickly shut down by a vlang dev (not Alex) who grilled on me on why I wanted to know how the language worked. I've seen this same reaction to other newcomers who dare to ask reasonable questions instead of simply drinking the Kool aide.

He lives in Sweden where the cost of living is quite a bit lower than most of the US and also has people contributing to him on GitHub. A quick Google search suggests it's quite possible to live on $1k a month in Sweden for one person but I admit I have no personal experience in that point.

Edit: I was wrong about the location but that does not change my opinion.

Things have improved but it's not clear the author realizes the magnitude of what he's trying to do.

The big ticket item is the autofree memory management system which promises near C/Rust performance and minimal overhead without the complexity of borrowing and ownership. To date, this system does not work and is "wip" as the vlang community likes to say. There are also no clear explanations of how it works beyond just "it inserts calls to free() when you are no longer using a variable" which is ... extremely obvious. The more interesting question of how the compiler determines something is no longer being used in the face of aliasing and no borrowing system is completely unanswered. No one working on the project understands how complex that problem is. Initially the goal was that this system would manage all memory for the programmer automatically, this goal has since moved to "manage 90% of objects in memory and use GC for the rest". I suspect we will see that number continue to drop as the author realizes this is intractable without whole program analysis (which they can't do and still hit their compilation time targets).

Other items are very much in an alpha state if they work at all. Only in the last month have you been able to create a generic function with more than one type parameter, although V has been claiming support for generics since at least last year. There's still no ability to constrain the type parameter to something that implements an interface/trait/protocol.

C2V, another wildly ambitious project that could literally be a PhD project in automatic language translation, was supposed to be released "this week" 5 weeks ago. It's currently in a very private alpha and no source has been released.

Which is basically the state of most of the author's projects: huge promises in terms of features and performance with most of them little more than demos. I've come to believe this is an intentional strategy by the author to maximize his Patreon revenue. He makes big promises on social media and then delivers the easy 20% of the project to his followers before switching to another project. It would make far more sense to release a finished project before starting another massive one and yet he can't sit down and finish a project because he knows he can't actually deliver what's been promised.

> It has incremental compilation, in-place binary patching, the ability to use code before declaration in a file, compile-time code execution, and extremely low compile times. Rust itself doesn't have most of those.

Rust has all of those except in place binary patching and fast compile times.

Looks like the two main issues were:

1. Some crates in the ecosystem have "extension traits" that add the same method to `f32`. Adding this into std will cause conflicts with those methods so users will need to disambiguate or remove their use of those extension traits. (This is allowed breakage under the stability guidelines)

2. Should this use this two arguments or a range (`x.clamp(1.0, 5.0)` or `x.clamp(1.0..5.0)`)?

I think part of the reason this took so long was that by having widely used crates like `numtools` in the ecosystem that provided this functionality, it took a lot of the pressure off having this in std/core.

> all the while yelling at us old fogies for being old and fogey.

TIL that being 27 makes you an old fogie.

What AAA games exist in C#?

> 0 games have shipped in Rust and there is no plan anytime soon in the future that it will.

That's trivially false.

> Last week, I released A Snake’s Tale on iOS, Android, Windows, Mac, and Linux.

> A Snake’s Tale was programmed entirely in Rust, and to the best of my knowledge, it is the first commercial game made in Rust to be released.

Dated 09 May 2017.

https://michaelfairley.com/blog/i-made-a-game-in-rust/

> Minecraft was written in Java, so that can't be it.

What does that have to do with the parent comment? The usual argument I've seen is that game developers "move too fast", "don't have everything designed ahead of time", "have to iterate quickly" and Rust's insistence on writing correct code gets in the way of that during the prototype phase.

Java doesn't really have that issue as it is quite a bit more forgiving than C++ and will happily let you hammer a square peg into a round hole at the expense of performance, as evidenced by Minecraft.

It's a game not a framework unless I'm completely misreading their website.

The advantage vs some C# library is essentially the advantages of Rust over C#: precise control over memory layout and usage, no GC, higher performance, an ecosystem that was designed to be x-plat from the beginning instead of bolting that on after the fact.

Ah yes, the average citizen will definitely trust that "homomorphic encryption" isn't just some nonsense made up so the election can be rigged.

Rust has had that for a long time as well. This is first-party support from Microsoft for Rust in contrast to community supported options like in D.

As is pretty typical for the V community, there's a lot of amazing features listed on the home page, most of which are "wip" as they like to say or completely unimplemented.

The feature list is aspirational. Maybe one day they'll get there.

What "writing" would that be exactly?

I have tried this before and generally the response to my issues has been "this will be fixed" with no further explanation that would allow having a discussion and thinking through the soundness of the idea of even letting someone other than the author take a stab at implementing it.

Even for critical things like the memory management strategy, no one other than Alex has any idea how it is supposed to work (beyond some references to Lobster). Even when it's pointed out that Lobster makes some concessions that V does not so that the memory management system can work, there is still no discussion.

The V community and team seem far more interested in generating hype and publicity than actually doing the hard parts of language design.

I don't actually think the community is trying to be malicious. If you hang out in their discord, they're generally quite friendly. What they lack is focus.

The language and canonical backends aren't anywhere close to complete and there's already attention bring split to build an x86_64 backend and a wasm backend. Neither of these are anything more than toys even in comparison to the C one. At the same time, std is lacking critical things like a map type that doesn't require your keys to be strings. And yet they're working on a discord client and a websocket implementation. V-os and v-browser are seriously discussed with promises like "we'll start on that after 0.3".

V is sort of the ultimate yack shave. The author wanted to make a thin discord client but first they needed a new text editor so then they needed a language to write it in. It's really only a matter of time before the next project comes up and the author leaves V in the same state as his other projects.