Share compiled Nim libs

[EchoPouet]

Abstract

I am very interested in lots of small languages ​​and I wonder if companies can use them. Often with this language (open source) to share a library there is a package manager based on Git to get sources.

Motivation

The problem is that you must share your code. It’s not a problem when you work on open source project or if your business model is compatible with that. For a companie that would like to share a librairie to a customer without the code it’s a big problem. One solution is to generate C librarie and reinport it. Not realy ideal and why the customer would use Nim ?

Description

The idea will be to add a new type of file like JAR for Java. This file, nimca for Nim Compiled Archive (it’s an example), contains some information.

• List of all exposed functions and types,
• the compiled code
• others things to build with.

Of course this file can only work on the plateforme where the library was built. It’s not a problem at all. I really think this feature can encourage companies to use Nim.

To be clear, it’s not a judgement on business model or the open source philosophy. But the open source isn’t the unique model for lot of reason more or less justified and a language that force you to share your code limit your business.

Thank for your attention.

[Araq]

We have that in the form of .rod files which are generated for "incremental compilations" (IC) to work. Unfortunately only now work on IC has begun to continue now that ORC is reasaonably stable. But still.

[Clonkk]

Is installing rod files instead of source code a planned evolution for installing package ?

[EchoPouet]

Great.
To make it simple, this feature will replace this steps:
Nim->C Header + DLL + Nim C binding -> Nim

[Araq]

Is installing rod files instead of source code a planned evolution for installing package?

Yes. But it's quite far away and needs a mechanism like module_linux_arm64.rod because the rod-file resolved when statements and platform specific code.

[EchoPouet]

A last point, to be easy to use, nimble should allow to download or use local nimca file and build with this.

[mratsim]

The problem is that you must share your code. It’s not a problem when you work on open source project or if your business model is compatible with that. For a companie that would like to share a librairie to a customer without the code it’s a big problem. One solution is to generate C librarie and reinport it. Not realy ideal and why the customer would use Nim ?

The industry standard is a .dll or .so or .a and a header file. I don't see what nimca brings compared to that.

It's nice to allow the customer of that company to use any language as they see fit. Being interoperable is a strength, not a weakness. Forcing/contaminating all downstream to force them to use Nim, i.e. trying to do vendor lock-in, will be a negative.

[EchoPouet]

The industry standard is a .dll or .so or .a and a header file. I don't see what nimca brings compared to that.

It's nice to allow the customer of that company to use any language as they see fit. Being interoperable is a strength, not a weakness. Forcing/contaminating all downstream to force them to use Nim, i.e. trying to do vendor lock-in, will be a negative.

nimca is useful for Nim, it is always possible to produce .dll and header files for other languages. The goal is to share Nim libraries without giving the code in a simple way. It must be seen as for the JAR files in Java.

[mratsim]

I don't see the benefits compared to a .dll and header. Can you list them?

[Araq]

A .dll + header doesn't support anything with inlining semantics such as:

• generics
• templates
• macros
• iterators

Also a DLL is fundamentally type-unsafe and kinda the lowest common denominator.

[EchoPouet]

I also add that currently you have to create a Nim wrapper to use the C header and the dll previously generated by Nim. I think this is a ridiculous situation if on top of that you lose the advantages of the language.