←back to thread

My Foray into Vlang

(kristun.dev)
87 points Bogdanp | 2 comments | | HN request time: 0s | source
Show context
torginus ◴[] No.45082970[source]
I am of two minds on V

On one hand, I think there needs to be an applications programming language that's both fast, statically typed, and minimalistic (like C). C# and Java are unwieldy and carry too much baggage. I hoped Go would be that language. Unfortunately Go's weird choice to use green threads and channels made it very difficult and slow to interop with native code, especially desktop frameworks, which usually rely on a pumped message loop. V was supposed to be that language, that keeps the excellent syntax, but replaces much of the weirdness with much more convenient stuff, while adding a few extra features.

I first learned of V after reading the hit piece someone wrote on it, which has formed the majority of people's opinion's on the language. Back then I though most of the criticisms were unnecessarily harsh and belligerent, most of it boiling down to the compiler/stdlib having bugs, and one asserting that it's 'autofree' implementation leaked memory, based on an incorrect understanding of how valgrind and C memory management works.

I decided to get the truth for myself, and delve into the V language source code (after all, it's up on github). Oh boy.

- The 'compiler' itself doesn't seem to have a a codegen backend, it just produces C code, with every code generation call essentially becoming a stringbuilder concat pushing C code into a buffer. So it's more of a transpiler than a compiler.

- The compiler's code is very worrying - commented out snippets of code, TODOs like 'TODO: this isn't supposed to be null here' over a stray if statement

- The vaunted 'autofree' which (to be fair never claimed to be 100% effective, relying on GC for cases it can't figure out) is just checking objects allocated in the function scope, and frees them at the end of scope. (to be fair, autofree seems to have been deprioritised)

https://github.com/vlang/v/blob/master/vlib/v/gen/c/autofree...

While it works in some cases (including the original critical post where it claimed to fail), and I don't pretend to understand all the nuances of the compiler, I feel like the engineering behind this project is somewhat unsound.

It's super impressive just how much stuff they managed to do over the past few years, and I think a simple and pragmatic desktop language (that produces small binaries, has few dependencies and is easy to write and read) is still needed, I'm kinda reluctant to give V that role until the engineering behind it becomes more solid.

replies(2): >>45083361 #>>45084816 #
nine_k ◴[] No.45084816[source]
> an applications programming language that's both fast, statically typed, and minimalistic

While at it, does Zig fit this bill? (Or, haha, Free Pascal / Lazarus, if we talk about desktop software.)

replies(2): >>45085357 #>>45085834 #
thegeekpirate ◴[] No.45085834[source]
Far too complex, Odin (my favorite language for writing apps in) would align more with minimalistic values.

Lazarus always looked good, so there's probably value there if having a GC isn't an issue.

replies(1): >>45087932 #
1. shakow ◴[] No.45087932[source]
Lazarus does not have a GC AFAIK, it's manual-free.
replies(1): >>45088887 #
2. thegeekpirate ◴[] No.45088887[source]
It does seem like they somewhat do now, as of the last several years https://wiki.lazarus.freepascal.org/management_operators

From https://news.ycombinator.com/item?id=19100760 since I'm not a Pascal user:

> The change we're talking about automatically invokes Initialize and Finalize on all types for dynamic allocations / destruction, unless they intentionally circumvent it. Intentional circumvention might include allocating raw memory in a class and treating the class like an array with an index property. In other words, if you declare a raw pointer, allocate untyped memory (e.g. bytes), and handle something back from that memory using a typecast, then you are bypassing automatic allocation and destruction.

> All other ways to make space for complex types (records and classes) as well as types which may hold complex types (arrays and nested fields) will safely and reliably use Initialize and Finalize when needed if they are defined.