←back to thread

327 points AareyBaba | 2 comments | | HN request time: 0s | source
Show context
mwkaufma ◴[] No.46183728[source]
TL;DR

- no exceptions

- no recursion

- no malloc()/free() in the inner-loop

replies(9): >>46183820 #>>46183900 #>>46184073 #>>46184113 #>>46184198 #>>46184398 #>>46184472 #>>46184588 #>>46185500 #
tialaramex ◴[] No.46184198[source]
Forbidding recursion is pretty annoying. One of the nice things that's on the distant horizon for Rust is an explicit tail recursion operator perhaps named `become`. Unlike naive recursion, which as this video (I haven't followed the link but I'm assuming it is Laurie's recent video) explains risks stack overflow, optimized tail recursion doesn't grow the stack.

The idea of `become` is to signal "I believe this can be tail recursive" and then the compiler is either going to agree and deliver the optimized machine code, or disagree and your program won't compile, so in neither case have you introduced a stack overflow.

Rust's Drop mechanism throws a small spanner into this, in principle if every function foo makes a Goose, and then in most cases calls foo again, we shouldn't Drop each Goose until the functions return, which is too late, that's now our tail instead of the call. So the `become` feature AIUI will spot this, and Drop that Goose early (or refuse to compile) to support the optimization.

replies(3): >>46184322 #>>46185348 #>>46192161 #
1. tgv ◴[] No.46184322[source]
In C, tail recursion is a fairly simple rewrite. I can't think of any complications.

But ... that rewrite can increase the cyclomatic complexity of the code on which they have some hard limits, so perhaps that's why it isn't allowed? And the stack overflow, of course.

replies(1): >>46184519 #
2. AnimalMuppet ◴[] No.46184519[source]
I don't know that it's just cyclomatic complexity. I think it at least part of it is proving that you meet hard real-time constraints. Recursion is harder to analyze that way than "for (i = 0; i < 16; i++) ... " is.