
About V, the language Volt is written in - AndyKelley
https://volt.ws/lang
======
amedvednikov
Hi,

Developer here. I was going to post this here in a couple of weeks after
launching the product and creating a separate site for the language with much
better information about it.

I'd also like to hear your opinion about not allowing to modify function
arguments except for receivers. This is an idea I got that isn't really
implemented in any language I know of.

For example: mut a := [1, 2, 3]

So instead of multiply_by_2(&a)

we have to return a new array (and this will later be optimized by the
compiler of course)

a = multiply_by_2(a)

I think this will make programming in this language much safer, and the code
will be easier to understand, since you can always be sure that values you
pass can never be modified.

For some reason all new languages like Go, Rust, Nim, Swift use a lot of
mutable args in their stdlibs.

You can still have methods that modify fields, this is not a pure functional
language, because it has to be compatible with C/C++:

fn (f mut Foo) inc() { f.bar++ }

~~~
physguy1123
I'm not sure if I'm the target audience for this (low-latency trading), but
here's my thought - code which would allocate in a fast path is a strict no-go
for me, and this runs fairly close to that in a few regards:

> It seems easy to accidentally make allocating code allocate by changing some
> variable names (b = fnc(a) - oops, allocation)

> I would be extremely wary of trusting a compiler to realize what sort of
> allocations are optimizable and not - I already have problems with inlining
> decisions, poor code layout, etc in fairly optimized c++/rust code compiled
> by gcc+llvm.

Replace allocation with any other expensive work that duplicating a
datastructure would result in, and you have the same story. I suspect many of
the people that would be evaluating this compared to C/C++/Rust have similar
performance concerns.

~~~
gcb0
You need to stop pretending they are not globals. Just accept you work on one
continuous memory patch and are simply passing pointers around. If you don't
lie to yourself, you can't shoot your own foot when the compiler do not see
your lie.

~~~
nudpiedo
not all abstractions are leaky, many compilers/language grammars enforce the
paradigm of local lexical contexts.

Playing a game without accept its self imposed restrictions whose player
accepted voluntarily would be lying to oneself.

------
pcwalton
> V is compiled directly to x86_64 machine code (ARM support is coming later)
> with no overhead, so the performance is on par with C.

Direct compilation to x86-64 machine code does _not_ get you performance on
par with C (by which I assume the author means GCC or Clang). The optimization
pipelines of GCC and Clang have had decades of work put into them by some of
the best compiler engineers in the world.

Since the author states that the compilation time is linear, this would seem
to imply that a full suite of optimizations are not being done, since many
optimizations done by GCC and Clang have nonlinear complexity. It is easy to
get fast compilation if you don't perform optimizations.

> \- Thread safety and guaranteed absence of data races. You no longer have to
> constantly ask yourself: "Is this thread safe?" Everything is! No perfomance
> costs either. For example, if you are using a hash map in a concurrent
> function, a thread safe hash map is used automatically. Otherwise a faster
> single thread hash map is used.

This description doesn't guarantee freedom from data races. (Java's memory
model basically fits this description, for instance, except for the specific
case of hash tables, which aren't built into the language.) Even if it did,
the tricky part is determining what a "concurrent function" is. The obvious
ways one might imagine doing this tend to fall down in the face of higher-
order functions.

~~~
amedvednikov
Yes, you are right. I had a mental note to update the description, I never
expected this to be posted on HN so early :)

Just updated it:

> V is compiled directly to x86_64 machine code (ARM support is coming later).
> There's also an option to generate C code to support more platforms and
> achieve better performance by using sophisticated GCC/clang optimization.

~~~
kupiakos
Why not output to LLVM code instead of C?

~~~
amedvednikov
LLVM is a huge dependency. It's very complex and slow. And it's C++ :)

I want every part of the language ecosystem to be simple so that everyone can
contribute.

~~~
bakul
May be you should say "LLVM will be considered once its code is converted to
V." :-)

~~~
amedvednikov
:)

------
SiVal
My two biggest questions about V are 1) How is memory managed?, and 2) How is
concurrency done?

"V has no runtime". No GC, but you don't have to manually release memory, like
Rust but much easier. Sounds great. How?

And "no race conditions ever" and "everything is thread safe". You can do that
with "no runtime" fairly easily if there's no goroutine-style concurrency. I
didn't see any mentioned, but I could have easily missed it.

