21–30 of 86 posts
Earlier quoted context omitted.
Because Nim has an excellent 'compiler service', the symbols can be identified at the AST level instead of the textual level. In practice, most code bases stick to some conventions, and the possible ambiguity is rarely an issue, in my experience
Is there a style guideline for nim like pep8?
Earlier quoted context omitted.
Thanks for being honest with everything, I found this to be a very balanced answer. What would you say are the advantages of Nim over a language like Go? I see a lot of similar "value add" statements.
Happy to hear that you found my answer balanced :) > What would you say are the advantages of Nim over a language like Go? I see a lot of similar "value add" statements. In all fairness I haven't given Go a proper try. But my main problems with it, based on what I've seen of it, are the following: * Lack of generics * Lack of exceptions * I prefer the Python-like syntax of Nim * Metaprogramming in Nim is fun and powe…
* Lack of generics
* Lack of exceptions
BTW C/Go/lua are my languages of choice
(As you can see, I was one of the authors of that library in a previous startup. We haven't worked on Nim-Pymod in a while, alas -- I've been focused on the new startup! -- but Nim-Pymod is sufficient for our needs right now.)
Our webserver main-loops are in Python; our number-crunching ML/CV/img-proc code is Python extension modules written in Nim.
As a C++ & Python programmer, I'm a huge fan of Nim, which to me combines the best of both languages (such as Python's clear, concise syntax & built-in collection types, with C++'s powerful generics & zero-cost abstractions), with some treats from other languages mixed in (such as Lisp-like macros and some Ruby-like syntax). I find Nim much more readable than C or C++, especially for Numpy integration. I also find Nim much more efficient to code in than C or C++ (in terms of programmer time).
And Nim is a very extensible language, which enables Nim-Pymod to be more than just a wrapper. For example:
1. Nim-Pymod uses Nim macros (which are like optionally-typed Lisp macros rather than text-munging C preprocessor macros) to auto-generate the C boilerplate functions around our Nim code to create Python extension modules.
2. Nim-Pymod provides statically-typed C++-like iterators to access the Numpy arrays; these iterators include automatic inline checks to catch the usual subtle array-access errors. Nim macros are themselves Nim code, which can be controlled via globals, which in turn can be set by compiler directives; by compiling the Nim code in "production" mode rather than "debug" mode after testing, we can switch off the slowest of these checks to get back to direct-access speed without needing to make any code changes. (And of course Nim's static typing catches type errors at compilation time regardless of the compilation mode.)
3. Nim exceptions have an informative stack trace like Python exceptions do, and Nim-Pymod converts Nim exceptions into Python exceptions at the interface, preserving the stack trace, meaning you have a Python stack trace all the way back to the exact location in your Nim code.
Earlier on in our development of Nim-Pymod, there were some occasional headaches with Nim due to its in-development status. Occasionally the Nim syntax would change slightly and that would break our code (boo). We've also debugged a few problems in the Nim standard library. I suppose these problems are an unfortunate consequence of Nim having a small set of core devs contributing their time (rather than being supported by Microsoft, Sun, Google or Mozilla). Fortunately, these problems seem to have stabilised by now.
The Nim standard library is reasonably large, somewhere between C++ STL (data structures & algos) & Python stdlib (task-specific functionality). I recall that the stdlib could use some standardisation for uniformity, but I haven't been watching it closely for the last year or so.
Third party libraries are not abundant, aside from a handful of prolific Nim community-members who have produced dozens of fantastic libraries (eg, https://github.com/def- , https://github.com/dom96 , https://github.com/fowlmouth , https://github.com/yglukhov ).
I'm happy to answer any other questions about using Nim in production!
Earlier quoted context omitted.
Happy to hear that you found my answer balanced :) > What would you say are the advantages of Nim over a language like Go? I see a lot of similar "value add" statements. In all fairness I haven't given Go a proper try. But my main problems with it, based on what I've seen of it, are the following: * Lack of generics * Lack of exceptions * I prefer the Python-like syntax of Nim * Metaprogramming in Nim is fun and powe…
* Lack of generics * Lack of exceptions I don't see these items as being shortcomings. Go is simple and simplicity is elegance, and simplicity is something that cannot be found in most modern languages. Just look what happened to C++, It has become more like C# and Java. Regarding Nim, I believe it's a nice language and I have done a few small projects using it but just like what I mentioned there are 10000 ways to d…
Earlier quoted context omitted.
I love the simple and clean syntax of Nim. The first time I was very impressed with vim was when I used a wikipedia xml dump parser. What would have literally taken days to complete in Python (atleast on my machine, and god forbid if it had crashed somewhere in the middle) was done in a few mins by nim (again on the same machine). I was blown away! The one thing that concerns me a bit is that identifiers are partial…
Identifiers are "style-insensitive", so case changes and single underscore insertions don't actually change the identifier. There is exhaustive tooling such as nimgrep and ide support built into the compiler (such as find symbol at point equivalents) for helping when a convention is different. It is a strong philosophical position, but it does allow style consistency across a code base even when dealing with foreign…
Earlier quoted context omitted.
Identifiers are "style-insensitive", so case changes and single underscore insertions don't actually change the identifier. There is exhaustive tooling such as nimgrep and ide support built into the compiler (such as find symbol at point equivalents) for helping when a convention is different. It is a strong philosophical position, but it does allow style consistency across a code base even when dealing with foreign…
Wouldn't it have been better to just enforce one style over all nim code?
Judging by the upvotes there is a lot of interest in hearing answers to this question and yet there are few comments so far. I will share my thoughts but keep in mind that I am (extremely) biased as I am one of the core Nim devs. > How has your experience been compared to your previous tech? Previous to using Nim I was primarily using Python. This was a few years ago now, but recently I was working on a project in Py…
I love the simple and clean syntax of Nim. The first time I was very impressed with vim was when I used a wikipedia xml dump parser. What would have literally taken days to complete in Python (atleast on my machine, and god forbid if it had crashed somewhere in the middle) was done in a few mins by nim (again on the same machine). I was blown away! The one thing that concerns me a bit is that identifiers are partial…
My Vim config for Nim can be found here: https://github.com/jboy/dotfiles/tree/master/vim (based upon https://github.com/zah/nim.vim , with a few improvements to my taste).
In particular, Vim syntax highlighting for Nim: https://github.com/jboy/dotfiles/blob/master/vim/syntax/nim.... and some convenient Vim mappings to jump around in Nim: https://github.com/jboy/dotfiles/tree/master/vim/ftplugin/ni...
I also use (and recommend) the CamelCaseMode Vim plugin with Python & Nim.
> How has your experience been compared to your previous tech? Having used Python, Go, C, Perl, Java, Nim is a breeze to code in. Occasionally the compiler glitches and you have to delete nimcache. Very rarely it fails to compile something and you have to rewrite few lines differently. Not an issue. Build frequently to avoid any surprise. > How mature is the standard library? Not that much: it lacks examples and help…
This is a huge issue. If you can't trust the compiler, it's not ready to be used for any function that is system critical.
Earlier quoted context omitted.
Thanks for being honest with everything, I found this to be a very balanced answer. What would you say are the advantages of Nim over a language like Go? I see a lot of similar "value add" statements.
Happy to hear that you found my answer balanced :) > What would you say are the advantages of Nim over a language like Go? I see a lot of similar "value add" statements. In all fairness I haven't given Go a proper try. But my main problems with it, based on what I've seen of it, are the following: * Lack of generics * Lack of exceptions * I prefer the Python-like syntax of Nim * Metaprogramming in Nim is fun and powe…
Go does support multiple return values, commonly (T, error). If you think about it for a while, you will realize a exception is just a type of return value.
Regarding generics, the more I used golang, the less I had a need for generics. Also, there is solutions if you insist, such as https://github.com/cheekybits/genny