Open EchoPouet opened 1 year ago
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.
Is installing rod files instead of source code a planned evolution for installing package ?
Great. To make it simple, this feature will replace this steps: Nim->C Header + DLL + Nim C binding -> Nim
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.
A last point, to be easy to use, nimble should allow to download or use local nimca file and build with this.
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.
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
.
I don't see the benefits compared to a .dll and header. Can you list them?
A .dll + header doesn't support anything with inlining semantics such as:
Also a DLL is fundamentally type-unsafe and kinda the lowest common denominator.
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.
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.
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.