I would say Nim is far less intuitive than Python, and it’s better to only iteratively refactor occasional subsets of your code for heavy performance, and not presume you need all parts to have C-like speed (you don’t).
This is why I think choosing to begin a project in Nim (or C++), is a form of drastic premature optimization, compared with Python and iterative usage of Cython.
I think that’s a false question. The point is that it’s actually not easy, not even in Nim (in fact, especially not in Nim).
Writing safe and effective Python is easy. So then where do you go from there for the ~10% of the codebase where a user could conceivably ever care at all about performance enhancements? Wholesale switching to a different language is quite a drastic (premature) decision in such case, whereas Cython gives you the same (actually even better) facilities for type safety and detailed performance optimization, and offers it crucially on a case by case basis.
I see a lot of cheering for Nim on this front. It makes me happy that some people enjoy Nim and like to use it. Cool! But it makes me sad to see the significantly wrong-headed discussions about it as a practical alternative to Python + Cython. It’s the opposite: choosing Nim is a wildly impractical way to get what Python + Cython does better.
That's exactly what many said about Go. It was largely disproven since then.
You can integrate Nim code into your Python codebase just as readily as any other compiled language, including Cython. Cython produces shared libraries conforming to Python C-API, and you can do the same in Nim.
Having very similar, but different in surprising ways, language for extensions may be actually more of a problem then what developer familiarity might buy you. Instead of a mish-mash of two languages like Cython, using a proper language with its specific set of abstractions might be better, depending on a use case.
I would like to know what you consider the "better facilities" for type safety and performance optimizations Cython has that Nim lacks?
> “You can integrate Nim code into your Python codebase just as readily as any other compiled language, including Cython. Cython produces shared libraries conforming to Python C-API, and you can do the same in Nim.”
You can’t integrate as easily as with Cython at all (for instance any Python file is immediately already a valid Cython file). To boot, you don’t have to generate Python C-API code with Cython, you can just produce pure C shared object files and interactvwith it via cffi or ctypes if you want, or even just write an entire program in C with Cython and not have any CPython execution model anywhere in it.
The bigger benefit though is that you can target optimizations to specific subsets of code by creating both the CPython api for them and the underlying C implementation in one place, with just one kind of syntax.
> “Having very similar, but different in surprising ways, language for extensions may be actually more of a problem then what developer familiarity might buy you.”
I don’t understand this. Cython is a superset of Python. It’s not “different in surprising ways” because if you write Python it’s literally not different.
It has extra features you optionally can use, but that’s in no sense “different in surprising ways.” If a feature surprised you, it would be because you did not understand its usage, and not because it was a tricky, different way to achieve the same effect as something in pure Python (because to do that, you’d just write Python).
In terms of “better facilities” I am hesitant to engage because it seems like your mind is made up that e.g. Cython is “mish mash” and I highly doubt you would genuinely consider the significant design flaws of Nim (and in general I hate how religious about Nim these discussions always seem to be on HN), but one particular issue is the nasty Sum Type syntax in Nim with a companion enum for value constructors. Compared with fused types in Cython (which auto-generate the whole multiple dispatch apparatus and don’t need pattern matching), I’d prefer taking Cython as a way to make performant and polymorphic type safe code in Python any day.
reply