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

https://vlang.io/docs

Also

https://vlang.io/compare

https://vlang.io/compilation_speed

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.

  s := []string
  s << 'V is '
  s << 'awesome'

"Open source release in June 2019."

At this point it's just vaporware tease.

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.

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.

Moved from #7 to #74 for some reason.

Right, I'll show myself out...

This is huge.

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

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

https://news.ycombinator.com/item?id=19086712.

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

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

> “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.

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_!

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

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.

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?

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

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.

And there's nothing wrong with that.

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.

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

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.

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

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.

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

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.

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

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.

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.

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.

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.

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

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

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.

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

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

amedvednikov is the author.

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

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

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.

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.

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.

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.

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/

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

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.

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!

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

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

https://www.ponylang.io/

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!

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

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

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

Yes

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

https://www.ponylang.io/

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

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.

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.

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.

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

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.

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

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

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

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

Got some help :)

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.

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

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.

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

* 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.

None of the compilers are optimizing.

    $ time g++ cpp.cpp
    real 2m28,454s
    $ time gcc c.c
    real 0m7,112s

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

Temporary libcurl dependency

previous version of volt

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)

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

In the future V will have its own optimiser.

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

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

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

There are so many unanswered questions.

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

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.