Those two aspects of the language are fundamental enough that I would
certainly want to read about them near the top of any overview of the
language.

~~~
amedvednikov
Good question. I haven't mentioned memory management because it's not done
yet. I know for sure there won't be a GC or reference counting.

I want to do something similar to Rust's approach, but much much simpler. It's
not an easy task.

Right now the language handles very simple cases. Small strings are placed on
the stack, local variables that are not returned are clean up automatically.

Globals are not allowed, function args can't be modified, so that helps a bit.

~~~
pulse7
No GC, no reference counting, no manual memory management... Hmmm.... Not
everything can be managed by RAII/SBRM... Let say I have a function which
loads a complex document (like spreadsheet), does some changes, saves the
document and then exits. Who will dispose this complex, dynamic document from
the memory? This is the CORE question! If there is a no GC, no RC, no manual
management solution to this, then I AM REALLY INTERESTED to know about it...

~~~
SiVal
Yes, which is why I asked. He seems to be saying it will have the ease of GC
with the performance of fully manual memory management with none of the costs
of either. I don't see how radically simplifying Rust's approach can do that,
but I don't have to. If he can find a partial solution that is significantly
better, that will be great. I don't know if he'll succeed, but I'm rooting for
him.

------
dang
Making a programming language specifically for the needs of one program, then
developing that language and the program together, is an underestimated
strategy. I believe the world would be more interesting if more people applied
it—because then we'd get more qualitatively different new systems. The Sapir-
Whorf hypothesis may not be something people currently believe about natural
language but for sure it's true about programming: the language you program in
conditions what you think, which conditions what program you write. When the
two evolve together, evolution can go to new places.

This strategy is time-honored in the Lisp world, where making a language and
writing a program are more intertwined, and the cost of making a language much
lower, than they usually are.

~~~
omeid2
The downside to this is that unless your language gets widespread adoption,
you can corner your community into a bubble and drastically increase the
barrier to contribution.

I think one of the issues of Gnome Project is this, they use a language
specifically designed for Gnome/GTK+ and as if that was not enough, it has two
different syntax, one--Vala which is sort-of-kind-of C#-like and the other
being Genie which is sort of kind of python-like.

~~~
loup-vaillant
> _unless your language gets widespread adoption, you can corner your
> community into a bubble and drastically increase the barrier to
> contribution._

Only if your language (and standard library) is of comparable complexity to
that of widespread languages. C has more quirks than it lets on, C++ is a
monstrously complex beast, Java has an _enormous_ standard library…

If however you keep the syntax and semantics of your language simple, they can
be learned in a matter of minutes. If you keep the "standard" library focused
towards your application, it won't require more effort than any other regular
application.

The real problem with custom languages, I think, is that very few programmers
can actually write one. Most others don't even see the need, I think in part
because of motivated cognition (If I delude myself into thinking I don't need
something, I don't have to face the fact that I can't do it). Though the main
problem is probably education: we are taught that languages are _chosen_ , not
made. As for how they are made… well, that's the realm of geniuses who have
way too much time to spare.

Every programmer should have an introduction to programming languages, and we
need more specialists who can whip up a DSL in a couple days. Our craft would
be very different (and I think much better) if we did that.

~~~
andy_ppp
Elixir allows you to build powerful DSLs within the language using macros and
optional syntax. Also, if you write CSS well you end up with a DSL describing
your screens. What other languages give you this power?

~~~
eslaught
Terra [1]. I used it to create Regent [2] specifically because it takes this
approach.

