Hi everyone. I really like Nim and I want more people to use it. Right now Nim is a niche language but I want to help change that by making Nim more popular.
I think making it easy for devs working in other languages to use Nim code is a good way to get Nim used in more places and broaden Nim's appeal.
If developers start using Nim libraries from other more popular languages, Nim can work its way into more developers' sphere of awareness and maybe into more companies. I hope after more developers see they already use Nim code, they will start experimenting with it themselves.
This is why @guzba and I are working on genny.
With genny you can generate a shared library (.dll, .so and .dylib) with a simple C API and quality bindings for other languages.
Currently we have Python working pretty well with C and Node.js pretty far along too. We plan to and more languages. What languages would you like to see?
For our pilot genny project we have created pixie-python, bindings for Python programmers to use Pixie. You can simply install it with pip install pixie-python (just pixie was already taken). See: https://github.com/treeform/pixie-python and https://pypi.org/project/pixie-python/.
The Python code that binding users will write should feel "Pythonic" and pretty close to Nim:
Python:
Nim:
let paint = newPaint(pkSolid)
paint.color = color(1, 0, 0, 1)
ctx.fillStyle = paint
ctx.fillRect(50, 50, 100, 100)
We provide a DSL that you can use to define how things need to be exported. The DSL is pretty simple to follow:
import genny, pixie
exportConsts:
defaultMiterLimit
autoLineHeight
exportEnums:
FileFormat
BlendMode
exportProcs:
readImage
readmask
readTypeface
exportObject Matrix3:
constructor:
matrix3
procs:
mul(Matrix3, Matrix3)
exportRefObject Image:
fields:
width
height
constructor:
newMask(int, int)
procs:
writeFile(Image, string)
copy(Image)
getColor
setColor
Genny is very new and experimental, don't expect it to work perfectly for everything just yet. Genny is working though and we think it is possible to use genny for more projects at this point.
Consider trying genny or pixie-python for your next project and let us know what goes well and what we can improve!
Nice idea. Maybe rust as well. We can showcase nim's advantage's with it's competitor
Maybe pixiepy. Doesn't seem to be taken
Nice idea. Maybe rust as well. We can showcase nim's advantage's with it's competitor
Maybe pixiepy. Doesn't seem to be taken
We call this nim-c-nim sandwich. How it works is that we compile nim-c and create the DLL with a basic C interface. Then we create another nim file (it kind of looks it was generated by c2nim) that does the export.
original nim function:
proc simpleCall(a: int): int =
## Returns the integer passed in.
return a
c function signature:
long long test_simple_call(long long a);
nim's function DLL importer:
proc test_simple_call(a: int): int {.importc: "test_simple_call", cdecl.}
proc simpleCall*(a: int): int {.inline.} =
result = test_simple_call(a)
We do a function wrapper around the C function because some times one needs to convert from cstring to string, or other types, or insert exception handling. Some times its wrappers on both ends, to pass a string we convert it to cstring and then back to string. This allows programs using the DLL to use --gc:refc while DLL basically require use of --gc:arc or --gc:orc.
What languages would you like to see?
For scientific computing it could be nice to support R and maybe also Julia.
support golang or a popular "dev-ops" language. I anticipate newcomers from that work domain. probably, swift is also a good choice. julia language. similar to Nim in many ways.
bulky languages to benefit from memory or speed: java (or derivatives: scala, kotlin) and c#.
How would you handle the different GCs? or maybe there is no special handling needed?
For Julia, the way I did it in nimjl is that I wrapped the GC-routine as well in templates.
This allows you to :
Handling the GC has 2 scenarios right now. 1) the language has destructors or some kind of "I'm going away" object callback we can hook into. In this case it's great, we can manage the memory automatically. 2) In the case we do not have lifecycle events for objects, currently it requires manual management.
We hope many languages will be able to work automatically (like Python can), but it is not clear that we can make all of them work that way. This is also only the case for memory allocated by the Nim library, which for compute-centric stuff, may not be a concern so it isn't necessarily terrible for all Nim in all use-cases. But ofc not ideal.
@PMunch Yes generics or overloads are supported, you got to define a concreate type or proc in the bindings DSL (otherwise how languages like C which don't support them work?):
generics:
exportSeq seq[float32]:
discard
exportSeq seq[Span]:
discard
overloads:
draw(Image, Image, Mat3, BlendMode)
draw(Image, Mask, Mat3, BlendMode)
@Araq I totally agree a good UI toolkit would be great. But its also very hard to make one. Pixie is a step in the right direction.
@Clonk The compiled / interpreted is a huge debate. All I want to add as we plan to support both that is why we have C and Python as two things we target.