Mirror of forum.nim-lang.org

12708 :: Curious about nimony's new features

• micl2e2 (orginal) [2025-03-05T16:07:30+01:00] view original

  First of all, I could recognize the visions behind those plans/decisions, they are really impressive. for myself it'd be a new new language, (still new to nim 2.x, hence new new), and those visions quite match mine, quite attractive to me. There are many possibilities I am curious about, and thus have some questions:

  1. Can we expect to use those features in some versions? officially landed in 3.x or else? or maybe as preview/experimental features in 3.x or else? Especially those features including native codegen, lisp-like ir, which really get me excited.
  2. Before knowing nimony, I as a newcomer, can tell that nim has firmly committed to targeting C, and the masterpiece GCC as the first-class compiler. I am already quite satisfied with such approach, but even more satisfied when heard that there is possibility of targeting native code. However another question arises: is there any chances that nim targeting libgcc?, e.g. like what rustc_codegen_gcc is doing currently. Although this is irrelevant to nimony's current design, but that way, nim's existing users will possibly continue to completely benefit from GCC optimizations.

---

• Araq (orginal) [2025-03-05T16:44:34+01:00] view original

  1. I don't know how to bring all this good stuff into Nim's old codebase without going insane. So far, "extend Nimony until it compiles most Nim 2.0 code out there" is the more realistic path.
  2. There are some plans for a NIFC->LLVM translator as well as a NIFC->native code translator. I won't do a NIFC->libgcc translator (when I looked at it, its API was missing thread local storage, atomics, calling conventions and DLL support). But somebody else can do it. ;-)

---

• micl2e2 (orginal) [2025-03-05T17:55:22+01:00] view original

  extend Nimony until it compiles most Nim 2.0 code out there

  Sounds like the most smooth upgrade path

  missing thread local storage, atomics, calling conventions and DLL support

  Well okay then it seems there's a huge barrier. Anyway, thanks for your kind elaboration!

---

• Abathargh (orginal) [2025-03-05T19:16:13+01:00] view original

  Curious about point 2: is the native code translator going to be a sort of "roll your own" generator, like go does or have I misunderstood this point?

---

• Araq (orginal) [2025-03-05T19:22:51+01:00] view original

  Curious about point 2: is the native code translator going to be a sort of "roll your own" generator ...

  Yes, as I've lots of ideas how to do that in a reasonable simple way that neverthells produces competitive machine code. Don't hold your breath though, maybe I'll never find the time to implement it.

---

• Abathargh (orginal) [2025-03-05T20:24:47+01:00] view original

  Totally understandable, I think in the long run that would be a huge plus as it enables some incredible stuff (something similar to go cross compilation story in nim would be absurdly good for example)

  Two questions in case a future were this happen will become reality:

  • How would this interact with nim incredible FFI story and C interop? My intuition tells me there is a tradeoff here but maybe I'm wrong
  • Would you be interested in supporting many targets or just x64/arm?

---

• Araq (orginal) [2025-03-05T21:17:08+01:00] view original

  How would this interact with nim incredible FFI story and C interop? My intuition tells me there is a tradeoff here but maybe I'm wrong

  Well yes, exactly, .emit cannot be supported easily.

  Would you be interested in supporting many targets or just x64/arm?

  Just these two plus some GPU architecture...

---

• termer (orginal) [2025-03-06T05:22:28+01:00] view original

  Targetting LLVM would be cool, it would make emitting WASM a lot easier than how it's done now. I do hope we can keep C as a target though, since it makes the language super simple to use in embedded contexts for practically all hardware ever made.

---

• BLeAmz (orginal) [2025-03-06T16:04:49+01:00] view original

  I do hope we can keep C as a target though, since it makes the language super simple to use in embedded contexts for practically all hardware ever made.

  I share the same hope that C will remain a compilation target. While I'm excited about the development of Nimony and its new features, if it cannot use .emit or work directly with C code, this might be the reason that keeps me sticking with Nim2.

---