3 ms·
My issue with Nim is its import system. If you have a function "foo" it's hard to tell where is it imported from. I'm not sure why this bothers me when C is the
by sph 2y ago
My issue with Nim is its import system. If you have a function "foo" it's hard to tell where is it imported from. I'm not sure why this bothers me when C is the same... probably because I'm familiar by now which header defines any C function.
Also, I believe high-level compiled languages suffer from the fact that it is very hard to tell which construct is expensive and which is a zero-cost abstraction. Rust has the same issue, but "zero-cost" is a major feature of the language so you don't feel bad using an Iterator, for example, in kernel code. With Nim it is hard to tell.
- seanw444 2y agoIt makes logical sense to do imports that way when operator overloading exists. Otherwise your custom operators would look like: import other varA other.`+` varB Which is very ugly. At that point, we might as well just go with the function name approach that languages like Go take: customAdd(varA, varB) I suppose you could change it so operators are imported into the same namespace, and non-operators still require a separate namespace when referred to. But that makes it even more complicated in my opinion. I agree it's less obvious what's coming from where, but I think when your libraries have distinct responsibilities, it usually ends up being pretty straight-forward what function comes from where based on how it's named (if it's written well).