Hacker News new | past | comments | ask | show | jobs | submit login
V Programming Language (vlang.io)
191 points by rayascott 37 days ago | hide | past | web | favorite | 181 comments

I love looking at new languages. People invent really creative stuff. However, my exploration usually ends with "this is great, but there are no libraries for it, so I probably won't use it".

If you are building a language, starting from scratch is the epitome of Not Invented Here syndrome. Build it on top of an existing ecosystem. Look at Elixir and how it builds on Erlang and interoperates with it just perfectly. Or look Groovy, Scala and Clojure to see what kind of range you can get from a single platform. With the exception of Go, every language that has become popular in the past 10 years, built on something else.

> With the exception of Go, every language that has become popular in the past 10 years, built on something else.

And Go probably wouldn't have half the range it enjoys today without the massive reach and coffers of Google. That's not a snark, or a critique even, just a reflection of the difficulty of breaking through in this space and indeed a comment to support your assertion that in order to succeed in this space today you probably have to build on or successfully interoperate with an already established platform.

If Go didn't have the backing of Google, I doubt it'd have half the audience it enjoys today; Rob Pike notwithstanding. Case in point: Plan 9.

Not everyone is motivated by success. Grigori Perelman?

IMO people interested in success should be suspect. It’s weird to me that people would go through life seeking attention for invention that will not last much beyond their death.

If anyone here believes their efforts at even a Google size company are forever: 80% of the companies listed as Fortune 500 firms do not exist anymore.

Other than a few key discoveries, for a variety of reasons, none of the work at those firms is considered of value.

> Not everyone is motivated by success. Grigori Perelman?

I don't see how he wasn't motivated by success. He wasn't solving recreational math puzzles.

True, his definition of success didn't include money or prestigious prizes. Still, proving a great and long-standing theorem is a way greater accomplishment than becoming a millionaire.

>IMO people interested in success should be suspect. It’s weird to me that people would go through life seeking attention for invention that will not last much beyond their death.

Err, the attention and success can help them get money, funding for their projects, and other niceties much before their death, so there's that.

Plan 9 is a little different because it's harder to flitter between operating systems than it is programming languages.

That said, I'm not discounting what you're saying about Go's popularity either.

My point with mentioning Plan 9 was that even with luminaries such as Rob Pike, success is not guaranteed. Having a huge organization backing you doesn’t hurt. (Ok, granted, plan 9 had bell labs but I posit a research arm is altogether different from the commercial entity that is google.)

It's interesting you bring Plan 9 up, because it was closed source for a long time, who knows if it was long enough to kill interest. Probably another factor for success.

I got that. I was saying there were a lot of other mitigating circumstances that contributed towards Plan 9’s lack of success that would be specific to Plan 9 and thus not relevant to general purpose programming languages. So it’s not really a great example.

I do think your general point does have merit and the computer industry is littered with examples of great languages that have either failed to gain traction or just fallen out of favour for whatever reason.

I think what the OP meant was “cases in point: Alef & Limbo”. (These were languages that were introduced with Plan 9 and its successor Inferno, that didn’t catch on.)

point: utf8 (unicode)

Except that's your specific attitude towards language adoption. And while it's a perfectly reasonable stance, there's plenty of people who see a language with no libraries and see an opportunity to build their own. Every language ecosystem has to start somewhere.

Also, Rust started in the last 10 years and wasn't built on anything. Unless you count LLVM?

One of the main things that attracts me to non-mainstream languages is that they offer a chance to build some of the kinds of things I like to build for fun, without a bunch of killjoys nagging me about how $language already has $library.

Granted, there are still killjoys who want to nag about how $language isn't on the TIOBE index, but they're usually easier to ignore.

It looks like V is built on top of the biggest ecosystem of them all: C.

From the page comparing to other languages, they claim "Zero cost C interop".

Yet I've skimmed the entire site and nowhere do I see mentioned how to use C libraries in V.

I don't have to convert C to V and then compile the entire V program, do I?

I doubt it, but it's hard to tell. More will become clear once they've actually released the langauge - as it is, this whole website seems super premature, since neither the language itself nor the source code to any real software written in it are available for public consumption.

The documentation that exists is minimalist enough that I would be very careful about assuming it represents a complete representation of the language's features.

Good point, I'll add an example.

It's just `C.puts('hello')`

How do you include the header with puts though?

#include <stdlib.h>

fn main() { C.puts('hello') }

