Hacker News Reader

Comment by amedvednikov | Hacker News Reader

V's creator here.

We're really excited about this release.

This is a big one. 5769 commits pushed to master, 1697 bugs closed. The highlights of this release are C2V, a fully automatic C => V source code translator, closures, and no more memory leaks by default.

There's a really cool C2V demo:

https://www.youtube.com/watch?v=6oXrz3oRoEg

Translating DOOM from C to V, building it in under a second and running it!

View on HN

The "autofree" memory management [1] seems quite interesting, and a very cool mixture between garbage collection with static memory management. Has been there been any seminar / conference talk held on this topic related to the pros / cons of this approach vs a pure GC memory management strategy, since it seems like it could be used in _almost_ all modern GC languages.

[1] https://vlang.io/#memory

Ref: https://news.ycombinator.com/item?id=25514198

I tried c2v on some very simple commands in freebsd /usr/src/bin/ such as ls and pwd and it failed. Still, very good to see this progress! May be you can add some FreeBSD commands to your test cases?

This is why I don't believe a word from the author. I don't even know if the demo is actually translating it or a demo of how he wants it to work. I have no idea if 90% of it is hand translated (SDL, some complex routines, etc) with the easy 10% actually translated.

Or maybe 100% of it isn't translated but compiled to object files with a compiler with V generating wrapper functions. I have no idea what to expect

I just never heard of anyone using V and it actually working as they expect

The first public release of a C2V alpha is not going to handle all C programs right away. This is planned for a 1.0 release later this year.

c2v may have some assumptions that are not specified by FreeBSD C code. Probably easily fixable.

Rather than assume, you can use V and find out for yourself what works and what doesn’t.

> Rather than assume, you can use V and find out for yourself what works and what doesn’t.

Why would I bother? It's been shown the author says one thing while reality shows another

So you are commenting on something about which you have no direct experience, nor are you planning to change that. Why even “bother” repeating something you may have read or heard; why not just stay silent or learn something new?

My original comment was confirming to a poster that other people experience matches his. I never asked a (non rhetorical) question here or said anything untrue

Thanks for posting.

> Translating DOOM from C to V

Like, you can literally translate a C project to V without any manual intervention?

Exactly.

This isn't a criticism, but what's the purpose of using c2v? As in, anything outside c2v just to compile it. The example of DOOM is taking the C code, converting it to V, then compiling it (which internally converts V to C before passing it off).

Generating V wrappers on top of C libraries in order to use them. Otherwise all functions and types would have to be manually converted.

Migrating older projects from C to a nicer newer language.

By moving from C to V you get rid of complex makefiles, headers (you get nice clean modules instead), you get a modern stdlib with strings etc (although C strings aren't converted to V strings by C2V yet), much easier cross compilation, etc.

How do you handle function-like macros and concatenation? Also, both D and Zig seem to have switched to including a full C compiler instead due to issues with translating C source wise, is that a possible direction for this in V or is the source translation good enough?

Macros are unwrapped by Clang when generating C AST.

No plans to support C compilation for now, translation works well enough.

Was it tested on very huge code base like say, the Linux kernel?

DOOM is big but not huge.

So not yet.

But we are planning to translate SQLite soon and yes the Linux kernel at some point.

Yes I didn't mean to down size the impressiveness of translating DOOM, congratulation for that.

I was just wondering to which scale it would stretch properly.

Thanks for your replies.

Linux kernel might be a tricky one with all the inline assembly code.

Luckily V supports inline assembly code! It's used a lot in Vinix.

A use case would be converting an existing c codebase to v and then continuing development in v, rather than c.

I think this is very good for legacy C projects specifically that are no longer being worked on, to breath new life into them and easier coding.

For libraries this can be useful if it means that you don't need to deal with a separate C toolchain in the build process. Instead you just bundle a copy of the library transpiled from C.

If it works, devs can move to a safer language for future development of the project. Anyways, code as a sacred artifact perspective needs to go - by that I mean, having tools to modify/convert and answer questions about code much more easily. May be with AI that would finally be possible.

I presume the intention is that V will be compiled natively eventually, not via C.

Yes, there's our own fast native backend, about as fast as tcc. But it can't compile V yet.

It will never be as optimized as cc -O2 though, and it will never be as portable as C, so C will always stay an option.

Reply on news.ycombinator.com