differences being the libraries, frameworks, and ecosystems related to different languages
Advice, experience, wisdom, on those also would suffice.
My experience is that Nim itself won't limit you too much as long as you're willing to contribute to the ecosystem for the missing pieces.
Main blocker is social acceptance within your company and tooling (although it's been getting better and better, it's not yet at the Cargo / Bazel level).
I was looking at Nim for use as a primary programming/scripting language in the domain of DevOps, sys/infra administration/engineering etc.
I think, Nim is an excellent replacement for Bash, Python, and Go syntax-wise, and also with respect to features built-in, and the amount of control Nim offers over my computer.
However, I see that some core libraries keep getting abandoned/unmaintained (for example jwt), so, if I build tooling depending on them, they may break (maybe in the near future!).
I could manage to write and maintain some libraries, but even with the assistance of AI, I won't be able to write and maintain a lot.
Some of the key libraries that I am looking for alternatives in the Nim ecosystem are boto3 (Python) and similar SDKs for Google Cloud, Docker, Terraform etc.
Pure Nim sounds sexy but sometimes you just have to use wrappers around C libraries, like pkg/webtokens which is a wrapper around libjwt, providing low-level and high-level APIs for dealing with web tokens.
API ref: https://openpeeps.github.io/webtokens/. Don't be shy, feel free to fork, share with your chatbot, and contribute to the high-level API so we can make it easier to use for everyone
Also, writing clients for Google Cloud, AWS by hand is totally undoable. Posted here https://forum.nim-lang.org/t/13874, this will provide an OpenAPI 3.0 spec parser and generator. Same goes for generating native extensions for most popular dynamic langs.
The idea of Clue: A CLI app that you can use it inside a GitHub Action to schedule a regular regeneration of API client libs, and docs directly from OAPI spec even when you're on vacation
My story: not an expert here, I'm just an enthusiast who switched from molly, shrooms, weed and photoshop to programming and Nim and it helped me a lot with my mental health and focus!
I think, Nim is an excellent replacement for Bash, Python, and Go syntax-wise, and also with respect to features built-in, and the amount of control Nim offers over my computer.
Nim is great to make system tooling into binaries. Go CLI will results in bloated mess, bash is unreadable and Python require to have a local python environment will all dependencies setup to be usable. Even on my personal Linux, I make some of my own tooling using Nim and https://github.com/c-blake/cligen. c-blake also made multiple unix utility tool using Nim who are excellent in both ergonomics and code quality.
However, I see that some core libraries keep getting abandoned/unmaintained (for example jwt), so, if I build tooling depending on them, they may break (maybe in the near future!).
This is where you fork the existing libraries. As long as the original one is maintained you should be able to use merge upstream your fork.
When it gets abandoned, you can ask the owner to take over the library. This is what I did with https://github.com/Clonkk/nim-cppstl which originally was not developed by me.
You SHOULD fork and use a fix commit for the dependencies that you use no matter what. You don't want a key dependencies you do not own and you don't want an update upstream to break your system.
I have very real-world example of Rust codebase where engineers spend a considerable amount of time repairing the code base due to mis-management of external dependencies (this is a setup / human issue, as Cargo allows proper dependencies management when correctly configured and used).
I could manage to write and maintain some libraries, but even with the assistance of AI, I won't be able to write and maintain a lot.
It's not that time consuming honestly, and AI has made it much better. Develop only what you need when building libraries and keep an eye out for issues / PRs.
If other people wants to use your stuff, they can also contribute to it. If your library is not popular, then you don't need to add a lot of stuff to it and if it does become popular then it's fair play to ask people to help you maintain it.
Some of the key libraries that I am looking for alternatives in the Nim ecosystem are boto3 (Python) and similar SDKs for Google Cloud, Docker, Terraform etc.
Either interface with existing library by making Nim primitive of your target API and then implement higher level Nim function that expose a clean interface or rebuild-it. You can use https://github.com/yglukhov/nimpy for interfacing with Python or FFI to interface with C and C++ .
The reality of software engineering is that :
Really, the main limiting factor of Nim is the social acceptance of peers. Many engineers loves Nim features in a vacuum but don't trust the language because :