I've tried it out and read the Nim book, but I'm not using it for any larger project right now. So here is a biased opinion.
Pros: Nim is about as easy to program as Python, has the same speed as C, a working FFI, and all the usual bells and whistles of modern "battery included" languages like a package manager with lots of packages. It is garbage collected, which is good -- about this, some will disagree, of course. It has nice high level constructs and doesn't attempt to reinvent OOP or something like that, the language is fairly straightforward. It also has a powerful macro programming facility, which is cumbersome to use though.
Cons: The community is too small and so far has not attracted CS people or many professionals, and there is the usual bulk of abandoned or undocumented packages you get with these kind of languages (more on that below). It has a few controversial syntax choices (e.g. identifier case rules) and also a number of semantic misfeatures that ease compatibility with C. It has support for native threads but no Green threads like Go, and consequently also no Green thread -> OS scheduling that would be ideal. (You'd like the language to do some flow and dependency analysis and parallelize to Green threads automatically, which are then mapped to OS threads, but AFAIK only few experimental languages can do that by now.) Its garbage collector is not optimal and not as performant as Go's, I believe. It uses whitespace for blocks, like Python.
Overall, Nim is a pretty good general-purpose programming language.
I should say that I have a long-term interest in esoteric languages and have been working on my own for a while. However, my main use case is desktop application development and unfortunately so far there is not a single new language that I would really recommend for developing desktop applications, unless you're fine with bindings to some monstruous web interfaces (Elektron, Sciter, etc.) and want to program half of your application in Javascript.
Rust, Go, Nim, Elixier, Julia, Crystal, etc. do not have GUI frameworks that are ready for prime-time use in production, except maybe for a few interfaces to web apps. Their native libraries (like Nimx for nim, duit for Go, Conrod for Rust) are unfinished, limited or simply too impractical, and bindings to Qt and wxWidgets are either undocumented, incomplete, or suffer from weird license restrictions (like a Go Qt binding I've taken a look at, I forgot its name). Some of the libraries also create monstrously large executables.
For command-line tools you can use any of them, just like thousands of other languages. For web programming, you can also use them but then there is also Common Lisp, Racket and plenty of other languages good for that. For desktop applications with modern GUI, on the other hand, you will be too limited with any of these languages and constantly chase some incomplete bindings or try to figure out how the bindings work. (Most docs for bindings simply assume that you've used the respective library a thousand times in C or C++, in case of which you could, frankly speaking, probably safe yourself the trouble and do it in C or C++ anyway.)
For this reason, I've decided to use Lazarus for my GUIs. Qt with C++ or Python is also a good choice. I also use Racket, but its native GUI is too limited, and still have hopes for Go.
I'm writing a Scheme interpreter in C++ with the express purpose of easily using Qt from it. It supports call/cc efficiently, which I hope will allow me to write Scheme programs handling GUI ops which use signals/slots behind the scenes in direct mode (basically have (potentially many) Scheme threads of execution instead of callbacks). Another thing that I'm vaguely interested in experimenting with is offering a "reactive"/functional/immediate mode layer on top of Qt with it, but I don't have enough experience yet to know how possible that will be.
The interpreter currently relies on refcounting for simplicity and to provide deterministic latency behaviour. It's (currently) a simple s-expression interpreter partially because (at least at first) I want to use it to interoperate with another Scheme system via sending s-expressions forth and back, and then that's the lowest latency option. I've got various ideas in the areas of debugging and typing that I'll try to implement, and if I succeed on that path and start wanting to use it as the main Scheme system then I'll certainly move on to compiling to byte code or use a JIT.
I just started a month ago, and have to nail down licensing with my employer, when that's settled I'll publish the code.
That's a very interesting project. Still, if you're aiming at real-world usage, please seriously consider postponing your own language+implementation (or keep it as a side project) and writing a library for Chez Scheme instead. That would be awesome.
Chez is very mature and probably the fastest Scheme available. It's so good that the Racket team is currently converting Racket to Chez as the backend language and compiler.
I know about Chez and Racket's effort. The reason I'm rolling my own is that as mentioned I've got ideas to help debugging and typing that I find easier to implement when knowing the system and the system is simple. And that I want to control GC pauses, and get easy interop with C++ (e.g. I can use Qt strings as Scheme strings that way). I also don't want to be tied into a particular Scheme implementation (e.g. some of the GUI apps that I write I will want to run client side in the browser, too). I would be happy to meet with any Chez users/implementors though to learn about its internals etc. I'm looking for Scheme and CL people to meet in London, BTW (https://www.meetup.com/London-Metaprogrammers/ - first meetup soon).
PS. consider it to be a Scheme really optimised for doing work with Qt. It appears that binding Qt well into another language is difficult (Python being about the only one where that was done successfully?), so I'm taking the approach of working "close to the metal" (C++), do things that are better done in C++ (like subclassing widgets) there, then making interfaces to scm as I go (i.e. make it so easy to make interfaces that this is a reasonable approach to do). That way I don't have to do all the work of binding the entirety of Qt, I can use qtcreator as I see fit, I can decide on a usage basis how to interface to a widget (modal in the Scheme view but not modal in Qt's view?, when does it need destruction in that case?). I guess the knowledge or abstractions coming out from this might be portable to other implementations, though.
Also again, I also do have code in another implementation (Gambit) that will have to stay there for the time being; communicating with the GUI via sexprs will of course be an indirection, but given that web programming could work the same way (the Scheme implementation on the server communicating with the one in the browser) it looks like the right approach to try for me. That will also mean that the approach will work with any Scheme implementation as the server (Chez, Chicken, whatever).
I am curious to know what you find limiting about the Racket GUI. There have been some interesting[1] things[2] being developed with it recently. I have been able to use it to write a stock trading simulator[3] with price charts.
Same as OP but posted from another account. Well, it always depends on the application. Here are the main limitations:
1. no internal drag&drop from control to control in a frame or from frame to frame, like from an editor snip to a listbox, or from a listbox item to a text field or canvas
2. text% and editor-canvas% are too slow for some applications, esp. for displaying lots of data fast or styling snips
3. text% does not allow associating arbitrary data with ranges (strange enough, list-box% has this)
4. text% uses a nonstandard format, neither RTF, XML, HTML, rich text is not easily drag&droppable or copy&pastable to other applications in a platform-compliant way without writing your own converter
5. no images in list-boxes, and generally speaking no advanced custom "grid" control (e.g. also no editable fields in list-boxes or similar table features)
6. no images in menu items
7. no toolbar, you have to make one your own and it will not be platform-compliant (macOS)
8. no docking manager or other advanced user configuration controls (we could implement these easily if we had frame-internal drag&drop, but we don't, so we can't)
9. no built-in input validation for text fields, like limiting one to integers, floats, dates, you have to do that on your own
10. it appears that some icons are not properly installed by Racket's deployment functions even if you specify them in the #:aux argument of create-embedding-executable
11. no access to tray icon
12. no way to obtain system colors from the system color scheme for custom controls, so you cannot create theme compliant custom controls
13. clipboard operations are limited (unless this has changed since I checked last time), meaning e.g. you cannot easily implement a "receiver" for some mime type data
14. related to the previous one, only whole frames can receive drag&drop objects and you basically just get a file path
That are all the points off the top of my head. For me, only 1, 3, 4, and 5 are problematic and 1 is a show-stopper. 3 is also important, since implementing this on your own can lead to a vast range of problems (you'd have to constantly maintain a data structure in sync with the snips in the editor).
It's arguably more error-prone, e.g. Rob Pike justifies Go's decision to use curly braces like so:
>Some observers objected to Go's C-like block structure with braces, preferring the use of spaces for indentation, in the style of Python or Haskell. However, we have had extensive experience tracking down build and test failures caused by cross-language builds where a Python snippet embedded in another language, for instance through a SWIG invocation, is subtly and invisibly broken by a change in the indentation of the surrounding code. Our position is therefore that, although spaces for indentation is nice for small programs, it doesn't scale well, and the bigger and more heterogeneous the code base, the more trouble it can cause. It is better to forgo convenience for safety and dependability, so Go has brace-bounded blocks.
and then you do both, indents and braces,
indents that it looks nice and braces to satisfy the machine. Then you can just omit the braces... If i would just got a penny for each time i've counted braces...
Pros: Nim is about as easy to program as Python, has the same speed as C, a working FFI, and all the usual bells and whistles of modern "battery included" languages like a package manager with lots of packages. It is garbage collected, which is good -- about this, some will disagree, of course. It has nice high level constructs and doesn't attempt to reinvent OOP or something like that, the language is fairly straightforward. It also has a powerful macro programming facility, which is cumbersome to use though.
Cons: The community is too small and so far has not attracted CS people or many professionals, and there is the usual bulk of abandoned or undocumented packages you get with these kind of languages (more on that below). It has a few controversial syntax choices (e.g. identifier case rules) and also a number of semantic misfeatures that ease compatibility with C. It has support for native threads but no Green threads like Go, and consequently also no Green thread -> OS scheduling that would be ideal. (You'd like the language to do some flow and dependency analysis and parallelize to Green threads automatically, which are then mapped to OS threads, but AFAIK only few experimental languages can do that by now.) Its garbage collector is not optimal and not as performant as Go's, I believe. It uses whitespace for blocks, like Python.
Overall, Nim is a pretty good general-purpose programming language.
I should say that I have a long-term interest in esoteric languages and have been working on my own for a while. However, my main use case is desktop application development and unfortunately so far there is not a single new language that I would really recommend for developing desktop applications, unless you're fine with bindings to some monstruous web interfaces (Elektron, Sciter, etc.) and want to program half of your application in Javascript.
Rust, Go, Nim, Elixier, Julia, Crystal, etc. do not have GUI frameworks that are ready for prime-time use in production, except maybe for a few interfaces to web apps. Their native libraries (like Nimx for nim, duit for Go, Conrod for Rust) are unfinished, limited or simply too impractical, and bindings to Qt and wxWidgets are either undocumented, incomplete, or suffer from weird license restrictions (like a Go Qt binding I've taken a look at, I forgot its name). Some of the libraries also create monstrously large executables.
For command-line tools you can use any of them, just like thousands of other languages. For web programming, you can also use them but then there is also Common Lisp, Racket and plenty of other languages good for that. For desktop applications with modern GUI, on the other hand, you will be too limited with any of these languages and constantly chase some incomplete bindings or try to figure out how the bindings work. (Most docs for bindings simply assume that you've used the respective library a thousand times in C or C++, in case of which you could, frankly speaking, probably safe yourself the trouble and do it in C or C++ anyway.)
For this reason, I've decided to use Lazarus for my GUIs. Qt with C++ or Python is also a good choice. I also use Racket, but its native GUI is too limited, and still have hopes for Go.