3 ms·

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

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?

mlthoughts2018 8y ago
> “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.

mlthoughts2018 8y ago

> “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.