Nim's compiler converts the AST into an intermediate representation that can be compiled to several backend. The primary backend is C source code, but it also supports outputting Javascript (experimentally) or interpreting the intermediate representation ala Python.

The difficulty of developing the IR -> C transformation certainly influences the features of the language, and certain features, like tail calls, can't be implemented because Nim expresses functions as C functions for the benefit of foreign code. I wouldn't say it's a leaky abstraction though, not any more than C is a leaky abstraction over machine code.

It looks like work/research in this area has been going on for at least ~20 years.

int f(int a, int b){return f(b,a);}

compiles into

int f(int a, int b){start: int t=a; a=b; b=tmp; goto start;}

All the transpiler has to do is invent a globally unique name for each function, for instance. Of course they might not have implemented it yet, but there shouldn't be any firm reason why it can't be done.

I would expect nested functions to close over their context. Still implementable in C of course (or ghc -fvia-c wouldn't work), but not as trivially.

From the manual: http://nim-lang.org/manual.html#closures

  proc a =
    proc b =
      proc c =
        proc d = echo "Hello World"
        d()
      c()
    b()
  a()

Not necessarily a problem, but unless implemented as something other than nested functions in C, there may be some portability issues. Worth investigating.

EDIT: Actually this raises the question of how it handles closures, since the generated code does not seem to provide for preserving the surrounding environment data. Though I may just need to dive in now that it's catching my interest.

http://nim-lang.org/manual.html#closures

In your example, it could be something like this:

    struct variables_in_a_that_are_visible_in_d {
        int aa;
    };
    
    void d_nested_in_a(struct variables_in_a_that_are_visible_in_d *ascope) {
        // Variable dd, not accessible from a
        int dd = 42;  
    
        // Increment a's aa
        ascope->aa += 1;
    }
    
    void a() {
        int aa = 0;
    
        // Pack up variables for d()
        struct variables_in_a_that_are_visible_in_d ford;
        ford.aa = aa;
    
        // actually call d)
        d_nested_in_a(&ford);
    
        // Unpack after calling d()
        aa = ford.aa;
    
        // Continue with a()
        // ...
    }
    

The struct may have holes that contain variables that aren't used by the nested function, but that doesn't matter. Also, you would have to make sure to flush values from registers onto the stack, and, depending on the ABI, would have to explicitly push arguments passed in registers onto the stack (that would have the struct contain a return address, but that's not a problem, either), if you need them to pass arguments to the nested function.

  proc a =
    var x = 10
    proc b = echo x
    b()
  a()

Anyway, I think I'm overdue on reevaluating the language. I can't wait to replace Python/Go/C/Java with this.