3 ms·
> Also, why "fortunately"? Because I think it's a lot harder (both for you and for your users) than you thought at the time, and I hoped you wouldn't waste you
by tom_mellior 9y ago
> Also, why "fortunately"?
Because I think it's a lot harder (both for you and for your users) than you thought at the time, and I hoped you wouldn't waste your time (and your users' time) on it. Personally, I think GC is the way to go to keep your (programmers') sanity. If you worry about GC pauses in time-critical sections, provide for a way to turn off the GC temporarily for such sections.
You might want to mark such non-GC sections/functions specifically and enforce statically that no dynamic allocation may be triggered from within them. Kind of like a monad. No allocations, no GCs, no headaches. Simpler and more flexible than the Rust model.
> No insult was intended.
I didn't read that as such!
- paniq303 9y ago> Because I think it's a lot harder (both for you and for your users) than you thought at the time, and I hoped you wouldn't waste your time (and your users' time) on it. I believe it is possible to offer such a feature without declarative baggage. If it's not, then I don't want it ;-) > Personally, I think GC is the way to go to keep your (programmers') sanity. If you worry about GC pauses in time-critical sections, provide for a way to turn off the GC temporarily for such sections. It might be even possible to leverage Scopes' support for compile-time introspection to write contextual GC's from within the language. I haven't explored that yet. In games development we usually prefer to allocate in frames, stages or on custom stacks, so that's also a way to do it. Installing a GC at the lowest level is a brutal choice that precludes many other possible ways this could go, so I'm cautious.
- yoklov 9y agoFWIW, I’m in the camp of people who find this to be extremely interesting, but only given that there’s no GC.