Shared compiled V libs
EchoPouet opened this issue · comments
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. 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 V ?
The idea will be to add a new type of file like JAR for Java. This file, vca for V 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 V.
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.
Not sure if I understood it correctly, but why we can use a DLL in this case?
Maybe I'm not making myself clear. You have to see it as for C/C++. To share your library you need the .so or .a file (for linux) but this is not enough. You also need the header files to compile your project with the library.
As for Java there is no separation between the declaration of functions or types and their definition. Header and sources in C/C++. JAR is used for that, share a file that contains définitions and binarie (pre-compile) associate.
For V for example, the .vca file must contains all definitions and the binarie code associate in an archive. This file can be used by V compiler like a special library used to build your code.
I see. And the main goal of this is to help companies share proprietary code in V?
Yes, share V libraries between companies without give the entire code.
Did you do any research on how this will help V adoption by companies? Because this seems to be a quite big feature, that will expand the codebase and needs to be maintained as well.
I personally don't care about companies and their proprietary libraries, and I will be against this feature if it will introduce more complexity to V without benefits.
So as I understand you want a way to share V libraries without sharing the source. For proprietary software.
Right?
The very first version of V used to allow that. I'm personally fine with this, as it is a requirement in some industries (although it's needed less and less these days).
although it's needed less and less these days).
👍 this is exactly what I see around me.
Anyway I think the obstackle is V itself as V does not have any "headers specification" whatsoever. Thus the only way to make a binary (e.g. a library) usable by other apps (incl. but not limited to apps written in V) is to distribute C headers. And doing this is a great advantage because there is already infrastructure for C header based workflow.
Why would one want to come up with something V-specific when the goal is interoperability for which C as the common denominator is the industry standard?
It does actually: .vh (V headers).
Again, they somewhat disappeared after the compiler re-write, but they will be back for module caching, so that the parser won't have to parse entire libs when using pre-compiled lib cache.
Did you do any research on how this will help V adoption by companies? Because this seems to be a quite big feature, that will expand the codebase and needs to be maintained as well.
I can't give you any information to say that V will be adopted by industrial companies, but what is certain is that they won't do it without this feature.
So as I understand you want a way to share V libraries without sharing the source. For proprietary software.
Right?
Yes. As I say, an archive with the definitions of functions and types and the associated binary code.
although it's needed less and less these days).
👍 this is exactly what I see around me.
I never give a date to made this feature. This is not the most important.
Anyway I think the obstackle is V itself as V does not have any "headers specification" whatsoever. Thus the only way to make a binary (e.g. a library) usable by other apps (incl. but not limited to apps written in V) is to distribute C headers. And doing this is a great advantage because there is already infrastructure for C header based workflow.
Why would one want to come up with something V-specific when the goal is interoperability for which C as the common denominator is the industry standard?
As it is, how do I share my V lib with another V developer without giving my code away and without him having to do a C binding?
An example: I am a C developer and I like V a lot. I have to make a lib for a customer and I tell him that V is a great language. He is very interested because he wants to test something else but it must be simple, not like C. When I tell him that my delivery will be a C header with a DLL and a V binding file, he tells me that in the end why not stay on C.
@EchoPouet this will be implemented (or rather brought back) this year.
There is no rush.
This possibility has become very rare in modern languages and it limits their use in many areas.
For your information, there are several types of contracts in my company (we also work on open source project):
- The customer orders the development of a software brick (lib or executable). He is the owner of the code.
- The customer buys a license to use our executable or library. From the most expensive to the cheapest:
- He buys the rights to have the code and to do what he wants with it
- He buys a license to use the application with the code but must not modify the code (correction, nor improvement). It is the developer who does the maintenance.
- He buys a user license without the code.
@medvednikov What's next ? I have to create an issue that points to this RFC?
A last point, to be easy to use, vpm should allow to download or use local vca file and build with this.