This is an important point.

amedvednikov is the author.

It is hard to interpret it. The V compiler parses C?

To offer a counterpoint, I basically entirely disagree with your opinion but maybe we have different ideas of using something.

Most libraries aren’t really that useful in the long term (although the most-used are). Typically they will not do quite what you want or they will do more than you need and therefore what you want will be mixed up with a lot of other things you need to specify. In cases where a perfect library already exists for your thing there is a reasonable chance that your thing already exists, and otherwise just use whatever language the library is in.

Now there are some libraries but I claim that basically everything else you can get away without and just do it yourself only adding things as you need them. E.g:

libc type library is quite fundamental. Likely a lot of the basic stuff already exists. So long as you have an ok ffi it should be easy to add any missing calls.

HTTP client. This is likely to exist but also not super hard to implement. One can also skip this and ffi/shell out to curl.

Json parser. Again likely to exist and quite easy to implement.

Data structures. Likely to somewhat exist although anything missing that you want may be a bit annoying to add. Typically I think most projects don’t hinge on exactly the right exotic data structure, and if they do then they should be implementing that themselves.

E.g. yaml parser. Less likely to exist and annoying to implement but you can just use some existing program to convert to json first and then easy.

E.g. bindings for your favourite C drawing library. Probably don’t exist but hopefully there is an ffi so just do it yourself.

Libraries aren’t really very special and rolling one’s own isn’t hard. And even if you refuse that, you can just write part of your project as a simple unix process and call that from your python script with all the libraries you want.

Personally I see the lack of libraries as an opportunity to not search around for libraries or try to work out how they can go wrong or be forced to do things a certain way. Especially if the language is novel, it probably isn’t really clear how such a library should be structured. E.g. the reason that rust doesn’t have a canonical gui library isn’t that there are no libraries or no one is trying or no libraries exist but rather that the community in general are still trying out different approaches trying to find something that fits the language well. On the other hand the OP mentions the existence of a widget library for V already.

Http clients and Json parsers aren't great examples because both should be about as fast as you can make them. Idk about you but I don't find it credible to claim writing your own http library or Json parser is a reasonable route to go down in most cases. Not to mention the opportunity cost of reinventing those wheels would be quite large.

Especially considering HTTP 2 is an entirely different beast, which means it's more or less another library.

Well, those kind of types can always stick to the popular and safe languages...

The importance of libraries turns largely on how powerful the language is. For a weak language like Java or C, it takes a lot of library to be much help.

A more powerful language like C++, Rust, or Haskell can capture much more semantics in a library. This builds on itself, so that spending time optimizing a library is worthwhile if the library starts out more useful. Putting more work into a library benefits every user if the library can absorb the extra work.

Obligate-GC cuts library authors off at the knees, so otherwise powerful GC languages tend not to collect libraries.

TypeScript is a good example of a language that received widespread adoption due to its ease of integration with regular JavaScript.

Another lesser-known example is ReasonML [0], which is supposed to integrate really well with JavaScript and OCaml. Based on my experience, it's still young with plenty of rough edges but it's very promising.

[0] https://reasonml.github.io/

>If you are building a language, starting from scratch is the epitome of Not Invented Here syndrome.

And there's nothing wrong with that.

Depends on whether you want the language to be used.

I've never seen a language being used or not used because it reused some other ecosystem.

It might have worked for Clojure and Scala, but didn't get tons of other JVM targeting languages very far.

And inversely, C, C++, Java, Python, Perl, Go, Rust etc succeeded by themselves.

