5 ms·

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,

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.
      - steveklabnik 8y ago
        :p (I don’t work on that stuff personally, to be clear.)
- edflsafoiewq 8y ago
  See https://github.com/vlang-io/V/issues/3#issuecomment-467808445 https://github.com/vlang-io/V/issues/3#issuecomment-46780844... and the following two comments.
- amedvednikov 8y ago
  I've updated the example: https://vlang.io/compare https://vlang.io/compare Got some help :)
  - Arnavion 8y ago
    Unfortunately this still has two of the three problems I pointed out, and as I said it is unlikely a Rust user would use threads for this purpose in the first place. It's definitely less "simple", contrary to what the text introducing it says, compared to letting futures+tokio handle the concurrency for you. Not to mention less efficient. But I suppose it needs to be this way so as to be equivalent to the other languages' examples.
amedvednikov 8y ago
Oops, it's https://vlang.io/compilation_speed https://vlang.io/compilation_speed :)

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.
    - steveklabnik 8y ago
      :p (I don’t work on that stuff personally, to be clear.)
edflsafoiewq 8y ago
See https://github.com/vlang-io/V/issues/3#issuecomment-467808445 https://github.com/vlang-io/V/issues/3#issuecomment-46780844... and the following two comments.
amedvednikov 8y ago
I've updated the example: https://vlang.io/compare https://vlang.io/compare Got some help :)
- Arnavion 8y ago
  Unfortunately this still has two of the three problems I pointed out, and as I said it is unlikely a Rust user would use threads for this purpose in the first place. It's definitely less "simple", contrary to what the text introducing it says, compared to letting futures+tokio handle the concurrency for you. Not to mention less efficient. But I suppose it needs to be this way so as to be equivalent to the other languages' examples.

amedvednikov 8y ago

Oops, it's https://vlang.io/compilation_speed https://vlang.io/compilation_speed :)