[1]: [http://terralang.org/](http://terralang.org/)

[2]: [http://regent-lang.org/](http://regent-lang.org/)

~~~
SomethingOrNot
You’re affiliated with Stanford? If so, also with the developer of Terra?

------
mathgladiator
Awesome, I love to see new programming languages in action. This is great.
Some thoughts.

First, ignore negativity and focus on getting constructive feedback. One of my
tiny regrets is that I abandoned one of my projects due partially to negative
energy. Many years ago, one of my projects was shared here (
[https://news.ycombinator.com/item?id=226480](https://news.ycombinator.com/item?id=226480)
), and the feedback was kind of a buzzkill (especially since I wasn't the one
sharing it).

Second, think about the growth you want. While I could ignore the buzzkill and
keep the faith, I used my language to put a real product out into the world.
The crazy thing is that I got it working and working very well, but when it
came to hire. It was a cluster fuck. I should have spent a bunch more time on
documentation and examples, but I had other concerns that were higher
priority. I ultimately had to abandon the whole thing, and I just rewrote
everything in C# and used Mono. It was painful, but the company was able to
grow faster since the tools were somewhat standard and a plethora examples for
the new hires.

When I look back, I was onto something. If I had kept the faith and pushed
through, then I would have created something very similar to HHVM which
Facebook uses. My strategy back then was to create a less awful language,
improve it, then port the platform bits to a better ecosystem and preserve the
"business logic".

My core advice with the programming language side of the house is to find a
partner for you to lead/follow with shared values. Make it open source as soon
as possible, don't wait.

------
AndyKelley
Found this from the Slack thread:
[https://news.ycombinator.com/item?id=19081896](https://news.ycombinator.com/item?id=19081896)

Is this language going to be open-source? It seems incredibly impressive, and
100% overlapping with what I'm trying to do with Zig.

~~~
nickpsecurity
To Andy:

I thought it was a new name for Zig seeing your name and the description in
the link. ;) It actually looks about too good to be true, especially that it
can handle any C++ to V conversion. I was pushing people to check out
languages like ZL exactly to rid us of C++ without throwing away legacy code.
If it can do that and fast compiles, I can't wait to read the full write-up
later on.

Btw, I encourage you to keep at Zig for diversity in systems, language space.
Plus, macros. I tell people to avoid them by default for more maintainable
code. However, there's times where it's better to have them than not have
them. I was happy to see D, Rust, and Julia do macros. Zig and V should have
them, too, for max productivity.

To amedvednikov:

1\. The name. Although Kesterel had a V language, that was long time ago.
You're not stepping on anything. I just encourage you to do one people can
spell and pronounce easily that isn't already taken. That will make both
search results and adoption a little better.

2\. Macros. Like I said above. I saw you mention Go which intentionally tries
to keep a standardized language for maintainability and easy compilation. I
get that. You could add a warning to the main page that macros are available
but discouraged for most situations for those reasons. "Use them only when the
cost is worth it." Can just do two passes: one for macros, one for regular
code. Your incremental compilation should knock out most of what little
slowdown there is.

~~~
amedvednikov
I'm against macros. I've done a lot of research on this topic.

One of the main goals is simplicity and maintainability. I want people to be
able to jump into any code base (including stdlib and compiler) and understand
what's going on. Macros don't help with that.

I went through like 10 names and ALL of them were taken. There are a lot of
programming languages out there :)

~~~
skocznymroczny
I don't know of any language with macros that have proper IDEs that do more
than syntax highlighting. One of the reasons languages like Dart, Java or C#
have such amazing IDE capabilities w.r.t. refactoring is that they don't
generate half of their code during runtime...

------
didip
Wow, I like the selling points:

* Strong modular system and built in testing.

* Global state is not allowed.

* There's no null and everything is automatically initialized to empty values. No more null reference crashes.

* Variables are immutable by default and functions are partially pure: function arguments are always immutable, only method's receiver can be changed.

* Thread safety and guaranteed absence of data races. You no longer have to constantly ask yourself: "Is this thread safe?" Everything is! No perfomance costs either. For example, if you are using a hash map in a concurrent function, a thread safe hash map is used automatically. Otherwise a faster single thread hash map is used.

* Strict automatic code formatting. It goes further than gofmt and even has a set of rules for empty lines to ensure truly one coding style.

Especially eye catching is the 2 mode of every data structure. Switch to
thread-safe if there are concurrent access.

~~~
duncan-donuts
For no null is he saying that everything is just initialized to a default
value (int=0, str=“”, etc)? I’m thrown off by, “everything is initialized to
empty values” because I don’t see how empty and null are different.

~~~
eridius
The difference is all values are valid. In C, you can't know that a `char *`
is safe to dereference.

~~~
dkersten
Garbage but valid values are, in my opinion, _much_ harder errors to catch
because they can silently corrupt data, than a simple crash/null pointer
exception.

I'm not a fan of null (option types seem better -- which V does say it has),
but defaulting to an "empty" value isn't the answer IMHO as it makes it much
harder to debug by obscuring that there's a problem at all. You may not
realise that the 0 is actually an "empty" and not a valid 0 until you realise
all of your calculations are wrong, months later.

------
anderskaseorg
“No variable shadowing” might sound great when you’re thinking about that one
time someone confused you for three seconds with the addition of a new inner
variable with the same name as an outer variable. But once you realize that it
equally means forbidding the addition of a new outer variable with the same
name as an inner variable (even though those inner variables are supposed to
be implementation details)—and, as a corollary, you can _never add new
builtins_ to the language without breaking backwards compatibility—you’ll
realize that most languages allow shadowing for a reason.

~~~
vanderZwan
> you can never add new builtins to the language without breaking backwards
> compatibility

Adding any keyword is by definition breaking backwards compatibility, so I'd
say this is the correct behavior.

~~~
kupiakos
I think you're confusing "keyword" with "reserved word". A keyword has a
special meaning in certain circumstances, while a reserved word cannot be used
as an identifier. In some languages, those are the same thing.

For example, "goto" is a reserved word in Java, while not a keyword.
Inversely, in Fortran, keywords are not reserved names, so `if if then then
else else` is valid. C# has "keywords" and "contextual keywords", both
categories being keywords, but only the former being reserved names.

Regardless, a builtin might be referring to a function that's included as part
of the base language - like make() in Golang or zip() in Python.

~~~
vanderZwan
Eh, right. But correcting for that I still hold the same view that adding new
builtins should be considered breaking backwards compatibility.

EDIT: Since someone has gone through the trouble of downvoting this viewpoint,
I would like an explanation as to why I'm wrong here. I cannot imagine a
scenario in which doing so would not likely break existing code.

~~~
mrgriffin
If you allow shadowing then surely the local definition of the name will take
precedence over the new name introduced in the stdlib (or wherever), and thus
the program will keep behaving how it did before the new builtin was
introduced.

I think I must be misreading you, because it sounds like you're arguing for
the idea that adding new names to an API should be considered a breaking
change? I'll accept that maybe reflection will catch those changes, but with
that exception why would any code even notice?

------
coldtea
Is this a real language, or am I dreaming this?

Those are exactly the ideas I had for what would make a perfect language!
(Assuming they're implemented properly of course).

Simple features. Immutable and pure by default (but not dogmatically so). Fast
compile. Hot reload. Automatic C interop. Fast-ish. Built in niceties like
hashmaps, strings, and vectors (niceties compared to bare C). Receivers so you
don't have to do the song and dance you do in C to tie structs and functions.
No header files!

Go came close, but no cigar. Rust added the whole kitchen sink and loads of
accidental complexity. Anxious to see how this fares...

~~~
zevv
You might want to take a peek at the Nim language as well; it has all of the
above and is quite mature.

~~~
dual_basis
Hit reload though?

------
johnt15
It's interesting that the roadmap of volt has been saying v1.0 is just around
the corner for the past half year. The other roadmap items also don't change
much.

[https://web.archive.org/web/20180615121501/https://volt.ws/](https://web.archive.org/web/20180615121501/https://volt.ws/)

[https://web.archive.org/web/20181023093131/https://volt.ws/](https://web.archive.org/web/20181023093131/https://volt.ws/)

It would be great if the roadmap contained realistic items. Once a user is
burned by an unmet expectation he won't believe anything else on the website.

~~~
amedvednikov
Yes, I've done a terrible job with estimations and for 9 months I lived in
"release tomorrow" mode.

I made lots of mistakes that caused the delay, I'll post a detailed blog about
it.

Should have sticked to "it's ready when it's ready".

Ironically this time it it really is going to be released tomorrow (Feb 7).

~~~
adamrezich
please don't take this the wrong way but I'm almost more excited to read blog
posts about your process and what you've learned than I am for the eventual
product, or language used to create the product (though I am excited for both
of those!). reading experiences people had trying crazy new stuff is more
interesting than results of trying crazy new stuff imo

------
slaymaker1907
I think doing away with global variables is not a very good idea. While using
globals is usually a bad idea, there are many instances where globals are
appropriate (at least for languages supporting mutability). People who say
they never use globals usually do use globals and are just trying to convince
themselves they are not because they heard they were bad from somebody.

The entire Spring framework is IMO an elaborate construction built so that
engineers could use global variables without their managers finding out. There
is little to no difference between carefully using global variables and Spring
dependency injection except syntax.

The best solution I have ever seen to global variables is definitely
parameterize with Racket ([https://docs.racket-
lang.org/guide/parameterize.html](https://docs.racket-
lang.org/guide/parameterize.html)). I don't think Racket was the first
language to come up with this, but it was the first one I am aware of. The
basic idea is that you define some global with a default value. However, you
can call parameterize to change the value for the duration of some input
function. It is made thread safe by using thread local memory. It then resets
the parameter back to the default value at the end of the function.

On the other end of the spectrum, I think Rust also has a very good
implementation of globals. It will let you use global variables, but you have
to declare it as mutable, use some form of locking, or use an UnsafeCell.
Additionally, you have to mark your code as unsafe any time you try to read or
change this global variable.

~~~
darrenf
> _The best solution I have ever seen to global variables is definitely
> parameterize with Racket ([https://docs.racket-
> lang.org/guide/parameterize.html](https://docs.racket-
> lang.org/guide/parameterize.html)). I don't think Racket was the first
> language to come up with this, but it was the first one I am aware of. The
> basic idea is that you define some global with a default value. However, you
> can call parameterize to change the value for the duration of some input
> function._

Isn't that basically Perl's `local`?

~~~
tripa
It is, but Lisp did have it first, even if not through Racket.

~~~
eslaught
Yes, it's called dynamic scoping, and for a long time it wasn't believed that
the other option (what we call lexical scoping today) could even be
implemented efficiently.

[https://en.wikipedia.org/wiki/Scope_(computer_science)#Dynam...](https://en.wikipedia.org/wiki/Scope_\(computer_science\)#Dynamic_scoping)

------
edgarvaldes
I like to know that there are still developers for whom the size of an
application is an important issue.

~~~
ci5er
The SS-ci5er is here to take the call.

This is "the deal"...

There are many computer environments beyond the desktop and cloud servers.
Arguably most computer environments.

But to reduce it: imagine an O&G pipeline controller that stupidly did
something bigger than QNX & C. That will be pumping oil and gas for 30 years.
Online upgrades, until some young turk blows out the library size. Oil spill
with a blown line, and New Jersey explodes.

~~~
eridius
Those systems aren't running desktop applications though.

------
cschep
100+ MB down to 5 MB is such a nice win, it's amazing that the author even
bothered to continue from 5 MB down to 100 KB. Very impressive!

------
rafaelvasco
Sounds too good to be true. If this is released it'll be serious competition
to Rust, Nim, Zig, etc. Lets hope for the best. There's just so many amazing
features. There's even a graphics library in it.

~~~
amedvednikov
I'm very excited about it. I've been working on this and Volt full time for a
year.

~~~
rafaelvasco
Very good to know! Keep going strong !

------
ilovecaching
To the problem you were originally trying to solve, why not just use Rust? Go
and C are really about as related as Java and C. Rust would have met all your
requirements, and has a lot of features you added to V to begin with.

~~~
amedvednikov
Slow compilation. Complexity.

~~~
ilovecaching
That's strange, I find Rust to be much less complex than working with C++ or
C. It keeps track of all the tough bits for me, and it has all of the nice
expressive stuff from Haskell. With Go I kept running into cases where the
language simply had no feature to save me from multiplicative complexity in my
code base.

I haven't had any problems with build times thus far, how big is your project?

~~~
amedvednikov
It's not big. But I'm developing V so that everyone can create large
applications with very fast compilation times. I'm getting x120 improvement
for DOOM 3, and I think it can be up to 400 times faster for more complex C++
projects using more templates, boost, etc.

Of course I didn't need a new language to make my project compile faster :) I
just wanted a simpler C, and I had some experience with writing languages (I
wrote 2 languages at school/uni).

Now I'm actually more excited about V than the original product I created it
for :)

~~~
solarkraft
This is the part that astonishes me the most. How can you compile so fast?

~~~
fxfan
He is a russian- these guys are crazy when it comes to performance lol.

------
avisaven
I had been looking for this exact project, but I couldn't remember its name
for the longest time. But I remember that home page exactly. Doing a bit of
seraching it turns out volt.ws appears to be a rebranding of a previously
posted [1] Eul (eul.im), posted by alex-e (whom I assume is its author).
Either way, volt.ws and the associated V language sound quite interesting, I
look forward to hearing more about this in the future.

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

------
DaiHafVaho
As an (anonymous) programming language designer, a few bits of feedback.

First, nice concept, but without open code, it might as well not exist, and
without open specification, it might as well be yours alone, like one of
Tolkien's languages. Closed languages wither and die, and yours seems well
onto that path.

Second, what makes V compelling to you appears to be completely uninteresting
to me in terms of language design. It might as well compile from V to Go; I
can't see why not!

Whenever a language designer appeals to simplicity, they are usually appealing
to whatever makes it possible for them to be productive, and they are usually
missing that the productivity is personal because the designer is the one who
builds the language. The GL demo seems to be a great example of this sort of
situation.

I hope that you publish your work so that we may properly critique it.

Edit: Here is another language designer who is not me saying "closed languages
die" ([https://blog.golang.org/open-source](https://blog.golang.org/open-
source)). I think that, until we actually have a compiler for V (or whatever
it is hopefully renamed to before release) in our hands, we ought to be
extremely careful about trusting that any of this exists. It is all too common
in PLT/PLD for somebody to come in with bold claims, outrageous mockups, and
zero toolchain. I addressed what I saw, which is yet another compiles-to-Go
hobby language. To become more than that requires a committed community and a
common repository of open code, and the author appears to have only the
former.

~~~
ww520
> Closed languages wither and die, and yours seems well onto that path.

This is unnecessary harsh. The author has already said it will be open sourced
later. I can understand the reasons to not open source now. Managing an open
source project is no small work.

Second, notwithstanding V's slim feature set, it's already more successful
than 99% of language design attempts out there in that it ships. It certainly
succeeds in letting the author to build his other projects faster and easier.
It fulfills the author's own needs. I'm sure Perl and Python started that way.

~~~
kkarakk
look at the authors comments in this thread, he's been known to miss deadlines
before. open sourcing is probably gonna be really really delayed

~~~
ww520
This is his personal project. He really does not owe anyone anything, deadline
or no deadline. Open source "users" have been getting really entitled these
days.

------
kilowatt
Looks a bit like Odin
([https://odin.handmade.network/](https://odin.handmade.network/)) --a
language explicitly designed to be small and simple I've been enjoying
learning and toying around with.

------
hexmiles
For me personaly the killer fature is: C/C++ to V translator

Having all my library in the same language make a lot thing like debugging and
testing easier. It also semplify the mental model i have of the program.

Also C(lang) interop is my main struggle with go. For me it is such a pain
that something i wrap a c library in a stdout/stdin server and just spawn it
and use cap'n'proto for communication. When you use cgo you lose the easy
cross-compiling, i would love for something similar in go and/or rust.

I wonder if llvm could be used to implement a sort of universal transpiler.
even if it not use the target language in a semantic language it still make a
lot of thing easier.

~~~
amedvednikov
> For me personaly the killer fature is: C/C++ to V translator

Yes, I'm super excited about it!

------
stabbles
I tried the app on the mac and it's very buggy.

I couldn't save settings, and from then it kept on crashing after restarting
the app.

~~~
gbersac
I was considering downloading it, but I think I won't now that I read your
answer. Do you know of any good competitor ?

------
leshow
> Originally Volt app was written in Go, but after a couple of weeks of
> development I decided to re-write it in C for two reasons: easier
> integration with existing C graphics and UI libraries and much smaller
> binaries. The app size reduced from ~5 MB to ~100 KB.

I'm always curious when people complain about binary sizes. Was there some
reason the binary needed to be small? Or just based on some sense of
'largeness' and 'smallness'. It seems to me like rewriting in a 'less
productive language' to save a few mbs of binary size that nobody cared about
anyway is a pretty big waste of time.

I don't mean to come across super critical, there are cases where binary size
could be really important. Say you're on an embedded platform with minimal
memory. I just don't /understand why it was something worth optimising over
here... especially to the point of a rewrite

~~~
GenericsMotors
This is the same attitude that has gotten us 20MB+ web page sizes.

~~~
leshow
I'm not talking about a web page, I'm talking about a binary you're running
locally. Your criticism doesn't apply.

------
legostormtroopr
So Volt seems interesting, but how to I download it?

All of the download links just give todays date and issues in the GitHub page
the site links to mention it being flagged by virus or not being supported.

[https://github.com/voltapp/volt/issues](https://github.com/voltapp/volt/issues)

~~~
amedvednikov
I've just released a macOS beta. Windows and Linux will be released later
today.

------
vanderZwan
I'm not sure I get what is going on in the live reloading code.. if you update
the draw function to change colors, then why does the block only change colors
when it hits the edge of a screen?

[0] [https://volt.ws/img/lang.webm](https://volt.ws/img/lang.webm)

~~~
amedvednikov
Good catch!

It should be instant. But when I was making this gif, there was some kind of a
bug, and I some how made it work only after it reaches the edge.

I was not able to reproduce this :)

I'll make a better gif once the new website is up.

------
elcomet
Volt looks amazing. I've been looking for a native IM app for a while, and I
couldn't find one. I hate all those electron or browser apps taking hundred of
MB of ram just to display messages.

I hope it succeeds and is released soon! Thank you very much for your work.

------
Rusky
> You can also simply translate your entire C/C++ codebase to V and make your
> build times up to 400 times faster. An automatic translator supports the
> latest standards of these languages.

Is this saying you can actually get compile time improvements compared to the
original codebase? If so I can imagine a couple of ways this could work-

1) skipping the optimization the C/C++ compilers would do, with V's direct-to-
machine-code generator, and/or

2) doing some heavy lifting in the translator, so the equivalent V has more
redundancy and less implicit information.

How close am I? Or is there something else here?

------
amelius
> Modern garbage collectors are very powerful and optimized. However for the
> best performance and latency it's better to use a language without a GC.

This is quite a controversial statement. But it could indeed be true, see this
article: [1]

[1]
[https://softwareengineering.stackexchange.com/questions/2037...](https://softwareengineering.stackexchange.com/questions/203745/demonstration-
of-garbage-collection-being-faster-than-manual-memory-management)

------
n13
As a someone who has never design the language or implemented a compiler, this
seems to be on very very daunting task. Just wondering how much effort it
requires and if someone like me - who has experience in developing software
using high-level languages but not compilers - can implement it. It seems to
be very interesting project and I would love to try something like this just
for the sake of learning. I would really appreciate if someone can give me the
pointers about where to begin with.

~~~
omegabravo
[http://craftinginterpreters.com/](http://craftinginterpreters.com/)

It's an excellent book and is incredibly approachable.

------
gnuvince
I'm interested to know how the language handles memory; automatic memory
reclamation without a GC and that is simpler than Rust seems like a very
attractive proposition.

------
chubs
This is a helpful approach for embedded platforms: Write in a nice language
(V), spit out C code that the usually-old embedded toolchain can compile.

~~~
amedvednikov
And you can also do C++ => V => C :)

~~~
bogdanoff_2
Do you have anything to say about C++ => V translation?

From what I know C++ is an extremely complex language. How do you deal with
the complexity? (Especially considering V is meant to be simple)

~~~
amedvednikov
It is ridiculously complex. Right now the size of the C++ translator is 10
times bigger than C and it'll get even bigger.

I'll post a detailed article about it soon.

------
mjaniczek
Re the website: are the fonts quite unreadable just for me?
[https://screenshotscdn.firefoxusercontent.com/images/761f208...](https://screenshotscdn.firefoxusercontent.com/images/761f2089-8374-449d-827e-1a0d2be8e079.png)

(BTW, the language itself is exciting!)

~~~
amedvednikov
Yea, it's using Google fonts, I'd better switch to something more standard.

------
forhadahmed
I see Go-ish syntax in some of the examples but I also see underscore_case
being used (instead of camelCase)

Does V encourage one or the other? (coming from a C background, I prefer
underscore_case)

Does V have Go's funny "uppercase export" rule? Only identifiers that start
with an uppercase letter are exported from a module?

~~~
amedvednikov
V is very strict. There's only one style. Using anything other than the
underscore case is a compilation error.

It doesn't have the uppercase export rule.

It's going to be either Rust's `pub` or Oberon's `*` or `+`, haven't decided
yet.

------
fooker
How does the live reloading work when you are compiling to C or machine code
and claim to not have a runtime?

------
User23
I'm a big fan of what they are doing, but this is really light on details.
Please show us more!

~~~
amedvednikov
You can follow the project here:

[https://github.com/vlang-io/V](https://github.com/vlang-io/V)

[https://vlang.io](https://vlang.io)

------
shouyatf
> You can also simply translate your entire C/C++ codebase to V and make your
> build times up to 400 times faster. An automatic translator supports the
> latest standards of these languages.

How do you plan to translate the latest C++ standard with all those template
stuff?

------
slaymaker1907
I would be cautious about making a language with only reference counting since
you can easily end up with stack overflows when implementing something as
innocent as a linked list unless you keep some sort of list of objects to free
in the runtime.

------
akrymski
Finally, a simple alternative to C++! I've been dreaming about creating this
for years, thank you for doing it!

Few ideas I had:

\- Simple classes (no inheritance, only mixins) like in JavaScript

\- Always pass objects by reference as in Java to avoid the pointer mess

\- Copy the core APIs from ECMAScript

------
mbrodersen
The programming language C was invented to write Unix. So sometimes creating a
language to write software works. The defence industry (in the US) is
(apparently) notorious for doing this. Any other examples?

------
jagger27
This is the most exciting software announcement I have seen in a while. I
can't stand using Facebook Messenger in Firefox.

I'd love to see how V generates its machine code. Using the Go syntax is a
wonderful idea.

------
hawski
Would it be possible to compile V to Java or JVM byte code, but by not using
giant array in the middle? I'm mainly wondering if one could use GTK+ in Linux
and Android APIs without JNI on Android.

------
warpech
Apparently now there are two programming languages called "V", the other
being: [https://www.vcode.org/](https://www.vcode.org/)

~~~
rafaelvasco
Yeah, i guess V is just a temporary name. Other nice names : Jolt, Quark,
Ether, L, Lum etc;

------
wishinghand
Off topic, but will there be a dark mode for Volt? I can’t abide by Slack’s
lack of official one and the constant overwriting of the file that maintains
the hack for the unofficial one.

~~~
amedvednikov
Yes, there will be.

------
snissn
Hey! I just wanted to see keep it up and that this looks really cool

~~~
amedvednikov
Thanks!

------
potta_coffee
Volt looks like a cool app, I'll be trying it out this week.

------
aethertron
Very very interesting. But I hope it's renamed to something other than a
single-letter name, so we can use search engines to find info about the
language later.

~~~
karolusrex
Usually you can find information about a new language pretty easily by adding
"Lang", e.g. "go lang" etc

------
solarkraft
> You can also simply translate your entire C/C++ codebase to V and make your
> build times up to 400 times faster.

What are traditional compiler makers missing?

------
duked
I really would love an alternative to the horrible Skype client but I doubt
it. AFAIK, you can't make your own unless things have changed ?

~~~
amedvednikov
Check it out tomorrow :)

~~~
duked
I will for sure. Their latest client is just too hostile.

~~~
duked
the Mac client is available but Skype support is tomorrow :/

------
lucas_membrane
Looks like this language has something in common with single-assignment C. Can
anyone offer comparison/ontrast with that?

------
dna_polymerase
Fantastic stuff. Waiting for a release though before getting too excited.
Sounds too much for a single person to do.

------
slimsag
How does this prevent data races? Does it suffer performance, or require Rust-
like annotations about lifetimes?

------
BlackEspresso
Looks really good. Any ressources on how you wrote the x86_64 backend ? Or
Thema Compiler per se?

~~~
amedvednikov
[http://ref.x86asm.net/coder64.html](http://ref.x86asm.net/coder64.html)
mostly

------
Kip9000
I'm excited about this.. Feature list seems almost too good to be true. :)

------
p0nce
> Full source code is available here.

Link refers to the same page.

------
MuffinFlavored
Is Volt WebKit or not? I can't tell...

~~~
blattimwind
Cramming WebKit into 100 kB seems technically impossible, unless those 100 kB
contain "git clone ; ./configure; make -j32 / _wait three hours_ /".

~~~
MuffinFlavored
I totally agree. So what does "Slack support" mean? Is he... implementing the
Slack API? and Skype? and Gmail? and Discord? and Facebook Messenger?

Edit: I see now. It's just a chat app with a bunch of protocols and a clean
interface.

------
sandov
It's not garbage collected, right?

~~~
mattbreeden
Correct. There's some more details in this (unfinished) article:
[https://volt.ws/game](https://volt.ws/game)