I would argue that Kotlin (https://kotlinlang.org) is an exception to this rule.

It’s extremely popular and I could foresee it eclipsing new Java projects going forward.

Kotlin hit the sweet spot between the abtrusity of Scala and the sloppiness of Apache Groovy.

Re-used an ecosystem? Perhaps not. But the breadth of the library is a big deal for language usability. The easy way to get a big library is to steal an existing one.

Java and Go didn't take that route, because they had corporations behind them that could put a lot of people on writing a solid, broad library fairly quickly. When C came out, the standards were a lot lower - a few people wrote the library that they wanted. Same with Perl. (CPAN is an amazing organic achievement, but it took time to develop.) When C++ started, it just used C's library. I don't know about Python.

Rust is the exception to my reading of this, but even Rust had a large organization, even if it wasn't a corporation. So I think the rules are be early, so standards are lower; have a big organization write a big library at the beginning; or use an existing library to get off the ground.

>* The easy way to get a big library is to steal an existing one.*

Doesn't that always lead to compromises in the language design (to easily link to the old language) and sub-par non-idiomatic libraries?

Probably at least to some degree, yes.

But there are different degrees. C++ had "extern C", which is not much. Java, get the same ability, had JNI, which is gouge-your-eyeballs-out ugly.

A language can probably survive having something like "extern C" to be able to get to the libraries. But if JNI were the way to get to the standard library, it probably would have killed Java.

It's interesting that you chose Elixir, Groovy, Scala, and Clojure as examplars - they seem like failures from an adoption standpoint.

Go, your exception, is by far the most successful of the languages listed.

That's not true. According to the Redmonk rankings, Scala is slightly more popular (based on GitHub and Stack Overflow) than Go. They are both solidly tier 2 languages. Groovy and Clojure are tier 3 languages. Elixir is about as popular as Fortran or Ocaml, which is not bad, but kinda niche.

That lacks the context of their age.

Go is 10 years old, scala is 16 - 60% older, and it was built on top of the JVM, which is much older than that.

I feel like that's worth mentioning, because it seems like Go has more momentum - maybe there's data that shows otherwise though, like trends in Redmonk over time. I had a quick look and didn't see an easy way to get that. I'd be happy to be proven wrong, it's just the impression I get.

And Go put a lot of effort into the standard library by the looks of it.

The initial library was very based on Plan 9 and Inferno libraries. It was far of being a direct port (not even a derived work strictly speaking), but it certainly took a lot of inspiration.

Would love a modern programming language that compiles to Go and can call Go libraries...

That would be a sign of maturity in the Go ecosystem if a whole new language could be built on top of it - perhaps one that isn't C-like/Go-like at all.

The very first and ancient version of V was compiling to Go :)

I think this can be an option in the future. The language is simple enough.

All I know is that such language would first be called “Go with classes,” then “Go++.”

I started a project called Go++ which was exactly this lol

*Go with templates

I’ve been working on a language that builds on top of Go for this exact reason. I want to use the existing ecosystem.

But a lot of people have been telling me it isn’t a “real” language and that I need to target either C or LLVM. Can’t please everyone, I suppose.

I think that is a great idea. something like typescript? Do you have a repo you can share?

This compiles to C, which (I think) means it should be able to FFI to it fairly easily?

Yes, calling C functions is as simple as C.puts('hello world')

Ah, cool, so effectively the standard library is huge :).

Question though; I'm assuming that if you're touching C, there's no extra protection added by V, right? The C will be just as unsafe as it was before, or do you add some kind of exception handling thing around it?

Where did you get an idea that the language has exceptions?

Looks like they just have a way to return errors if you use question mark at the end of function declaration. See "Option types" here https://vlang.io/docs

Sorry, that's kind of what I meant, though I realize I made a mistake in how I said it.

No extra protection right now. You have to handle error codes.

Strings are simple: 'hello'.cstr()

So are arrays: [1,2,3].carray()

But if you work with pointers, you have to be careful. Maybe I'll implement an unsafe block.

How can this be true if "V's memory management is similar to Rust but much easier to use"?

I find the same, but there are rare gems out there.

Frustratingly I saw a fun-looking language posted here before, which was a virtual-machine based system. It was small, clear, and had a good range of libraries and I'm damned if I can find it again!

http://wren.io/ Has been around HN before, as has https://fascinatedbox.github.io/lily/

Were either of these two the ones you were thinking of?

wren was the project i Was thinking of, thank you so much for the help!

Probably Tcl ;-)

Pharo, Pixie, Pony, ...?

I looked those up:

https://pharo.org/ - A language with an IDE

http://pixielang.org/ - A lisp.


Sadly not a match. All I remember was that the language was written in C, compiled to bytecode and was executed in a virtual machine (like Lua, and similar languages). It was "small" and "fast" and probably had a C-like syntax.

I should perform a decent search, because the more I think about it the more I'm annoyed now!

No virtual machine, but maybe you‘re thinking about https://nim-lang.org ?

No, it was definitely bytecode/vm-based. That was one of the reasons I was interested - because I've written a couple of toy virtual machines myself.

I should just post an "Ask HN: Tell me of your niche languages" and hope I get lucky!

Pharo is a Smalltalk distribution. I believe it's based on Squeak.

