> 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](https://scinim.github.io/getting-started/external_language_integration/nim_with_py.html) 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
