3 ms·

How about D[1] or possibly ante[2]? Ante has significant whitespace (sorry), BUT it has fancy macros. Goto is implemented as a macro, for instance. 1: https:

How about D[1] or possibly ante[2]? Ante has significant whitespace (sorry), BUT it has fancy macros. Goto is implemented as a macro, for instance. 1: https://dlang.org/ https://dlang.org/ 2: https://github.com/jfecher/ante https://github.com/jfecher/ante

reificator 9y ago
Note that I did edit the above post as you were replying. Also I should note that I'm writing this from the perspective of developing game engine style code. D: * D's garbage collector can be switched off, but last I checked (to be fair a few years ago) this even locked you out of parts of the stdlib. For smaller game engine projects, this is an issue. For larger ones, they often rewrite the stdlib anyway, though I'd expect growing pains while bootstrapping up to that point. * Memory safety guarantees appear to be much stronger in Rust than in D. The difference in approach demonstrates this well I think, Rust has an `unsafe` keyword while D has a `@safe` attribute. * It's great at its goal, which is to be (C++)++. It sidesteps a lot of the problems found in C++ and appears much more intentionally designed. * Despite a 7-8 year headstart for D, from the outside of both communities the Rust community appears much more vibrant. I've not heard of Ante, I'll go take a look.
- earenndil 9y ago
  > D's garbage collector can be switched off, but last I checked (to be fair a few years ago) this even locked you out of parts of the stdlib. For smaller game engine projects, this is an issue. For larger ones, they often rewrite the stdlib anyway, though I'd expect growing pains while bootstrapping up to that point. Yeah, that is a problem -- albeit one that people are currently working on fixing. Look at BetterC[1]. And I've heard rumours someone is rewriting the GC to be much more performant? And if nothing else, you can just stop the GC and manually collect your own memory, and a smart pointer implementation is probably relatively simple. However, is the GC even a problem? You know what they say about premature optimization. 1: https://dlang.org/spec/betterc.html https://dlang.org/spec/betterc.html
  - reificator 9y ago
    I've spent enough time writing games in various GCed languages, and GC has been an issue in all of them. It's less about the optimization of the actual pause time and more about trying to make sure that things are as deterministic as possible for debugging's sake. Though the pause is of course an issue as well.
reificator 9y ago
Just looked up Ante, and it has some compelling bulletpoints. However, development on the language hadn't even started by the time Rust hit 1.0. I like to play on the bleeding edge sometimes but I wouldn't write a large sideproject in a language that new. And of course, as you stated it is a significant whitespace language, which isn't usually my cup of tea. I will certainly keep an eye on its development though, thanks for the heads up.

reificator 9y ago

Note that I did edit the above post as you were replying. Also I should note that I'm writing this from the perspective of developing game engine style code. D: * D's garbage collector can be switched off, but last I checked (to be fair a few years ago) this even locked you out of parts of the stdlib. For smaller game engine projects, this is an issue. For larger ones, they often rewrite the stdlib anyway, though I'd expect growing pains while bootstrapping up to that point. * Memory safety guarantees appear to be much stronger in Rust than in D. The difference in approach demonstrates this well I think, Rust has an `unsafe` keyword while D has a `@safe` attribute. * It's great at its goal, which is to be (C++)++. It sidesteps a lot of the problems found in C++ and appears much more intentionally designed. * Despite a 7-8 year headstart for D, from the outside of both communities the Rust community appears much more vibrant. I've not heard of Ante, I'll go take a look.

earenndil 9y ago
> D's garbage collector can be switched off, but last I checked (to be fair a few years ago) this even locked you out of parts of the stdlib. For smaller game engine projects, this is an issue. For larger ones, they often rewrite the stdlib anyway, though I'd expect growing pains while bootstrapping up to that point. Yeah, that is a problem -- albeit one that people are currently working on fixing. Look at BetterC[1]. And I've heard rumours someone is rewriting the GC to be much more performant? And if nothing else, you can just stop the GC and manually collect your own memory, and a smart pointer implementation is probably relatively simple. However, is the GC even a problem? You know what they say about premature optimization. 1: https://dlang.org/spec/betterc.html https://dlang.org/spec/betterc.html
- reificator 9y ago
  I've spent enough time writing games in various GCed languages, and GC has been an issue in all of them. It's less about the optimization of the actual pause time and more about trying to make sure that things are as deterministic as possible for debugging's sake. Though the pause is of course an issue as well.

reificator 9y ago

Just looked up Ante, and it has some compelling bulletpoints. However, development on the language hadn't even started by the time Rust hit 1.0. I like to play on the bleeding edge sometimes but I wouldn't write a large sideproject in a language that new. And of course, as you stated it is a significant whitespace language, which isn't usually my cup of tea. I will certainly keep an eye on its development though, thanks for the heads up.