Why should the goal of every programming language be to become popular?

Seems like you either need to build off an existing platform, or have a company bankroll it. Rust also falls into this category.

I‘m not sure this will ever reach the light of day. It follows the same patterns as Eul did, another creation if the same inventor: - plenty of empty links on the website that lead to something ‚coming in march/april/june/...‘ - lots of nice ideas, but nothing to show for it

I wish the creator all the best, but Eul promised a lot, long long ago, and never delivered

https://volt-app.com/ it's currently released in beta for mac and windows

I can't help but wonder why Volt on Mac is 300kB and on Windows it's 2.1MB.

It explains it if you click it :)

Temporary libcurl dependency

Who/what is Eul?

I'm pretty sure this is supposed to be the continuation of eul. And having used the windows beta, it looks pretty impressive.

My friendly advice for the author of this project:

Release the code on Github. Just release anything, even if it's not finished. Make the code work first, then build a slick website where you brag about its features and benchmarks.

Creating the website first, before there's even anything to try out, is disingeous at best, and at worst it's leaching productivity away from time better spent programming. I remember how, as a junior developer, it was a lot more fun talking about how great my project was going to be, than doing the actual, hard work. But it does take hard work to bring something to completion.

You're doing the exact same thing with your chat app, Volt. You spent years talking about how great it was going to be. You promised features and release dates, then changed the release dates once you weren't able to deliver. Your current alpha release barely works and barely has any of the features. You clearly need some helping hands to implement all the features you've been promising over the years.

I'm sure there are lots of developers here who would love to hack on a new programming language or a chat app.

Creating and evolving programming languages is a difficult task. It also takes considerable time to write a decent set of libraries and iron out most of the wrinkles before it can be used in production.

As more people move into programming, we're bound to see more languages on the horizon. I wonder what the most popular languages will be, say, 10 years from now?

I'm personally looking forward seeing one language reach maturity – Pony – https://www.ponylang.io/ It seems that it brings some novel concepts to the table, one being the combo: statically compiled + actor model + high performance + capabilities secure.

Pony's memory sharing model used with Actors is really interesting. When I was writing in Elixir the overhead of deep cloning any message (or almost any - I realize large binaries are an exception) between actors seemed like a big limitation. I think Pony offers an interesting solution

I remember coming across some big systematic gotcha with Pony when I was learning though. It's been a year or two since I've even thought about it though and my brain is foggy. I think it'll take more adoption of both Erlang/Elixir and Rust for people to really see the benefits of what Pony offers. It's a really ambitious language for sure

Although it comes at the expense of better performance, not having shared memory between actors in Erlang was a deliberate decision, as it offers a few advantages over the shared model:

* More robust failure recovery, as actors can be restarted truly independently in case of faults

* Better distribution out of the box as actors on different machines can't share memory anyway

On the other hand, Pony does promise to catch certain types of errors at compile time, but this is hardly foolproof, as long running programs will still encounter hardware and runtime errors. But since these classes of errors are less common, one can choose to live with them.

Ultimately, one must learn to compromise one way or another. For now, I'm happy I can extend Elixir via Rust.

Looks very similar to Zig in terms of goals. I'm rooting for both, but it seems that Zig is ahead in terms of community. Would V have any benefits over Zig?

I think a "better C" is the biggest hole in the programming language world today. Rust doesn't do it to me, because what makes C great is that it's so simple, and easy to write a compiler for. Rust is a different class.

Walter Bright will probably show up in a minute and tell you D is a better C. He's probably right too. But being the best isn't why people pick C these days.

I also object to the idea that it's easy to write a C compiler. A toy compiler might be easy, but a good one takes UINT_MAX man-hours at least.

From what I've seen D looks like an amazing language. I've been particularly interested in the -betterC flag.

D is not simple and by default it relies on a garbage collector.

And yes, I meant it's easy to write a simple/"toy"-compiler. TCC is a good example, and I've actually used it for a real in-house project. Not every application requires perfect compatability and good optimization, and it makes it easy to get started on more elaborate compilers.

> a good one takes UINT_MAX man-hours at least.

I think Walter could legitimately claim this is only true if your int size is 11 bits (so about one man-year) or thereabouts.

Yes, the goals are similar. I will add a detailed comparison to https://vlang.io/compare

Off the top of my head: simplicity, strings, no globals, easier allocations, automatic memory management, no LLVM dependency, hot reloading, faster compilation times: https://vlang.io/compilation_time

