To be frank: I have never used Rust nor Go. Nevertheless, I am quite sure closures and goroutines would complicate the translation due to different syntax from ordinary functions. The same argument is being discussed at reddit https://www.reddit.com/r/programming/comments/8si75b/how_an_...
Speaking at least for Go, the "different syntax" between closures and functions is that for closures, you don't give a function name. The only way they could be any more similar is if closures did take a function name, which is generally a bad idea because there's no single behavior I've seen that captures what programmers expect to happen in that case. (In general, for the code
x = func blah() { ... }
there is a conflict between "x is the only new binding we should have as a result of executing that line" and "the function name 'blah' should do some sort of binding".)
If that's enough to throw your translation process, you've got bigger problems....
(Cards on the table, D is probably a good choice and I'm not advocating for Go here.)
> I am quite sure closures and goroutines would complicate the translation due to different syntax from ordinary functions.
It's unclear where the root of that confidence lies. The translation is just as mechanical in either language as it would be otherwise: see an inner function, replace it with the one thing that can capture variables. Speaking for Rust, it would actually be even easier to do the translation using closures, because Rust closures can have their signatures inferred whereas Rust functions cannot.
I can see at least two issues. I'm sure you're aware of these, but:
- Rust closures don't really support recursion, at least without serious hacks.
- Rust closures borrow the variables they reference as soon as the closure is created; you can never write to those variables again as long as the closure is alive, and if the closure mutates the variable (resulting in a mutable borrow), you can't read from them either, outside the closure itself.
The latter isn't as a big a deal for some other use cases for closures, but if you want to use them to emulate nested functions, you're probably creating the closure at the beginning of the outer function and keeping it in scope for the whole function; this means that what you can do with mutable variables is severely limited.
Both issues could be worked around if the mechanical translator liberally sprinkled the code with Cell/RefCell – which would also be necessary to deal with pointers in the source language. But the result would be highly unidiomatic and verbose Rust code.
(In any case, I'm not sure I'd have recommended Rust to OP as they claim to put a high priority on fast compile times, but that's a separate issue.)
