5 ms·

I stumbled into Nim recently and this thing "just works". Python-like syntax, performance like C. This is what C should have been, I'd say. https://nim-lang.o

I stumbled into Nim recently and this thing "just works". Python-like syntax, performance like C. This is what C should have been, I'd say. https://nim-lang.org/ https://nim-lang.org/

mlthoughts2018 8y ago
I would encourage you to use Cython instead of Nim if you're looking for Python-like syntax combined with C performance.
- dom96 8y ago
  Why is that?
- gtycomb 8y ago
  This is just my situation, but I gave up on Cython when I started moving forward with it (distributed graph algorithms). I found that I had more things to learn. With Nim, it took me half a day (after seeing the language for the first time) to get a basic numerical process going and another few days for distributed data communication involving messaging and postgres/mongo (Nim has a modern JavaScript (ES6) promise/async/await like concurrency model that is powerful and succinct like the language itself)
  - mlthoughts2018 8y ago
    I find that strange, but I concede you know your use case better. I work on a very similar type of application that manages async workers who process large distributed NLP tasks. Writing it in Cython was extremely easy, because for the modules that have zero need for static typing, such as the part using async/await in Python 3, or when we supplement with gevent, I can just write those parts in plain Python and it’s quite a bit easier than Nim or Cython or whatever else, while still having great performance from those tools’ low-level implementation. Then for the parts that do possibly benefit from static typing and compilation (unlike the async layer), I can have precise module-level control over what has a C-level implementation and if or how it interacts with anything in Python. The inability to separate the two situations in Nim (as with many statically typed languages) just doesn’t work out well enough for my use cases. In fact, I’d even go as far as to advocate that in today’s language landscape, if you want to write a new greenfield project in C or C++ for performance reasons, it’s unequivocally your best option to write the whole thing in Cython, and avoid what you might call “premature static typing optimization” by profiling and leaving the things with no bottleneck in Python.
    - gtycomb 8y ago
      Hi - thanks for outlining your case. My Cython know-how is limited to qualify any kind of comparison with Cython. Its just that my attempt with Nim went surprisingly smooth for me. Coming from some of the older languages I use and love, the reliability of the newer Nim is pleasing and coding is fun. I ended up eliminating all Python code from my back-end. Because Nim is statically compiled I can deploy pieces of it anywhere just like a compiled C program, without dependencies, and it means a lot in my particular situation.
      - mlthoughts2018 8y ago
        > "the reliability of the newer Nim is pleasing and coding is fun." Can you elaborate on the reliability part? I've spent a lot of time grokking Nim specifically to be able to make good judgments about whether there are use cases in which it would be a better choice than Cython, and from a reliability point of view I have not noticed anything that would distinguish Nim from any other language. I can agree that Nim's syntax is nicer than many other statically typed languages, though the language design has some warts with `result` and `discard`, etc. But I can't see any reason to believe it is 'more reliable.' > "I ended up eliminating all Python code from my back-end." While I can't know the reason for this in your exact case, generally this seems like a very suboptimal thing to do. Python has a much richer set of libraries, testing utilities, etc. It is a language with a huge community of users and developers, and much more likely to be a known language for someone new who joins the project. If a system was working well and someone proposed to refactor away a solid base language like Python, that would almost always be a crazy choice, regardless of any positive aspects of the targeted new language. It's similar to why you should rarely throw away old code that has meaningful tests. You can slowly refactor it little by little, but wholesale switching to something else is usually evidence of wrong engineering priorities, especially when the something else is a 'latest and greatest' kind of new language or tool, like Nim is. > "Because Nim is statically compiled I can deploy pieces of it anywhere just like a compiled C program, without dependencies, and it means a lot in my particular situation." This can also be done with Cython, using the options to embed an interpreter... and there are various other third party tools that allow you to create thick binaries for combined Python programs as executables, including runtimes and dependencies. To boot, you definitely should be managing the deployment of some binaries with proper dependency management practices. So really, if you're already using dependency management techniques for the binaries, the minor extra work to maintain Python environments and dependencies would almost always be pretty trivial, with a huge family of tools (pip, conda, pipenv, virtualenv, etc.) and endless tutorials on the community-developed and mature best practices for packaging Python programs. I would be curious to know more details about a project where it was truly advantageous from a productivity and deliverability point of view to rewrite the backend to move from a stable and mature ecosystem like Python to a relatively younger and less mature system with Nim specifically to gain a benefit somehow related to ease of deploying pieces of the code to different locations. The details just don't sound like they could possibly be in favor of using Nim in a case like that.

