> personnaly, I find using scripting language from compiled language makes more > sense than the reverse.
An interesting use case for the compiled -> scripting direction is being able to write a performant algorithm in the compiled language and having it available in the scripting languages (almost) automatically. I think Nim is uniquely† positioned to do this since, as genny shows, you can automate the work to create a native‡ wrapper. This of course would not be especially attractive to users of the above languages (Python, R, Julia) but it should be attractive to scientific library authors. †I am really not competent enough to know if Rust or Zig would be able to do the same but I guess Nim could be more attractive anyway for library creators used to work with Python/R/Julia. ‡the key element is the fact that genny is opinionated, I guess for scientific computing this would mean in general to convert array/tensors to the correct objects, e.g. arraymancer to numpy > as for Julia may not worth it, they don't like C and usually trying to avoid > it and use/rewrite it in Julia instead Julia being created essentially to solve the two language problem it clearly has less interest in a second language to write performant stuff. Still, if you already can write something in Nim and making it available in R and Python, why not go the extra mile and make it available "natively" in Julia (whatever native means in terms of Julia multi dispatch paradigm...)