FYI, the Rust code on that comparison page is not very representative of how that problem would be solved today. (I realize you took it from a 2016 post, though even back then some of that code would've been outdated.)

- It uses outdated libraries - `rustc_serialize` instead of `serde`, and `hyper`'s synchronous API (which no longer exists) instead of `reqwest`'s synchronous or `hyper`'s asynchronous API.

- It spawns eight threads, whereas the Go example (and presumably the V example too?) uses eight fibers.

- A thread-safe incrementing counter would be better done using an `AtomicUsize` rather than a `Mutex<usize>`, in which case the entire `next` function is a single call to `AtomicUsize::fetch_add`.

A modern Rust example could either continue to use the eight threads, in which case it would look quite similar in terms of the length of the code.

But more likely someone writing the code today would use fibers via futures and tokio, which would not have the Mutex or "manually chunk the work among eight workers" stuff. I think that it would be a bit shorter and clearer than the current code, but I would have to write it out to be sure.

Here is the futures+tokio approach I was talking about: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Indeed it's a bit shorter than the original, and hopefully clearer without the line noise of locking and manually chunking work.

It’ll also get even clearer with async await!

Well, get back working on that, then! JK, you're doing great work, keep it up.


(I don’t work on that stuff personally, to be clear.)

I've updated the example: https://vlang.io/compare

Got some help :)

Unfortunately this still has two of the three problems I pointed out, and as I said it is unlikely a Rust user would use threads for this purpose in the first place.

It's definitely less "simple", contrary to what the text introducing it says, compared to letting futures+tokio handle the concurrency for you. Not to mention less efficient.

But I suppose it needs to be this way so as to be equivalent to the other languages' examples.

There was a language called Clay that aimed to be a better C and succeeded through design, though it is no longer maintained.

It had ownership and templates but was mainly meant to be directly translatable to C.

The authors talk a lot about how fast the compiler is. It doesn't matter if the compiler is fast if the generated code is slow.

Imagine the simplest “compiler” for python or perl or JavaScript that doesn’t compile anything but just interprets it. There’s a lot of advantages to not having to wait for compilation. One can write a large and useful program with reasonable speed ups just from stupid compilation as many programs don’t need to be particularly fast.

One can imagine modifying the compiler to output llvm bitcode. You now can throw plenty of optimisation at it for free (but you are now slower to compile). This may be useful for prod but I claim a lot of the time it’s still useful for dev to have a simple very very fast compiler. Think less about the time to build one file and more of the time to rebuild your entire tree (or just a file which many things depend on)

> One can imagine modifying the compiler to output llvm bitcode. You now can throw plenty of optimisation at it for free (but you are now slower to compile).

If you look at the FAQ, you'll see they can do exactly that but using gcc/Clang, not LLVM.

Isn't Clang LLVM?

Debug builds in C++ can be slow AND generate slow code.

Like the website says, if you need performance, you do production builds, which use GCC/Clang with -O2.

In the future V will have its own optimiser.

I'm curious. Why the short names such as .len instead of .length? Also, ui.WindowCfg instead of ui.WindowConfig? I think this would make we hesitate all the time. Was it .new_textbox or .new_txtbox? Short keywords are one thing (Lua's local and function are no fun) but abbreviated library functions and types are another.

Why is this such a big deal? Is there really so much difference among ui.WindowCfg, ui.WindowConfig, and ui.WindowConfiguration?

As long as everything is consistently named within a framework/language, I don't see any problem.

Yes. The latter are words, cfg is not a word. Words are easy to google, say, pronounce. "shortenings" are up to interpretation, have no translation.


> “config”

> The word you've entered isn't in the dictionary. Click on a spelling suggestion below or try again using the search bar above.

Hey, I prefer configuration, so you'll get no argument from me on that, but it's definitely more of a word than cfg.

I tend to agree. That said, I rather like V’s short primitive type names (i32, u32, f32, f64, etc.).

But why do definitions put the type _after_ the field/variable name? So many of your type names are the same length! Think of the beautiful column alignment you could have if you put the type _first_!

V aligns your code automatically :) Also variables are declared with `a := value`

On putting the type after the name: https://golang.org/doc/faq#declarations_backwards

I'm guessing here, but I don't think column alignment was a consideration for the ordering.

I would be concerned if it had been :).

Agreed, predictability is huge.

I think our systems can handle an extra few characters :)

