Nim programming language finally hit 1.0

[Ola Fosheim Grøstad]

On Thursday, 3 October 2019 at 19:54:32 UTC, Russel Winder wrote:
> It seems that Python, Ruby, Rust, Go, and D disagree with this 
> position, all being based on source code packages.

Python have enough libraries that have been maintained for a long 
time to be reliable, also the language is stable, does not change 
much and the environment is essentially a VM. So, even if it is 
not maintained, you can basically keep using it.

Sure Go has many packages, but very few I would dare to rely on. 
The language is still changing, and I also don't want to use 
libraries on a server from a source I cannot trust.

There are so many unmaintained libraries for these new languages 
that it doesn't look good for people who want to write software 
that has to be maintained for 15+ years.


> Indeed C++  is catching up and doing something very package 
> like.

Maybe, but if the libraries you use have strong ties to the 
OS/CPU architecture, then it has to be maintained at a higher 
frequency (which is more typical for low level programming than 
high level).

What I believe is typical for C++ is to either include 
C-libraries that have a long track record of reliability, or 
depend on a small number of solid (commercial grade) 
C++frameworks, or use very small header libraries (preferably 
libraries that can be imported as independent single file 
headers).

You really need to be careful with what you pull in when 
programming in C++ both in terms of being able to debug and build 
times.


> If you end up using a library that was third-party maintained 
> but gets abandoned, do not take the time to take over 
> maintenance, change to another library. There is generally a 
> very good reason the library got abandoned, and there are 
> invariably very good newer replacements.

That's not really possible in a larger project that has been 
deployed. That would incur large costs. Besides there might not 
be another PDF-generating library for you to use, or sound 
synthesis package that is anywhere near compatible. Even in 
Python, if I cannot use the PDF library I am using now, I would 
most likely set up an additional Java service rather than trying 
to pull in another PDF library written in Python.

Besides, in reality you often end up maintaining your own fork 
anyway, since you usually have to make modifications to the 
library over time if it is doing something significant and 
special that you cannot roll on your own.

Another reason to not use packages in larger projects is that it 
makes no sense to import an entire package when you only want one 
function. Increased build times, harder to read the codebase, and 
so on.

What I find repulsive about the node.js world that use packages 
at crazy levels of pervasiveness is the security aspect of it.