| |
| ▲ | Ygg2 13 hours ago | parent | next [-] | | When triaging an issue you have to prioritise. Do you fix a problem that affects 2-3 people or one that may affect thousands? | | |
| ▲ | nh2 12 minutes ago | parent [-] | | The point is that such bugs shouldn't exist in the first place. Using recursion on unbounded inputs on a programming language that doesn't support that (which are most) is an extremely classical mistake that really should be known to all programmers, especially those of low level languages that care about safety. Every time you call something recursively you should be thinking "how deep is this?". |
| |
| ▲ | IshKebab 13 hours ago | parent | prev | next [-] | | It's a stack overflow which means it's using recursion and for historical reasons that don't make sense any more, stacks are teeny tiny on 64-bit Linux - apparently only 8 MB on Linux! I'm not sure why they don't raise it to something reasonable like 4 GB. I guess because they want consistency with 32-bit? Maybe we can finally change it if/when they phase out support for 32-bit Linux. Apparently it might not be that far away: https://lwn.net/Articles/1035727/ | | |
| ▲ | ploxiln 2 hours ago | parent | next [-] | | 8MB is the default per-thread stack size from glibc, also seems to be the default "ulimit" from pam or the kernel, I'm not sure. So for the main/default thread (or if not using threads) the process can use setrlimit() and for threads it can use pthread_attr_setstacksize() to get bigger stacks if it knows it may need them. 8MB is pretty huge though; musl libc is famous for defaulting to much smaller per-thread stack size of 128KB (to avoid over-committing lots of memory when there are many threads - the main dev is really principled/opinionated on this topic, but again there are a few ways for applications to explicitly size their stacks as large as they need). Linux kernel threads get a bit less than 16KB! | |
| ▲ | tosti 13 hours ago | parent | prev [-] | | OIC. Rust doesn't guarantee optimizing tail recursion. How unfortunate for a language that's getting widespread adoption. | | |
| ▲ | gpm 12 hours ago | parent | next [-] | | For what it's worth there's reasonably active [1] work on implementing opt-in guaranteed tail calls - but it's not particularly fast going. LLVM (the backend rust uses) needs better support for musttail (e.g. some architectures just don't support it [2]). [1] https://github.com/rust-lang/rust/issues/112788 [2] https://github.com/rust-lang/rust/issues/153827 By-default guaranteed tail calls really isn't rust's style, because it means subtle changes (introducing a destructor, re-ordering code, etc) can change semantics without you realizing it. If you want to guarantee that a call can't allocate a new stack frame you should have to say it. | | |
| ▲ | lioeters 12 hours ago | parent | next [-] | | Not so familiar with this area, but isn't the existing behavior of implicitly creating new stacks more of a problem than implicit tail-call elimination? Seems the latter is a kind of compiler-level optimization, of which there are already many (I think) that change the semantics internally but guarantee the outward behavior stays the same. But I can understand the preference for an explicit opt-in, to make clear that it is enforced and not assumed. | | |
| ▲ | gpm 12 hours ago | parent [-] | | > implicitly creating new stacks I'd argue that it's explicit - that's what a function call does and you don't have implicit function calls in rust. > Seems the latter is a kind of compiler-level optimization, of which there are already many (I think) that change the semantics internally but guarantee the outward behavior stays the same. What you're asking for here already exists. Tail calls might be optimized into not allocating extra stack frames, the rust compiler just doesn't guarantee that it will perform that optimization (and almost certainly won't when code is compiled without optimizations... for instance). What people want is the semantic guarantee that the stack frame won't be allocated. Not just a compiler that often performs the optimization. Otherwise you can't be sure that your code will keep working with new compiler flags/versions/architectures/... You could say "whenever the code is the right shape we'll guarantee the optimization" (C++ famously did this for things like copy elision)... but now the shape of code comes with non-obvious semantic guarantees and that's not rust's style. Hence the proposal for a keyword instead. | | |
| ▲ | lioeters 12 hours ago | parent [-] | | I see it, certain algorithms need guaranteed tail-call elimination, otherwise they are too inefficient and must be manually unrolled or rewritten to avoid blowing the stack. So a compiler optimization that is "nice to have" is not good enough. | | |
| ▲ | clhodapp 3 hours ago | parent [-] | | No algorithm requires tail-call elimination in a general-purpose language with imperative mutability. It's just another way to express iteration. |
|
|
| |
| ▲ | jmalicki 3 hours ago | parent | prev [-] | | > because it means subtle changes (introducing a destructor, re-ordering code, etc) can change semantics without you realizing it. No, it won't change semantics - if you say @musttail or similar, it will simply fail to compile if you, say, introduce a destructor - the semantics will not subtly change. | | |
| ▲ | afdbcreid 2 hours ago | parent | next [-] | | Incorrect. `become` does change drop order - https://play.rust-lang.org/?version=nightly&mode=debug&editi.... | | |
| ▲ | jmalicki an hour ago | parent [-] | | That's not implementing tail calls breaks things, that's bad design of implementing tail calls breaking things. The whole idea of "let's change semantics to make it easier" is dumb. If you want guaranteed tail calls, change your code until it works. |
| |
| ▲ | gpm 3 hours ago | parent | prev [-] | | Uh, yes, if you guarantee the semantics only when the code explicitly opts in and not by default then semantics will not subtly change, that is the point of my comment | | |
| ▲ | jmalicki 3 hours ago | parent [-] | | It's not a change in semantics of compiled code. It is only a change of whether or not the code will compile. |
|
|
| |
| ▲ | IshKebab 9 hours ago | parent | prev [-] | | Do any widely used languages guarantee tail call optimization? It's a pretty niche feature. | | |
| ▲ | gpm 9 hours ago | parent [-] | | Scala, ocaml, racket, clojure, zig. For recursion only kotlin. (For most of these only with syntax specifying it) |
|
|
| |
| ▲ | hulitu an hour ago | parent | prev [-] | | Rust ? Because of ... memory safety. /s |
|