For me I guess, it depends how many such abbreviations one must learn. 100 fine. 1000 too many for me.

Github of compiler (not examples) or it didn't happen.

The site says open source will happen this year

perhaps, but it’s all conjecture until it’s out there. i hope it’s real, though!

It looks like a nice little language. It looks like Go influenced the syntax (in a good way). Based on the "concurrent" example, can we assume that it does coroutines instead of green threads?

Have you tried converting the C impl of the Computer Language Benchmarks Game to compare runtime performance against other languages?

well, I don't know why this doesn't have more upvotes. It deserves them. This is literally the first time I've fallen in love with a programming language. It does all the things I'd want it to. Has all the positives of go without most of the shortcomings, is minimal and understandable, disallows 10.days.ago style magic without being overly limiting, compiles fast and makes small apps, something I really want in the age of bundling Chromium and Node with every hello world, and has a native GUI, so huge potential for accessibility. The only thing unnerving me is that Volt, the only publicly available app written in V, doesn't seem to be accessible which might indicate the GUI is not native after all.

Thanks. Glad you like it.

Volt uses native UI, but the text content is drawn for performance. It will be made accessible soon.

How can you fall in love with something you've only seen described to you in platitudes?

Comparing the compilation speed of a non-optimizing compiler against optimizing compilers is very dishonest.

I repeated the experiment with 200 000 lines of code, where each line contains an assigment (just a constant) followed by a print statement (printf / std::cout). Results on my Macbook Air are similar:

    $ time g++ cpp.cpp
    real 2m28,454s
    $ time gcc c.c
    real 0m7,112s
Compilers are indeed really slow.


None of the compilers are optimizing.

There used to be a stack-based language called V as well... https://code.google.com/archive/p/v-language/

Which license will be chosen when it will be open sourced?

Not sure yet. I'm considering GPLv3 with the linking exception.

Apache/MIT would be more sustainable as it will be easier to get companies to donate money and use the technology.

It would certainly be easier for companies to take it and not give anything back, that's for sure.

I know it is "yet another language" but I at least like the examples I saw. Very golang inspired obviously (even has the go keyword) but with some niceties (e.g optionals). Maybe when I get around to writing my Z language I'll use this as a basis.

Why not leverage LLVM for doing stuff with SIMD?

Will the output to readable C always be available in the future?

> Will the output to readable C always be available in the future?


Curious about the GUI parts: Is it talking to X11 directly? What about widgets? Cairo, Skia?

Indeed it uses Cocoa/Win32/GTK+, and if you need drawing, there's a small library called gg. It used OpenGL, but in the future will also support DirectX and Metal backends.

GTK is super slow. Do you have any intentions of using raw X11 or Wayland?

From "Simple GUI app" example - "import ui // Native cross platform ui toolkit (uses Cocoa, win32, GTK+)".

Looks very similar to Go(which is a good thing) but to catch up it needs a great std lib and great tools like Go has. I wish it would keep the upper-case/lower-case convention as well for private/public identifiers

Well cheers to someone making a compiled language that is like a simplified C/C++. Rust is great but it's a paradigm shift, and Go is great but it (edit here:) has a runtime which we don't have implicit control over.

This is a promising C-ish language without the cruft and easy foot-shot triggers.

Can't wait for the rules regarding packages/modules, how they are distributed, the clean and simple build systems, documentation constructs, and clean integration into VSCode ... and of course all of the key/default libraries we need to be productive.

Good start folks, looking forward to the next rev.

Out of curiosity, what makes you think Go is not compiled?

It's my fault. Go is compiled, of course, but it has a 'not yet very well optimized' runtime which I don't immediately associate with compiled languages. I should have been more clear. My bad.

What about Go's runtime do you find not very well optimized?

No worries, I was just curious if you read that somewhere.

Have you even used it? According to my tests Go is quite well optimized. It beats most languages at prime number crunching/array push/map set.

Anytime I did any text work with it it was awful (including JSON etc).

Go is compiled... It has a runtime with GC but it is definitely compiled to static binaries.

I think this looks extremely promising. Out of curiosity, is there any support for lambdas / functional programming? Can I pass a function as a reference?

I haven't figured what I want to do with this yet.

Most like something like `users.filter(_.name.starts_with('A'))`


This seems pretty amazing. I'm really curious how it manages to avoid data races. It doesn't seem to mention anything complicated like rust lifetimes.

