First of all, a bit of my history.
I worked in a C++ with a very generic 3D Mesh data structure (OpenMesh). Everything was templated, and I could add arbitrary data to vertices, edges, halfedges and faces. The data structure was basically the non-plus-ultra in 3D geometry representation. But it had one drawback. Every build file that included this Mesh datastructure got an increase in compilation time of 10 seconds. Meaning that the total build time rose up to over half an hour on a fast machine. Everything, because the same datastructure got compiled over and over again.
My question is, does Nim have anything to prevent this problematic development in compilation time?
generic library:
type superGenericContainer*[T] = seq[T] # imagine something really complicated and big here, not something so trivial as this
everything that actually get's used:
type IntContainer* = superGenericContainer[int64]
proc newIntContainer* : IntContainer = newSeq[int64]()
how I use it:
var ic : IntContainer = newIntContainer()
In the practical case the Generic container get's instanciated with exactly one type, and form there on, only this type is used.
A trick to improve build times in C++ is to concatenate the source files. (Or equivalently, #include all files into a single compilation unit, which maintains source line numbers for debugging.) Precompiled headers provide almost no speed-up at all for templates, in my experience.
In Nim, if you use a specific generic proc, then that proc will be specialized in the nimcache/module.c file for the module in which that proc is defined. (You can verify that yourself. I just did. That's one of the great benefits of transpiling to C.) No matter how many instances or uses across all the modules imported by your executable, there will be just one specialization per type(s). So it will have the same advantage as concatenation. And of course, since that file is C, not C++, it will compile even faster and consume much less memory.
So the answer is yes, Nim generics compilation scales well.