About V, the language Volt is written in(volt.ws)
volt.ws
About V, the language Volt is written in
https://volt.ws/lang
342 comments
> 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.
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.
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.
"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.
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.
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.
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 ), 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.
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 ), 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.
Found this from the Slack thread: 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.
Is this language going to be open-source? It seems incredibly impressive, and 100% overlapping with what I'm trying to do with Zig.
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.
* 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.
“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.
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...
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...
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/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.
https://web.archive.org/web/20180615121501/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.
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). 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.
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). 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.
I like to know that there are still developers for whom the size of an application is an important issue.
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!
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.
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.
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
[1] https://news.ycombinator.com/item?id=14778263
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). 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.
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). 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.
Looks a bit like Odin (https://odin.handmade.network/) --a language explicitly designed to be small and simple I've been enjoying learning and toying around with.
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.
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.
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.
I couldn't save settings, and from then it kept on crashing after restarting the app.
> 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
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
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
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
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
[0] https://volt.ws/img/lang.webm
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.
I hope it succeeds and is released soon! Thank you very much for your work.
> 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?
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?
> 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...
This is quite a controversial statement. But it could indeed be true, see this article: [1]
[1] https://softwareengineering.stackexchange.com/questions/2037...
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.
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.
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.
Re the website: are the fonts quite unreadable just for me?
https://screenshotscdn.firefoxusercontent.com/images/761f208...
(BTW, the language itself is exciting!)
(BTW, the language itself is exciting!)
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++ }