Also, what happens when unsafe C++ is converted to v, for example, code with iterator invalidation?

There are so many unanswered questions.

If you are a V programmer do you have to go around at night and spray paint V on garbage cans?

Not required, but recommended :)

V for vaporware?

I dont believe this is real. Sorry but maybe someone can decompile the volt app to see if this is any legit.

I mean if you are releasing such vaporware you should at least do it anonymously not openly like you do.

We'll see but anyhow it seems that some people like the language's features. Pony exists so why not this?


Can you explain the connection you're trying to draw between Pony, a language used in production, and this one? I don't want your comment to be misinterpreted.

Sorry I wasn't clear and the connection is not clear. The connection is only that Pony is as far I know a less common language that implements a unique set of somewhat similar features so it should be feasible for V to be built. I was thinking that not only can Google create Go or Mozilla create Rust but smaller groups or maybe an individual can create an useful programming language.

Writing this caused me to look at [1] to see if I was completely off. I do see some similarities but also a big difference, at this point of time, in terms of Pony's greater professionalism and claim's to rigour.

[1] https://www.ponylang.io/discover/#what-is-pony

The connection being that coming from the fringes/nowhere (e.g. no Google or MS etc), without much support, and building a language with a comparable feature set is not exactly impossible...

Pony actually exists, while this doesn't. Not sure what you are trying to say.

If you take as granted that "this doesn't" exist, of course there's nothing the parent can say.

But if you consider that "it might or might not exist, it could be vapor, or merely under wraps, we don't know yet" -- which is reasonable, then the comparison to Pony is clear:

Pony (a language with tons of similar great features and no big corporate funding behind it) does exist, and THUS it's not impossible for another language like that to be made.

In this day an age, we constantly see quite good languages coming from apparently nowhere. I'd add Nim, Zig, Crystal, and others to the list.

So, parent's point is: V might not exist at all, but that's not because it's too farfetched to exist.

If it works as advertised, it looks to be a boon. I hope we can commit to a full security audit of the compiler, runtime, and std libs. My trust is lacking lately.

This sounds like the best thing since sliced bread language.

The 400K compiler is interesting. But, does it help to solve any of my problems today? I would like to hear more about the reason of its development.

How to download the compiler ?

You can't.

"Open source release in June 2019."

At this point it's just vaporware tease.

I don’t think it is.

It'll be available in June. Online playground in 2 days.

Interesting! Any chances to see an ARM port in the future?


But of course you can already compile for ARM by emitting C.

Come on guys. I get it that everyone and their cat invent new languages nowadays. And that is a cool thing, do not get me wrong. But as a professional in that field, is it too much to ask to give just a little overview over the /interesting/ parts of the language? What is its type discipline? What data structures are supported? What is the execution/evaluation strategy? How about concurrency? Coroutines? Macros? Modules? The language design space has been mapped thoroughly in the last decades. Is it so hard to give a tiny X on that map?

The Comparison page is pretty illustrative here: this language appears to be an effort to build up a lower-level-ish Go (e.g. no runtime, no GC) with some extra features (e.g. nullable types, generics) and some extra safety properties (e.g. no global state, immutable-data-by-default.)

c.f. https://vlang.io/compare

Has it actually been mapped thoroughly? Is there actually a common language/terminology across Ruby, Python, Lisp, Javascript, Go, C++, etc?

I've noticed that terms & definitions subtly or not-so-subtly vary from programming language to programming language, so I imagine it's pretty tricky to come to any sort of consensus.

>> C/C++ translation

This is huge.

It is. I'm super excited about it.

I'm wrapping up an article on translating Doom 1 to V. It will include generated .v code.

C maybe, but translating from (or even to) C++ is a genuinely company-sized effort.

Yeah, I'm kind of wondering if it does template instantiation or the C++ it reads is basically C with class methods?

It's vaporware.


Last time it was posted, it was a small page with some basic information about the language.

Now there's documentation, examples, comparisons, and lots of extra details. I guess that's why people started discussing it and posting on different platforms.

I know about the no dups rule, just thought it would be interesting for people to discuss.

OK! We've un-duped it.

Thanks :)

Moved from #7 to #74 for some reason.

It tripped the overheated discussion detector, which we've just turned off.

Good thing - V looks hot.

Right, I'll show myself out...

What does [dupe] mean?

I think the intention is to mark this story as a duplicate of


For lizard people.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact