
The V Programming Language - dTal
https://vlang.io/
======
open-paren
I know the launch was mired in controversy, but work has gone on since them.
Christine Dodrill occassionally takes a look at it after writing about it at
launch and I like her updates. Here's[0] her most recent look at the project,
from June

[0]: [https://christine.website/blog/vlang-
update-2020-06-17](https://christine.website/blog/vlang-update-2020-06-17)

~~~
xena
Author of that post here in case you have any questions, ask me anything!

~~~
gavinray
Wow, it makes me sad to hear they had retaliated in this way.

You're one of the most knowledgeable people I've seen, with a consistently
incredible blog I've learned so much from.

At the end of the day, it's an experimental language that (I thought) was fun
to mess around with. Not a very kosher way to respond to factual criticism.

~~~
xena
Thanks, I try.

The last article had to be edited down because as it was written initially
(see the git history of
[https://github.com/Xe/site](https://github.com/Xe/site)) it made the V cult
come after me. This among other things is why I do not plan to write about V
in the future.

~~~
whycombagator
> The last article had to be edited down...see the git history

For anyone interested:

[https://github.com/Xe/site/pull/167/commits/354c6079acc2d02a...](https://github.com/Xe/site/pull/167/commits/354c6079acc2d02a95647c637065f0539bca4787)

------
non-entity
So if I recall correctly? when this language was first announced there was
some strange controversy about it mostly being vaporware and serious claims
being made about the language and its performance before they were
implemented.

I assume this has mostly changed now? Has anyone tried using it recently?

~~~
burlesona
I think when V was first announced (and to a lesser degree still today) it was
really hard to tell the difference between the things the author had actually
running and what was only “the vision.”

For example, V compiles to C super fast. Then you compile the C code at normal
C compilation speed. Very logical design so no complaints there, but the
original claims made it sound like it went straight from V to machine code in
a blink, which isn’t exactly true.

However I will say that the project has been very active, the author has made
his claims a lot more clear, and so far he’s delivering on his promises little
by little.

If I were to summarize my experience testing out V, I would say the author
looked around at the world of software engineering and said, “there are lots
of good pieces out there, but what I want is one language + Stdlib that does
absolutely everything, and what the hell, I’m just going to make it myself.”

It’s super ambitious, but it’s also pretty neat.

~~~
throwaway894345
I wonder what are the tradeoffs between targeting C and targeting LLVM/LLIR?
Is it mostly "I know C"? Given that LLVM is purpose-built for this kind of use
case, I would expect that it would be the better target, but I'm not very
knowledgeable on the subject.

~~~
higerordermap
Can use any compiler. (GCC sometimes optimizes better than LLVM, GCC has more
platform support, TCC can be used for faster compilation).

LLVM interface is unstable.

That said there are things you can't properly implement by compiling to C.

~~~
posix_me_less
> there are things you can't properly implement by compiling to C

Very interesting claim, any examples?

~~~
aweinstock
If your source language has some construct that you want to express as state
machines (e.g. async, CPS, pattern match compilation), and you want to compile
the state machine as direct threaded code[0] (which involves fewer branches
than a while-switch), then if you're compiling to C, you need computed
gotos[1], which are non-standard.

[0]:
[https://en.wikipedia.org/wiki/Threaded_code#Direct_threading](https://en.wikipedia.org/wiki/Threaded_code#Direct_threading)
[1]: [https://gcc.gnu.org/onlinedocs/gcc/Labels-as-
Values.html](https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html)

~~~
mratsim
GCC, Clang, ICC do support computed gotos and you can fallback to ``while
true`` loop + switch dispatch for others.

This is what Nim does: [https://nim-lang.org/docs/manual.html#pragmas-
computedgoto-p...](https://nim-lang.org/docs/manual.html#pragmas-computedgoto-
pragma)

------
gavinray
Want to comment as someone who has written small amounts of code in V and
followed it since near it's inception:

V is essentially a much cleaner version of Go, syntactically. Though it adds
many features that turn it into one of the nicest (IMO) languages to write.

It adds:

    
    
        - Hot reloading, on a compiled language (WOW)
        - Pattern matching/match statements
        - Option/Sum types
        - A really clean approach to handling Maybe results that I haven't seen in other languages before -- EDIT: I take it back, apparently my own ignorance here
        - Generics
        - C interop and compile/build integration that's incredibly easy
    

Some of my favorite bits:

    
    
        // Error-catch + propagation on Maybe's with "?"
        fn f(url string) ?string {
            resp := http.get(url) ?
            return resp.text
        }
        
        // Identical to this -- Option types must be handled with "or" if not "?"
        resp := http.get(url) or {
            return error(err)
        }
        return resp.text
    
    
        number := 2
        s := match number {
            1    { 'one' }
            2    { 'two' }
            else { 'many'}
        }
     

Additionally, the devs/community on Discord are really friendly, and they
spent an hour helping me compile Facebook's reference C++ GraphQL parser
library, and interop with the C API from V. I'd never touched low-level stuff
before and the experience was a blast.

This was all it took (minus figuring out the C++ build process):

    
    
        // app.v
        #flag -I libgraphqlparser_compiled
        #flag -L /home/user/Projects/vlang-graphql/libgraphqlparser_compiled
        #flag -l graphqlparser
        #include <GraphQLParser.h>
        #include <GraphQLAstToJSON.h>
    
        struct C.GraphQLAstNode{}
    
        fn C.graphql_parse_string(text charptr, error &charptr)  &C.GraphQLAstNode
        fn C.graphql_ast_to_json(node &C.GraphQLAstNode) byteptr
    
        node := C.graphql_parse_string("query MyQuery { id email }", "Failed to decode")
        json_str := cstring_to_vstring(C.graphql_ast_to_json(node))
        println(json_str)
     
    

And because the primary compilation target atm is C, performance is generally
screaming fast.

\---

Edit: Want to clarify it's still experimental. As a concept/language, I found
it fun.

See Christine Dodrill's negative experience and valid criticisms below for the
other side of this coin.

~~~
david2ndaccount
Hot reloading in a compiled language is not that difficult - you just
dlclose/dlopen/dlsym the shared library when it changes.

~~~
lightgreen
But making sure program won't crash after reloading (e. g. because of memory
layout or invariants change) is much harder, and I doubt V prevents these
failures.

~~~
delian66
It does not. The reloaded program can crash.

It is very useful for tweaking code, but if you make more substantial changes
to your state, currently hot code reload will not help you, and you may be
better of just restarting your app.

------
gridlockd
The problem with V is the habit of intellectual dishonesty surrounding it.

Take this chart, showing the selling point of "fast compilation times":

    
    
                    Space required  Build time
        Go          525 MB          1m 33s
        Rust        30 GB           45m
        GCC         8 GB            50m
        Clang       90 GB           60m
        Swift       70 GB           90m
        V           < 2 MB          <1s
    

All of these programs native compilers of complex languages, supporting
multiple architectures. V is a _frontend_ for a C compiler, which is likely
GCC or Clang. It doesn't even belong in the comparison.

The fact that building Clang/LLVM takes 90GB of disk space is of course a sign
of the impending collapse of human civilization, but I digress.

~~~
rkeene2
I'm not sure where they got that number, but my LLVM 8.0.0 install (relatively
complete, including Clang, etc) is 1.7GiB.

~~~
delian66
See for example:
[https://news.ycombinator.com/item?id=23139396](https://news.ycombinator.com/item?id=23139396)

------
merricksb
If curious, see previous discussions:

[https://news.ycombinator.com/item?id=19403271](https://news.ycombinator.com/item?id=19403271)
(191 points / Mar 15, 2019 / 182 comments)

[https://news.ycombinator.com/item?id=19526924](https://news.ycombinator.com/item?id=19526924)
(61 points / Mar 30, 2019 / 101 comments)

[https://news.ycombinator.com/item?id=20229632](https://news.ycombinator.com/item?id=20229632)
(146 points/ June 20, 2019 / 137 comments)

~~~
dang
Also

[https://news.ycombinator.com/item?id=21296855](https://news.ycombinator.com/item?id=21296855)

[https://news.ycombinator.com/item?id=20250990](https://news.ycombinator.com/item?id=20250990)

[https://news.ycombinator.com/item?id=20258485](https://news.ycombinator.com/item?id=20258485)

------
smartmic
It's still strange. What about Github stars? Either the HN crowd is very
biased or we have been ignorant or V enthusiasts do not show up here often.
Most of the latest system programming language discussions and post here
revolve around Rust, C, Go with some sympathy for Nim, Zig, Crystal and
others.

A quick lookup on star ranking gives surprising results for V: * Go 76.5k *
Rust 48.2k * V 18.5k (??) * Crystal 15.2k * Nim 9.9k * Zig 6.6k

~~~
Jtsummers
V got a lot of hype last year, and then a lot more criticism here on HN. I
suspect that's a reason it's not been promoted much on this site. People who
saw it coming out last year (like me) mostly ignore it, and the people
interested in it found other places to discuss it without the criticism.

------
runeblaze
I always have this feeling that the author of V just does not really know how
to properly write a compiler. imho he just always hacks something up without
properly learning the craft, which frequently results in some monstrosity that
at first does not quite work and gets slowly patched to the real thing (e.g.
the parser). This is very annoying because sometimes the real thing is quite
easy (or a solved problem) but the V compiler just seems to fail at it.

~~~
leafboi
How would you properly learn this craft? What resources would you recommend or
look into?

~~~
andoriyu
Dragon Book probably still valuable resource.

~~~
forgotpwd16
It should be noted though that Dragon is very detailed especially on parsing.
Thus some consider it a bad introductory book and/or even outdated. But it's
good resource if you want to become better and parsing is just a part of the
book.

------
hardwaregeek
I'm not sure I like how V seems to claim to be better across so many
dimensions. Language development is all about tradeoffs. You can have good
static analysis or fast compilation, not both. If you look at most successful
languages, they don't claim to be a silver bullet. Rust doesn't claim that it
compiles quickly. Go doesn't claim to have the best type system. Python isn't
the fastest language.

I'm curious to see how V ends up. It's unlikely that it'll succeed at
everything, so eventually it'll choose a niche. And backtrack/sweep under the
rug the claims that don't fit in said niche.

~~~
delian66
V is not a silver bullet either. No language is. V values highly fast
compilation times, and does not claim to have the best type system, similar to
Go.

~~~
vlang1dot0
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.

------
macintux
Very interesting, the list of improvements over Go address a lot of complaints
I have about the language.

Taken from [https://vlang.io/compare#go](https://vlang.io/compare#go)

\- No global state

\- No null

\- No undefined values

\- No err != nil checks (replaced by option types)

\- Immutability by default

------
azhenley
If I remember correctly, there was a lot of controversy, partially because of
the amount of donations being elicited before releasing anything and
overselling some benchmark results.

Looking at the repo, it looks like there is a ton of effort going on. 6458
commits and 687 open issues. Seems promising?

[https://github.com/vlang/v](https://github.com/vlang/v)

------
forgotpwd16
So how well it has ended up holding on its promises/claims? When was initially
released (previous year?) there was a backlash, and checking the source there
were some bad points but it seems it has now improved considerably.

------
bartq
It really reminds me of Jai programming language by Jonathan Blow. Just
downloaded and started testing it, looks promising! Is its main use case for
now the games development?

~~~
delian66
It is a general purpose language, but there are several games in the main V
repo, for example:

[https://github.com/vlang/v/blob/master/examples/tetris/tetri...](https://github.com/vlang/v/blob/master/examples/tetris/tetris.v)

[https://github.com/vlang/v/blob/master/examples/2048/2048.v](https://github.com/vlang/v/blob/master/examples/2048/2048.v)

You can try them with: `./v run examples/tetris/tetris.v` and

`./v run examples/2048/2048.v`

They work the same on Linux, Windows and MacOS.

------
javier10e6
It lost me from the main page example. How about...

fn main() { areas := ['game', 'web', 'tools', 'science', 'systems',
'embedded', 'drivers', 'GUI', 'mobile'] areas.each_with_index i {
println('Hello, '\+ ' areas[i] ' \+ developers!') } } for loops should not
exist because they they are external to the an object reflection attributes.

------
christiansakai
Looks really neat! What's the catch here?

~~~
oconnor663
One catch is that it's not currently memory safe, and it's unclear (to me)
what the future plan is for memory safety.

------
perfunctory
> No variable shadowing

too bad.

