Nim Lang Bindings

[naturalarch3r]

Describe the project you are working on

An unannounced 3D game project.

Describe the problem or limitation you are having in your project

Redot does not have a programming language that developers looking to graduate from GDScript can graduate to easily. C# is the easiest, but still a very different language from GDScript. Redot also lacks a language that performs like C++ without the headache and pain of using C++.

Nim would offer a smooth and straight path of upgrade from GDScript with its syntactic similarity and metaprogramming while also offering an easy-to-use, safe, and performant systems-level language.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

While Redot supports C#, C++, and GDScript, it would benefit massively from official Nim bindings.

What is Nim

Nim (https://nim-lang.org/) is a stable and mature systems-level language that is extremely configurable. Nim has multiple memory management techniques, including a cyclic reference counter, an acyclic reference counter, a mark and sweep garbage collector, manual memory management, and even optional borrow checking. It has a syntax inspired by Python which is very similar to the syntax of GDScript.

Why Another Language

There are three supported languages already: GDScript, C#, and C++. However, each have various limitations that make them unattractive for some reason or another.

GDScript is good for prototyping and learning and is a pretty decent interpreted language. C# is good because it can attract Unity and Godot users. C++ is good for very experienced users such as industry professionals.

GDScript is very slow, C# is verbose and slow, and using C++ is pulling teeth.

Nim has the expressiveness, clarity, and ease of use of GDScript while performing very closely with C++. Further, it is possible to tailor Nim so it looks and feels like GDScript.

Why not Zig

While Zig is a very capable language, it still suffers from many problems that C and C++ do. It locks out many community members due to being too complicated. From my personal experience (admittedly anecdotal), most users of Godot and Redot do not want to manage memory. Nim, due to its syntactic similarity to GDScript and its use of a Cyclic Reference Counter (ORC) by default, would benefit both experienced and inexperienced users.

Experienced developers could comfortably use manual memory management with Nim, achieving performance on par with C++. While not quite the same level of performance one would get out of Zig, it should be more than sufficient for nearly every developer. Those who need more performance and are experienced with Zig likely have the skills and knowledge to use its interop with C++ to take advantage of the existing C++ bindings and integrate Zig into their project.

As you will see below, Nim is the most suitable system-level language besides C++ to support officially.

Tailorable to Redot

The features Nim boasts, which most greatly would benefit Redot, are its close similarity to GDScript in syntax and DSL-like metaprogramming. If Nim was officially supported by Redot, the Redot package for Nim could provide syntactic sugar to mirror GDScript's syntax. For instance, you could use Nim's pragma syntax to include all GDScript attributes, such as the tool attribute.

Great C++ Interop

Further, Nim has very good C++ interop. This means that binding Nim should be easy and straightforward. The bindings could be generated from the API header file or the JSON API, as Nim has very good JSON support in its standard library.

To get an idea of just how capable the interop for Nim is, here are some bindings for Unreal Engine: https://github.com/jmgomez/NimForUE

Good Package Manager

Nim has a package manager called Nimble. Nimble would allow Redot users to utilize all existing Nim packages in their game projects. Nimble is somewhat similar to cargo in some ways as well, as dependencies are compiled into the resulting binary rather than being free-standing. This would greatly reduce clutter in project exports or testing.

Optionally Supports Functional Programming

With Nim, it is possible to use actual functional programming. This wouldn't be the lambda-centric approximate available in GDScript and C#, but rather, actual functional programming. This aspect of Nim is more obscure, though, so it likely would not be all that attractive to very many users.

In Conclusion

Nim is a very flexible language that would offer Redot users an immediate and direct path of graduating from GDScript, while also offering quite a lot to more advanced users. It would have an ease of use close to C#, the expressiveness and pleasantness of GDScript, with the performance of C++.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Summary

It would be best to support it similarly to the C++ GDExtension bindings as an official bindings generator project. This would allow users who want to use Nim to upgrade from GDScript or move to a more pleasant language than C# or C++. For the best level of support, there should be a plugin tool to generate the Nim project for the user so that they can easily get working on their project, similar to C# support.

The generated bindings would be a Nimble package that can be installed, named something like "ReNim-4.3.1".

A bindings generator leveraging CI / CD could automatically provide bindings to Nim whenever there is a new release for Redot. This should minimize maintainer work while also ensuring immediate support for API changes. Manual intervention will be necessary for any metaprogramming aspects, however.

An existing project for Godot that is MIT-licensed could be forked for a faster start if desired: https://github.com/godot-nim

Leveraging Metaprogramming

Nim has compile-time evaluation and metaprogramming. The bindings package could include syntactic sugar and additions that make Nim look and feel like GDScript. Alternatively, the syntax could be a separate package such as "RDSyntax-4.3.1".

It is possible to make changes to the syntax of Nim to make it more familiar to GDScript devs. For instance, here is what a struct definition looks like in Nim:

type
  foo* = object
    bar*: int
    baz*: float

With Nim's metaprogramming, it would be possible for it to look like this:

@tool #means everything in this source file can now run in-editor

pub struct foo
  pub bar: int
  pub baz: float

Variable declarations could go from this:

var
  foo*: int
  bar*: int

let baz*: float

To this:

var
  pub foo: int
  pub bar: int

let pub baz: float
``

### If this enhancement will not be used often, can it be worked around with a few lines of script?

This question is fundamentally inapplicable.

### Is there a reason why this should be core and not an add-on in the asset library?

While support for Nim at the engine level like C# would be ideal, it is also unnecessary. Support for Nim could be implemented as an official binding like C++.

Official support ensures that Nim is always an available option in Redot for developers of varying experience levels.

[heavymetalmixer]

IMO Nim is also too complicated, it tries to do many things but it doesn't really achieve anything to a good degree. That, and the fact that it has an "optional" GC makes it not appealing, because languages with optional GCs often break most libraries (including the standard library) by not using the GC.