You can see this repo https://github.com/SciNim and start with this doc https://scinim.github.io/getting-started/index.html.
This may be what you are looking for.
Checkout https://github.com/mratsim/Arraymancer.
@vindaar made a demonstration of it here: https://github.com/Vindaar/NeuralNetworkLiveDemo
That live demo wasn't buildable for me, so I redid it a bit somewhere. I'll look for it and post it.
so as not to start with Nim, then get some obstacles that you cannot pass, and lose time or have friction due to this.
What about the constant friction known as "matplotlib"? It's not like Python "just works", it too can be a terrible user experience...
I suggest you agree with your boss. base your projects on python (typed as much as you can), and tell your boss you can have more performance with Nim code when necessary. (create a nim .so lib and use this from python, as explained in nimpy).
That's terrible advice. Running Python code inside Nim can makes sense in the places where Nim doesn't have an existing package but the other way around is hardly practical. Exposing a foreign API is a lot of work in both development and maintenance for little added value - and worse you lose some of the best things in Nim : Nim is faster, easier to ship binary, and has better type system than Python.
Also, you don't code in Nim as you would in Python. So don't apply Python methodology to Nim. There are tons of resources and I've found both the Matrix/Discord or this very forum full of helpful people if you simply make the effort of asking good questions.
you can even replace the task with arraymancer if it can do the job, but allow yourself the flexibility of python, and the vast documentation and examples that come with it, so as not to start with Nim,
This, but the other way around. Use Arraymancer everywhere you can, and in the places where you don't find a Nim package, you extend Arraymancer through Scipy / Numpy. I wrote a page about doing exactly that and coded an easy to use NumpyArray type compatible with Nimpy https://github.com/SciNim/scinim/blob/main/scinim/numpyarrays.nim
then get some obstacles that you cannot pass, and lose time or have friction due to this. less joy but more stability. if you find designing with Nim is better for you, start with that, then either make a .so library, or reimplement (yikes) in the workplace preferred language, but you'll know it was type checked in Nim and is safe from a static language perspective. just my 2 cents. less idealic, but more rational in my opinion.
There are tons of friction in other language too; it's just that you're used to it so you don't notice it anymore.
Python is very slow and has no type safety. C++ has frictions EVERYWHERE from compiling, to writing generic code, to designing API that it's not even funny to ocmpare to Nim.
Nim is a powerful tool that requires learning how to use it to be effective with it. And yeah sure from time to time you encounter an annoying compiler bugs or an obscure error message; but the community is very helpful and the core team actually listens to the critics and I've found that over time, things are constantly improving
That's terrible advice. Running Python code inside Nim can makes sense in the places where Nim doesn't have an existing package but the other way around is hardly practical. Exposing a foreign API is a lot of work in both development and maintenance for little added value - and worse you lose some of the best things in Nim : Nim is faster, easier to ship binary, and has better type system than Python.
I disagree. I think calling Nim code from Python is a viable option (of course the ideal would be to use just Nim...) and you would use Nim instead of e.g. Cython to speed up Python code. Nimpy (and nimporter) should make this use case (almost) effortless. I think releasing Python libraries that use Nim inside could actually bring visibility to Nim from Python users (see also pixie that has been released with a python api through genny).
Note that in the reverse case, when you call Python code from Nim (which I agree is a viable option when you miss stuff), you introduce a Python dependency which might easily get complicated to manage (especially on windows) and if you ship a binary it will depend on the Python environment present on the machine you ship to.
In the case of @archnim it seems that if you have been previously approved to develop in Nim, instead of switching to Python to access the ecosystem, I agree that using Nimpy would probably be a valid choice that you can propose to your boss arguing that it will make the overall code safer and more maintainable.
In other cases where there is an existing big Python codebase, I think one way to introduce Nim in the work environment would be to propose to replace critical parts with Nim code (and even there a dev manager might have a justified concern: if my Nim coder goes away, do I lose ownership of Nim codebase inside my organization?).
That is true. If both options are on the table, I would also prefer to use Nim and call Python (or other) for what is missing (or better yet build it).
Nim powered Python libraries still could be seen as a Trojan horse to attract, if not Python users to Nim, maybe Python library builders to Nim. And if the library builder also sees that, for example, his library could be easily made available to other languages (eg R and possibly Julia although that makes much less sense since Julia would be better off with a lib built in Julia itself), Nim could be attractive for Data Science library builders and from there it is easier to transition to: just use Nim.
I use Nim for ML and built visualisation library http://pl0t.com example notebook.
P.S.
Just some notes, what part of ML/AI is missing in Nim in my opinion. Almost any language has the computation part of ML/AI.
The thing that Python has is the infrastructure around that ML/AI computations. Basically Python allows you to write couple of lines, hit "Run" and the job is done, do a lots of experiments fast, cheaply and efficiently (human-time efficient, not CPU-time efficient), write as little code as possible.
Many problems in ML/AI are not about ML/AI itself, but more like: 1) how to get the data 2) how to clean the data 3) how to visualise the results 4) how to switch to different algo and compare with previous algo 5) how to keep kode short and clean so math people can easy understand and change it etc.
In principle the laser code has been merged into arraymancer end of last year. That does include gemm, which is used for some operations nowadays by default. It's a bit messy at the moment whether something is Nim only or not though.
LAPACK however still depends on an external library.
Depending on your use case it might already work.
@mratsim could probably better expand on this.