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

261–270 of 308 posts

Re: The V Programming Language

#261

Post by amedvednikov »

hollerith wrote: post #153
trpc wrote: post #147

It's amazing that one person can do all this. It really takes a huge amount of dedication, knowledge and high IQ to invent a language from scratch alone. I think he is trying to Rustify Golang which is a thing I always wanted to do before giving up entirely on Golang.

When I saw your "Rustify" I assumed V has a borrow checker, which it turns out not to have. Having immutable variables, no null type and option types is not enough to make a language Rust-like IMO because dozens of languages have those things. ADDED. Now that I know more, I see you have a point: V and Rust are the only 2 languages I know that have immutable variables, no null type, option types and no automatic memor…

Yes, like https://vlang.io/compare says, V is somewhere in between Go and Rust.

Re: The V Programming Language

#262

Post by amedvednikov »

trpc wrote: post #147

It's amazing that one person can do all this. It really takes a huge amount of dedication, knowledge and high IQ to invent a language from scratch alone. I think he is trying to Rustify Golang which is a thing I always wanted to do before giving up entirely on Golang.

Thanks! :)

Re: The V Programming Language

#263

Post by dom96 »

ScottFree wrote: post #247
dom96 wrote: post #217

Earlier quoted context omitted.

> Now that (part of?) the code has been released, it seems to be little more than a transpiler from V to C, with allowed inlined C, with most advertised features stubbed out. This is a little off-topic but I feel it needs to be discussed. The term "transpiler" that you've used here is a little belittling, not only to V but to other languages which are translated to C. I don't think its fair nor accurate to characteri…

> V does seem to lean very heavily on inlined C inside its standard library and compiler. So that assessment is totally fair. If you don't mind me asking, how heavily did Nim rely on inlined C inside it's standard library and compiler when it was only 3 months old? Or did you guys do something different that early in it's development?

I wasn't around back then. But as far as I know there was never much inline C used, many C functions were wrapped sure, but that's necessary to use POSIX/WinAPIs.

Nim has always had a "everything should be implemented in pure Nim" philosophy. So much so that the stdlib is even separated into "pure" modules[1] (implemented in Nim completely) and "impure" modules (those that depend on external C/C++ libs). Nowadays major things are implemented in Nim, for example we don't use libuv/libevent but instead have written our own epoll/kqueue/IOCP implementation.

1 - https://github.com/nim-lang/Nim/tree/devel/lib/pure

Re: The V Programming Language

#265

Post by yjftsjthsd-h »

edgeyboy wrote: post #164

After going through the source code, I can tell for sure that it's an insecure C transpiler. - Most things call just out to C. - A lot of examples don't even compile. - Some things use CLI curl or mkdir, this is /INCREDIBLY/ insecure. - Many things are unimplemented. - Dev banned me off org when I opened issues about these and deleted issues. I was unnecessarily rude on some which I apologize for, but deleting them a…

What's insecure about curl and mkdir?

Re: The V Programming Language

#266

Post by dom96 »

bscphil wrote: post #254
estebank wrote: post #163

Earlier quoted context omitted.

Extraordinary claims require extraordinary evidence. If the information presented on https://vlang.io/ had any hint of being aspirational as opposed to comparing it directly with existing languages, and the author had less confrontational interactions with skeptical people online, the reaction to this language would be different. Of course, without the extraordinary claims this code dump would also not receive the at…

It's worth noting that the website now has "WIP" annotations on many of the claims. I'm not sure how recently these were added as this thread is my introduction to the language. My assessment (not a language designer) is that this is something that shows some promise as a transpiled language for people who want a Go-like language without some of the common pain points and are OK with having no GC. I would add that pe…

> It's worth noting that the website now has "WIP" annotations on many of the claims. I'm not sure how recently these were added as this thread is my introduction to the language.

Indeed, many of these have been added just today. But even with the WIP tags many of these claims still seem false, for example, the author asserts that "V compiles ≈1.2 million lines of code per second per CPU core." but below that notes that "direct machine code generation" is still a work in progress. For this particular case it sounds a lot like the author wrote a very bare bones code generator that was over-optimized for that benchmark to produce these numbers.

And indeed, as you mention, writing a machine code compiler is no easy task.

> The goals of the project remind me a lot of Nim, and I'd have preferred to see a comparison with it rather than Rust.

It reminds me a lot of Nim as well. As a core dev of Nim I find the hype surrounding it very interesting (and perhaps a little disheartening).

For what it's worth, there used to be a comparison, and in fact we discussed it in our forum[1]. Sadly it didn't seem particularly fair and it seems that V's author has decided to remove it after our debunking.

1 - https://forum.nim-lang.org/t/4758

Re: The V Programming Language

#267

Post by gbear605 »

mhh__ wrote: post #236
gbear605 wrote: post #155

Earlier quoted context omitted.

GCs are good for some things and bad for others. I wouldn’t want to write an OS with a GC but I also wouldn’t want to write a web server where I have to manually allocate and free memory. It’s all a trade off.

You shouldn't be manually allocating memory anywhere if you malloc and free. I feel quite strongly about the use of C in modern systems code: The "C" way of doing things can often be very unsafe or at least prone to being unsafe (No fault of the programmer, but if you don't provide RAII and things like that by default it becomes too easy to double free or leave bounds unchecked) A kernel doesn't really need a garbage…

Yeah, I was using “manually allocating” as a synonym for malloc and free, but they are actually different things.

Re: The V Programming Language

#268

Post by holy_city »

ithkuil wrote: post #241
holy_city wrote: post #228

Earlier quoted context omitted.

POSIX signal handlers don't take an argument other than the signal code, so if you want to handle them gracefully in a stateful app you need a global to communicate the trapped signal to your main loop.

Closures could be used to implement this use case, provided that they can be exported/represented as native C function pointets, e.g. via a trampoline that captures the necessary captured context)

How would you implement the trampoline without a global? And would the captured context not count as a global?

In C the only memory available to a function is its arguments and data with static duration. That static storage is synonymous with global state, if it isn't known at compile time.

Re: The V Programming Language

#269

Post by lifthrasiir »

endymi0n wrote: post #165

Despite the immense neophobia of Hacker News, I'll jump forward and say I think there's a lot to love around vlang. Go is an amazing language and my go-to language for most backend tasks these days, but often when jumping back from Python, it feels needlessly cumbersome. Now don't get me wrong, I'm not talking about any "magic", Go is exactly as great as it is, because it's so simple and barebones. I'm talking about…

Ideas are common goods. Virtually everything claimed by V was tried in at least one or other forms with varying degrees of success. As always the execution is hard.

Re: The V Programming Language

#270

Post by axaxs »

AndyKelley wrote: post #204

Dan, it seems like you're referring to me, and I don't appreciate this food fight characterization. In society it is the duty of everyone to call out scam artists to protect each other and that's exactly what happened in that thread. At the time, it was a scam, since the author was collecting money from people on false claims. Respect is not only contained in tone of voice, but also in how honest one chooses to be. H…

Andy - We don't know each other but I follow your works and have a lot of respect for it. Please don't let yourself get distracted and brought down into insults on others, even if it MAY be true. There's literally nothing to be gained, and a lot to lose in doing so.
Post reply on HN