I stumbled into Nim recently and this thing "just works". Python-like syntax, performance like C. This is what C should have been, I'd say. https://nim-lang.org/ https://nim-lang.org/

mlthoughts2018 8y ago

I would encourage you to use Cython instead of Nim if you're looking for Python-like syntax combined with C performance.

dom96 8y ago
Why is that?
gtycomb 8y ago
This is just my situation, but I gave up on Cython when I started moving forward with it (distributed graph algorithms). I found that I had more things to learn. With Nim, it took me half a day (after seeing the language for the first time) to get a basic numerical process going and another few days for distributed data communication involving messaging and postgres/mongo (Nim has a modern JavaScript (ES6) promise/async/await like concurrency model that is powerful and succinct like the language itself)
- mlthoughts2018 8y ago
  I find that strange, but I concede you know your use case better. I work on a very similar type of application that manages async workers who process large distributed NLP tasks. Writing it in Cython was extremely easy, because for the modules that have zero need for static typing, such as the part using async/await in Python 3, or when we supplement with gevent, I can just write those parts in plain Python and it’s quite a bit easier than Nim or Cython or whatever else, while still having great performance from those tools’ low-level implementation. Then for the parts that do possibly benefit from static typing and compilation (unlike the async layer), I can have precise module-level control over what has a C-level implementation and if or how it interacts with anything in Python. The inability to separate the two situations in Nim (as with many statically typed languages) just doesn’t work out well enough for my use cases. In fact, I’d even go as far as to advocate that in today’s language landscape, if you want to write a new greenfield project in C or C++ for performance reasons, it’s unequivocally your best option to write the whole thing in Cython, and avoid what you might call “premature static typing optimization” by profiling and leaving the things with no bottleneck in Python.
  - gtycomb 8y ago
    Hi - thanks for outlining your case. My Cython know-how is limited to qualify any kind of comparison with Cython. Its just that my attempt with Nim went surprisingly smooth for me. Coming from some of the older languages I use and love, the reliability of the newer Nim is pleasing and coding is fun. I ended up eliminating all Python code from my back-end. Because Nim is statically compiled I can deploy pieces of it anywhere just like a compiled C program, without dependencies, and it means a lot in my particular situation.
    - mlthoughts2018 8y ago
      > "the reliability of the newer Nim is pleasing and coding is fun." Can you elaborate on the reliability part? I've spent a lot of time grokking Nim specifically to be able to make good judgments about whether there are use cases in which it would be a better choice than Cython, and from a reliability point of view I have not noticed anything that would distinguish Nim from any other language. I can agree that Nim's syntax is nicer than many other statically typed languages, though the language design has some warts with `result` and `discard`, etc. But I can't see any reason to believe it is 'more reliable.' > "I ended up eliminating all Python code from my back-end." While I can't know the reason for this in your exact case, generally this seems like a very suboptimal thing to do. Python has a much richer set of libraries, testing utilities, etc. It is a language with a huge community of users and developers, and much more likely to be a known language for someone new who joins the project. If a system was working well and someone proposed to refactor away a solid base language like Python, that would almost always be a crazy choice, regardless of any positive aspects of the targeted new language. It's similar to why you should rarely throw away old code that has meaningful tests. You can slowly refactor it little by little, but wholesale switching to something else is usually evidence of wrong engineering priorities, especially when the something else is a 'latest and greatest' kind of new language or tool, like Nim is. > "Because Nim is statically compiled I can deploy pieces of it anywhere just like a compiled C program, without dependencies, and it means a lot in my particular situation." This can also be done with Cython, using the options to embed an interpreter... and there are various other third party tools that allow you to create thick binaries for combined Python programs as executables, including runtimes and dependencies. To boot, you definitely should be managing the deployment of some binaries with proper dependency management practices. So really, if you're already using dependency management techniques for the binaries, the minor extra work to maintain Python environments and dependencies would almost always be pretty trivial, with a huge family of tools (pip, conda, pipenv, virtualenv, etc.) and endless tutorials on the community-developed and mature best practices for packaging Python programs. I would be curious to know more details about a project where it was truly advantageous from a productivity and deliverability point of view to rewrite the backend to move from a stable and mature ecosystem like Python to a relatively younger and less mature system with Nim specifically to gain a benefit somehow related to ease of deploying pieces of the code to different locations. The details just don't sound like they could possibly be in favor of using Nim in a case like that.