Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The V Programming Language

vlang.io

Post reply on HN
Print view View original

11–20 of 308 posts

Re: The V Programming Language

#11

Post by asplake »

59nadir wrote: post #9

I find these languages that are developed behind closed doors and have no source published a bit frustrating. Even more so when they make big promises. Just like you can no longer charge for compiler, I don't think it's possible in the future to not publish the source. The truth is, there are plenty of actual open source alternatives to C (zig, et al.), what makes some shadowy language a reasonable alternative?

Not published yet. Perhaps the author considers publishing prematurely to be more hassle than its worth?

Re: The V Programming Language

#12

Post by danite »

The too good to be true alarm bells in my head are ringing. There's almost no way it delivers on all of the features listed here. Gonna need a lot of proof to back all of this up.

Re: The V Programming Language

#13

Post by lifthrasiir »

asplake wrote: post #11
59nadir wrote: post #9

I find these languages that are developed behind closed doors and have no source published a bit frustrating. Even more so when they make big promises. Just like you can no longer charge for compiler, I don't think it's possible in the future to not publish the source. The truth is, there are plenty of actual open source alternatives to C (zig, et al.), what makes some shadowy language a reasonable alternative?

Not published yet. Perhaps the author considers publishing prematurely to be more hassle than its worth?

If it's the intention, the author surely has been misguided. A drama is already happening (for example, [1]). While I think it is technically possible to deliver all of them (it should be noted that it is not exactly an optimizing compiler, which makes many things easier), it is natural and understandable that people doubt its premise before the full release.

[1] https://github.com/vlang/v/issues/35

Re: The V Programming Language

#14

Post by lamchob »

While it looks nice, it brags about it's compilation speed while simultaneously not offering any optimizations. If you want to have optimizations, C/C++ source-to-source compilation is required, which is slower by factor of 10. After that, a traditional C/C++ compiler runs the compilation/optimization, which again, costs time. What use is fast a compilation, if the resulting program can be slower by orders of magnitude?

Other than that, the design of the language looks nice and I will give it a spin at some point. Maybe I'll convert some HPC benchmarks to V and see how they perform.

Re: The V Programming Language

#15

Post by s_y_n_t_a_x »

lamchob wrote: post #14

While it looks nice, it brags about it's compilation speed while simultaneously not offering any optimizations. If you want to have optimizations, C/C++ source-to-source compilation is required, which is slower by factor of 10. After that, a traditional C/C++ compiler runs the compilation/optimization, which again, costs time. What use is fast a compilation, if the resulting program can be slower by orders of magnitu…

You can build and test faster using the direct to machine code compiler, then use the C compiler for a final production test and distribution.

Re: The V Programming Language

#16

Post by ncmncm »

kingkong2022 wrote: post #10

The claims in the homepage are completely refuted by the readme in the downloaded package. The compiler is not 400 kb dependency free. It requires shit ton of stuff. The codegen as well as hot code reloading is not present, so even the compiler performance claims and hcr on the homepage are lies. Even Rust like memory management that they claimed is not there. Volt is said to be written in Vlang using the UI present…

Memory management points up probably the most significant weakness. Give it a destructor or a drop trait or something that can be tied to scope exit. You don't need custom memory management features if you have resource management, because then memory is just another resource.

p.s. It says in the docs that its name is not vlang. That's just the web domain.

Re: The V Programming Language

#17

Post by olliej »

lamchob wrote: post #14

While it looks nice, it brags about it's compilation speed while simultaneously not offering any optimizations. If you want to have optimizations, C/C++ source-to-source compilation is required, which is slower by factor of 10. After that, a traditional C/C++ compiler runs the compilation/optimization, which again, costs time. What use is fast a compilation, if the resulting program can be slower by orders of magnitu…

I generally agree with what you’re saying in terms of perf comparisons, but high performance debug builds are incredibly important.

On the other hand, the reason they tend to be slow in large c/c++ programs is the module model basically meaning “behold as every file in your project parses and interprets large portions of the host platform’s standard library”. All modern languages know to avoid that - honestly if you want masochism I’d be curious to compare the time-to-execute for modern js engines, simply because they have incredibly large amounts of pressure to get to running code as fast as possible.

Re: The V Programming Language

#18

Post by olliej »

asplake wrote: post #11
59nadir wrote: post #9

I find these languages that are developed behind closed doors and have no source published a bit frustrating. Even more so when they make big promises. Just like you can no longer charge for compiler, I don't think it's possible in the future to not publish the source. The truth is, there are plenty of actual open source alternatives to C (zig, et al.), what makes some shadowy language a reasonable alternative?

Not published yet. Perhaps the author considers publishing prematurely to be more hassle than its worth?

But producing a flashy website is not?

Re: The V Programming Language

#19

Post by lamchob »

s_y_n_t_a_x wrote: post #15
lamchob wrote: post #14

While it looks nice, it brags about it's compilation speed while simultaneously not offering any optimizations. If you want to have optimizations, C/C++ source-to-source compilation is required, which is slower by factor of 10. After that, a traditional C/C++ compiler runs the compilation/optimization, which again, costs time. What use is fast a compilation, if the resulting program can be slower by orders of magnitu…

You can build and test faster using the direct to machine code compiler, then use the C compiler for a final production test and distribution.

You are right in a scenario where testing is lightweight and quick. I'm sure this can cover a lot of use cases. However, If the testing/development itself involves heavy computation (large integration tests for example), there are diminishing return from quick but unoptimized compilation.
Post reply on HN