15 ms·

Looks very similar to Zig in terms of goals. I'm rooting for both, but it seems that Zig is ahead in terms of community. Would V have any benefits over Zig? I

by audunw 8y ago

Looks very similar to Zig in terms of goals. I'm rooting for both, but it seems that Zig is ahead in terms of community. Would V have any benefits over Zig? I think a "better C" is the biggest hole in the programming language world today. Rust doesn't do it to me, because what makes C great is that it's so simple, and easy to write a compiler for. Rust is a different class.

Y_Y 8y ago
Walter Bright will probably show up in a minute and tell you D is a better C. He's probably right too. But being the best isn't why people pick C these days. I also object to the idea that it's easy to write a C compiler. A toy compiler might be easy, but a good one takes UINT_MAX man-hours at least.
- billforsternz 8y ago
  > a good one takes UINT_MAX man-hours at least. I think Walter could legitimately claim this is only true if your int size is 11 bits (so about one man-year) or thereabouts.
- vips7L 8y ago
  From what I've seen D looks like an amazing language. I've been particularly interested in the -betterC flag.
- audunw 8y ago
  D is not simple and by default it relies on a garbage collector. And yes, I meant it's easy to write a simple/"toy"-compiler. TCC is a good example, and I've actually used it for a real in-house project. Not every application requires perfect compatability and good optimization, and it makes it easy to get started on more elaborate compilers.
amedvednikov 8y ago
Yes, the goals are similar. I will add a detailed comparison to https://vlang.io/compare https://vlang.io/compare Off the top of my head: simplicity, strings, no globals, easier allocations, automatic memory management, no LLVM dependency, hot reloading, faster compilation times: https://vlang.io/compilation_time https://vlang.io/compilation_time
- Arnavion 8y ago
  FYI, the Rust code on that comparison page is not very representative of how that problem would be solved today. (I realize you took it from a 2016 post, though even back then some of that code would've been outdated.) - It uses outdated libraries - `rustc_serialize` instead of `serde`, and `hyper`'s synchronous API (which no longer exists) instead of `reqwest`'s synchronous or `hyper`'s asynchronous API. - It spawns eight threads, whereas the Go example (and presumably the V example too?) uses eight fibers. - A thread-safe incrementing counter would be better done using an `AtomicUsize` rather than a `Mutex<usize>`, in which case the entire `next` function is a single call to `AtomicUsize::fetch_add`. A modern Rust example could either continue to use the eight threads, in which case it would look quite similar in terms of the length of the code. But more likely someone writing the code today would use fibers via futures and tokio, which would not have the Mutex or "manually chunk the work among eight workers" stuff. I think that it would be a bit shorter and clearer than the current code, but I would have to write it out to be sure.
  - Arnavion 8y ago
    Here is the futures+tokio approach I was talking about: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=130314feccf3d541bf263bd5b343c403 https://play.rust-lang.org/?version=stable&mode=debug&editio... Indeed it's a bit shorter than the original, and hopefully clearer without the line noise of locking and manually chunking work.
    - steveklabnik 8y ago
      It’ll also get even clearer with async await!
      - Svenstaro 8y ago
        Well, get back working on that, then! JK, you're doing great work, keep it up.
        8y ago
BubRoss 8y ago
There was a language called Clay that aimed to be a better C and succeeded through design, though it is no longer maintained. It had ownership and templates but was mainly meant to be directly translatable to C.

by audunw 8y ago

Y_Y 8y ago

Walter Bright will probably show up in a minute and tell you D is a better C. He's probably right too. But being the best isn't why people pick C these days. I also object to the idea that it's easy to write a C compiler. A toy compiler might be easy, but a good one takes UINT_MAX man-hours at least.

billforsternz 8y ago
> a good one takes UINT_MAX man-hours at least. I think Walter could legitimately claim this is only true if your int size is 11 bits (so about one man-year) or thereabouts.
vips7L 8y ago
From what I've seen D looks like an amazing language. I've been particularly interested in the -betterC flag.
audunw 8y ago
D is not simple and by default it relies on a garbage collector. And yes, I meant it's easy to write a simple/"toy"-compiler. TCC is a good example, and I've actually used it for a real in-house project. Not every application requires perfect compatability and good optimization, and it makes it easy to get started on more elaborate compilers.

amedvednikov 8y ago

Yes, the goals are similar. I will add a detailed comparison to https://vlang.io/compare https://vlang.io/compare Off the top of my head: simplicity, strings, no globals, easier allocations, automatic memory management, no LLVM dependency, hot reloading, faster compilation times: https://vlang.io/compilation_time https://vlang.io/compilation_time

Arnavion 8y ago
FYI, the Rust code on that comparison page is not very representative of how that problem would be solved today. (I realize you took it from a 2016 post, though even back then some of that code would've been outdated.) - It uses outdated libraries - `rustc_serialize` instead of `serde`, and `hyper`'s synchronous API (which no longer exists) instead of `reqwest`'s synchronous or `hyper`'s asynchronous API. - It spawns eight threads, whereas the Go example (and presumably the V example too?) uses eight fibers. - A thread-safe incrementing counter would be better done using an `AtomicUsize` rather than a `Mutex<usize>`, in which case the entire `next` function is a single call to `AtomicUsize::fetch_add`. A modern Rust example could either continue to use the eight threads, in which case it would look quite similar in terms of the length of the code. But more likely someone writing the code today would use fibers via futures and tokio, which would not have the Mutex or "manually chunk the work among eight workers" stuff. I think that it would be a bit shorter and clearer than the current code, but I would have to write it out to be sure.
- Arnavion 8y ago
  Here is the futures+tokio approach I was talking about: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=130314feccf3d541bf263bd5b343c403 https://play.rust-lang.org/?version=stable&mode=debug&editio... Indeed it's a bit shorter than the original, and hopefully clearer without the line noise of locking and manually chunking work.
  - steveklabnik 8y ago
    It’ll also get even clearer with async await!
    - Svenstaro 8y ago
      Well, get back working on that, then! JK, you're doing great work, keep it up.
      - 8y ago

BubRoss 8y ago

There was a language called Clay that aimed to be a better C and succeeded through design, though it is no longer maintained. It had ownership and templates but was mainly meant to be directly translatable to C.