3 ms·
I understand the excitement of proving you _can_ do something. Wouldn’t a language suited to async, or a framework implementing that from the ground up, comple
by t-writescode 7y ago
I understand the excitement of proving you _can_ do something.
Wouldn’t a language suited to async, or a framework implementing that from the ground up, complete with all its natural ugliness, be ... better than trying to shoe-horn async into such a low language?
- liuliu 7y agoIt totally would! I think that is where C++20's coroutine proposal (or Rust) makes a lot of sense (and all these negative abstraction costs!). There are a lot of fun when working on though, and the end result is not bad (I translated my old stateful coroutine based code to this one in an afternoon: https://github.com/liuliu/ccv/commit/03c84ee1e3344b8458d8502010b3ea73417ede75#diff-0576585e7e3ffa72c74264debbc013ad https://github.com/liuliu/ccv/commit/03c84ee1e3344b8458d8502...)
- s_Hogg 7y agoSure, but this is hacker news. Talking about "I figured out how to do something" is core business :) Even if it doesn't necessarily make a lot of sense to do it in practice.
- kitd 7y agoIn many cases, the actual language itself is only one reason why a particular language gets used. Often the decision also involves tooling, culture, 3rd-party libs, workforce experience, etc. Having said that, I'm sure D would shine in OP's case.
- kragen 7y agoMaybe. Doing something yourself is sometimes preferable to your compiler doing it for you, for example because you can fix it if it breaks, or because you don't have to wait for the next version of the compiler or use a different programming language. I mean yes it's nice when other people solve your problems for you with no effort on your part but that doesn't always happen.