7 ms·
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 i
by dom96 9y ago
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 Python and found myself yearning for Nim. There were multiple reasons for this, but what stuck with me was how much I missed static typing. The Python project used type hints which I found rather awkward to use (of course the fact that we didn't enforce their use didn't help, but it felt like such a half-baked solution). Dependencies very often required multiple guesses and searches through stack overflow to get working. And the resulting program was slow.
As far as I'm concerned, Nim is Python done right. It produces fast dependency-free binaries and has a strong type system with support for generics.
Of course, that isn't to say that Nim is a perfect language (but then what is). For example, JetBrains has done a brilliant job with PyCharm. Nim could use a good IDE like PyCharm and with its strong typing it has the potential to work even better.
> How mature is the standard library?
To be honest the standard library does need some work. In the next release we do plan on making some breaking changes, but we always lean on the side of keeping compatibility even though Nim is still pre-1.0. Of course, sometimes this is not possible.
> How abundant are third party libraries?
Not as abundant as I would like. Great news is that you can help change that :)
The Nimble package manager is still relatively new, but you can get a pretty good idea of the third party libraries available by looking at the package list repo[1].
Hope that helps. Please feel free to AMA, I'd love to introduce you to our community.
1 - https://github.com/nim-lang/packages/blob/master/packages.json https://github.com/nim-lang/packages/blob/master/packages.js...
- vitiral 9y agoThanks 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.
- dom96 9y agoHappy 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 powerful * Lack of (official) package manager
- sepisoad 9y ago* 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 do a single task and that sometimes is confusing. BTW C/Go/lua are my languages of choice
- joobus 9y agoBeing fluent in Python and Go, I definitely prefer the explicit error handling in Go as opposed to the try-catch error handling in python where most of the time you can never really be sure of all the possible errors which can be thrown. I spent some time learning Haskell, and one of the points that stuck was that in languages with exception handling, a function will have some kind of declared result, but all the different exceptions which can be thrown are also basically alternative return values. Any caller of the function then has to know all possible return types to effectively handle all errors, but since most code doesn't document which errors might be thrown, it's a crap shoot. Functional languages basically force the return to always be the declared type, and go mostly follows this model.
- jboy 9y agoEven though I don't like Go's explicit error handling, I think this is a very reasonable comment. I don't like Go's explicit error handling because (1) I think it clutters up your main code path with error-handling logic, and (2) it forces you to always handle errors locally (even if that local code does not have the context to know how to handle the error) or return the error code through multiple layers of functions (back to where it can be handled). That said, I completely agree that exceptions are also problematic. As you say, you can never really be sure of what exceptions can be thrown. Some languages have a "throw" keyword, in which you're meant to enumerate the list of possible exceptions; but of course, that's a headache to maintain, and is affected by inner code (such as library code) that might be completely out of your control or review. And when should the "throw" keyword be enforced, at compile time or runtime? And what should happen if the "throw" keyword's list of possible exceptions is violated? Then of course there is the other problem with exceptions, the flip-side to being forced to handle an error locally: As your exception unwinds the stack, it might obliterate some local context that is needed to decide how to handle the error; or it might obliterate some local context that is needed to continue with your original task after the error has been handled! The most interesting (and least broken) error-handling mechanism I've encountered is Common Lisp's "condition" system: http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html http://www.gigamonkeys.com/book/beyond-exception-handling-co... I see C++'s `std::set_new_handler` function [0] as C++'s less-capable equivalent to Lisp condition handlers. But the function invoked by `std::set_new_handler` lacks the ability to assess local context to decide how to handle the problem. [0] http://www.cplusplus.com/reference/new/set_new_handler/ http://www.cplusplus.com/reference/new/set_new_handler/ EDIT: I would love to see a language like Nim incorporate something like Lisp's condition system. Nim already offers "procedural types" (function pointers) [1] and closures [2] to capture variables from the enclosing scope. Nim even offers "anonymous procs" [3], to avoid the need to define new error-handling functions everywhere. [1] https://nim-lang.org/docs/manual.html#types-procedural-type https://nim-lang.org/docs/manual.html#types-procedural-type [2] https://nim-lang.org/docs/manual.html#procedures-closures https://nim-lang.org/docs/manual.html#procedures-closures [3] https://nim-lang.org/docs/manual.html#procedures-anonymous-procs https://nim-lang.org/docs/manual.html#procedures-anonymous-p...
- sharmi 9y agoThan you. I currently work in python, so your answer is relateable. What do you think is the best resource to start learning Nim? Edit: I just found from your profile, you are tha author of vim in action! I suppose that is where I start!
- michaelcampbell 9y ago> It produces fast dependency-free binaries It does use glibc, right?
- bruce_one 9y agoThe little bit of nim I've done used musl rather than glibc. I think it's moderately flexible to what is used because it transpiles to c first (afaik?)
- dom96 9y agoIndeed. It compiles to C so you have a lot of flexibility. glibc/musl isn't much of a dependency (except when you compile on a newer glibc leading to issues [1]), but I am still amazed at how easily I was able to produce a cross-platform executable for Windows (XP+ !!), macOS and Linux[2]. 1 - https://github.com/dom96/choosenim/issues/15 https://github.com/dom96/choosenim/issues/15 2 - https://github.com/dom96/choosenim/releases https://github.com/dom96/choosenim/releases
- sharmi 9y agoI 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 case-insensitive right? (That means only the first letters are compared in a case sensitive manner. Other letters are compared case insensitively and underscores are ignored.) Does it hinder when you need to do refactoring? Also, I work in vim, and grep for stuff when I need. I am not sure if autosuggests and locating definitions/usage for variables would work. I am sure I must be wrong as I believe the core developers would have thought about it :) I just would like to know how
- girvo 9y agoBecause 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
- ddlsmurf 9y agoIdentifiers 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 symbols.
- jsjsjsjsjsjs 9y ago> Nim could use a good IDE like PyCharm Yes indeed. I for instance can not wait Kotlin-native to materialize because... Because Kotlin has a usable IDE already. Nim is a great language, although rough on the edges. Add lack of libraries or need of wrapper generation to the equation, also add lack of a decent IDE.. I am privileged enough to have liberty of picking my battles so one of my requirements for getting work done is to also feel a pleasure doing it. Writing nim code in a notepad which has some IDE features that may or may not work (auto-complete from nimsuggest is really iffy, in source code of compiler especially) is suboptimal. Add debugging experience which due to various reasons is not greatest.. It is hard to justify using Nim over c++ or python. It is a shame though because language is really nice and with some polish it could be a great alternative to already established languages. Keeping fingers crossed for some brave soul coming forward and making IntelliJ plugin for nim.