As Nim is approaching maturity in the public eye,
I claim that as a language, it has been mature for a long time.
However, in terms of documentation and standard lib, it hasn't been.
For the end user of the language, when you try to solve a real world problem, in this regard it is still immature.
It doesn't handle all the use cases that a user wishes to do with a language. Which are the areas most lacking?
Users can get stuck for lack of documentation, for lack of examples, for lack of functionality for a particular use case, or just a whole use case area that is simply unsupported.
What were you recently trying to solve, where you got stuck or was unclear about how to approach or advance with the available Nim resources?
What are the confusions, and which domains Nim doesn't have anything to show for?
I think surfacing these issues will let us see clearly what is missing, and prioritizing better.
Too often language fans attempt to see the issue from a boss point of view, or from acceptance or stability guarentees point of view, where really sometimes users leave or stay in a language, simply for being able to provide them with a quick way to get things done.
Nim is the best programming language I know, so let's make it obstacle free.
Please discuss :-)
The main obstacle for stdlib improvement is that, currently, it is distributed as part of the compiler.
Which means that stdlib evolution is linked to compiler evolution. That's a core issue because then if you need to fix a bug in the stdlib, you necessarily have to upgrade the compiler.
This is currently the main obstacle to improving the stdlib. See https://forum.nim-lang.org/t/7983 for more details.
As long as this is not solved, (breaking) changes in the stdlib will be difficult.
Nimble is a package manager, a project manager, a compiler wrapper, a project linter, but it doesn't cover all the details for every aspect.
It works, but I think it would be better to have a clear separation of the features offered by the tools
I’ve also suffered a few odd problems such as std/prelude not working for me and things like that. Nothing major but you can tell there are still a few rough edges here and there.
That being said, there are _a lot of great things about nim! Once these are improved (I’m particularly excited about the upcoming IC support) it will be incredible.
Use --verbosity:2 to be able to see the exact error
Incremental compilation is an in development feature
For debugging, you can use nim_gdb with gdb to debug properly.
For prelude, did you include prelude or import prelude
My experience with Nim:
The core of the language is mature and good (I personally would like to have a more auto infer, but it's ok as it is).
Macros is mature, but hard to use for a seasonal developer (who use Nim only 20% of the time). Every time I use complex macros I regret it later. You look at macros code you wrote couple of months ago and thinking "how it works?" or "how to fix or modify it?". Too hard to use. I try to avoid macros as much as possible.
STD not bad, better than Java/JS, but nowhere near as good as say Ruby/Elixir.
Parallel seems immature, it kinda works, but there are surprises and in its current state it's mostly for experts, not ordinary developers.
Fast IO currently available as Async IO. Works, but too many surprises. What you do with Node.JS in an hour may require days spent on debug in Nim Async IO.
Servers immature, too much unexpected crashes, don't know if it's my mistakes or some leaks.
Verbosity 2 enables --hint:source so you can also just pass that and get fewer messages.
var a: 10
/tmp/tmp.nim(1, 8) Error: type expected, but got: 10
var a: 10
^
Better type inference would require the Hindley-Milner algorithm or similar, which is incompatible with Nim's type system.
As for macros, complexity is like energy — you can move it to different places, but the total amount stays constant.
I like --verbosity:2! Didn't know this. FYI anyone using it, hints must not be disabled.
I empathize with the observations above. In the 5 years I've been using nim personally and professionally, there are certain rough edges that keep me from recommending it to most people, except for the occasional person who I know is okay with bleeding edge technologies and willing to go through a lot of learning pain. By the way, Nim v1.6 is amazing! Well done nim-dev community.
Because I personally have no "loyalty" for Nim, I am periodically on the lookout if there is a better tool for the job. However, it's amazing to me that in 5 years of evaluating new tools I still think Nim is on the right track for being best in Pareto front of all the qualities I personally care about, and I'm so impressed @Araq had this vision and made it happen. The community is small, progress commensurately slow-ish compared to gargantuan communities, but the immediate utility, trajectory, leadership, and community of Nim are all fantastic. You have a lot to be proud of.
I'd like to contribute some details to the OP's topic of Rough Edges in Nim Workflows.
For some reason the available learning materials each feel a bit lacking in different ways, only sufficing when taken in aggregate. But maybe this is because Nim has quite a depth to it, necessitating specialized/modular learning resources that could benefit from a better overall curated meta-structure. The nim-lang/documentation page is already quite good... The best way I've learned Nim is by reading the manual many, many, many times, and reading/contributing on the forum. I would love to see a community book, like an open source version of @dom96's book. (It's still one of the best introductory resources, and I suggest everyone to get a copy for themselves and also help support @dom96 and efforts!) Perhaps even just an update of @dom96's book to include a "go here or there to learn more about ____ advanced topic" would be great. For instance, my best guess to learn c2nim workflows is by trying to find existing projects with documentation of their c2nim process - this is hard for me to find.
In every language there are ways to shoot yourself in the foot with poor practices or thoughtless uses of the flexibility a language provides. I feel like Nim has this danger a bit more than other languages, yet there is no large upfront emphasis on best practices: "there be dragons, please do it this way unless you know better." The best I've seen is the detailed pros/cons analysis of practices in Nim by Status.im, some of which obviate complete features of the language in the name of better debugging and less confusion. This kind of insight isn't clear when learning Nim at the outset, but I feel like Status.im's detailed considerations are generally important to most developers and clearly they have been won through quite a bit of in-the-trenches experience. I would love to see more of this enter into introductory material.
Often, I am a bit confused by the errors, and must read the error carefully, then my code carefully, then apply all my Nim knowledge in order to understand what is going on. Simply forgetting to import a library results in some slightly confusing output, whereas something like Clang for C++ will say "actually, that's defined in <blah> did you forget to include it?" which saves some thinking for the harder stuff. Having said this, the new-to-me --spellSuggest default output is really great! I don't really know how long it's been there, but it's fantastic.
I'm really looking forward to Incremental Compilation, default ORC, and auto-bundled external stdlib.
I wish choosenim was a more obvious primary way to install nim, to make introduction to novices more uniform. Maybe there's an implication here that I don't understand, making this not feasible for choosenim to be in distro repos and such. Even rust has a similar problem because someone made the rust package so figured that's what I'd install. Then an hour later trying to figure out why my code isn't working, only for a colleague to tell me "your rust is super old - no one installs rust, use rustup."
As everyone knows, the IDE experience is good, but not great, and sometimes awful (why is my CPU maxing out?!) Trying to put my donated effort where my selfish interest is, I did submit a PR to fix a thing for VSCode Nim, and it got lost in a higher-up discussion about how best to fix it, which is fine - I can only hack ham-handedly at JS.
Okay, I don't think even Rust has this, but Python, Processing, XCode, and Visual Studio do. That is, download one single thing that either configures itself or comes with everything already for a complete smooth IDE experience. Such a package for Nim might include: Visual Studio Code portable, Nim, Zig (for compiling), and VSCode Nim plugin. A prolific coder colleague of mine had the most extreme attitude -- that I don't agree with but was interesting to observe -- when he tried Nim on OSX: "if it's not single file drag-n-drop install like XCode, then they aren't putting in the effort to make it accessible, [and I'm not touching it until then]" I don't think most people are that extreme, but I can see the merit of his point, and I think we definitely have the technology to make this happen with not a lot of effort once other parts of Nim are more similarly polished.
Thank you @ynfle, I did not know about --verbosity. Unfortunately, that makes name even more verbose (duh!) so it makes the "problem" (if you can call it that) even worse. Using --hint:source is better, but it does not seem that it works in combination of --hints:off? What I'd like is to minimize the (non warning / error related) hints but get the actual line of code that caused the error or warning on nim's output. Is that possible?
Thank you as well for the "include prelude" hint. I was using "import prelude". I have some thoughts about that but that can go into a separate thread.
Regarding the debugging experience, I have not tried nim_gdb. Does it work on windows? IMHO what would really take nim to the next level (debugging wise) would be to get debugging support on VS Code.
@ggibson, you captured perfectly my thoughts with your "ambiguous or confusing compiler errors" comment. It's not that the error messages are bad but that sometimes they require a lot of nim knowledge to understand them. This makes them not that helpful sometimes unless you really know what you are doing (which unfortunately is not my case yet).
As an example, the errors that you get when you do "include std/prelude" instead of "import std/prelude" make sense once you know what the problem is but they did not help me detect the problem until @ynfle pointed it out to me.
Regarding the nim-gdb script.
I only works if you have a compatible readlink (I don't on macos) and a GDB built with Python support, which I have learned that many that are pre-built for Windows do not.
See the following links for more discussion about it and workarounds for loading the nim-gdb.py script without using the nim-gdb script (if you do in-fact have a GDB with Python support):
The more C/C++ you know the better armed you will be to tackle the interop situation. It isn't well documented, because if someone don't understand how a C/C++ compiler and linker work, it is difficult to explain how to effectively use the interop feature set to them. This is why projects like furthark and nimterop, etc... came about - to ease some of this and to help automate the maintenance of bindings.
C++ is more difficult than C. JS is actually really easy...
It also fails to effectively attract the newcomer - it just mentions a bunch of languages most new programmers have never heard of (minus Python) and refers to a bunch of terms they're not going to understand. It fails to capture why anyone should really use Nim and instead shows fun things you can do with Nim that newcomers aren't going to understand and seasoned system programmers aren't going to care about.
Perhaps the point that makes me most sad is the little evolution I noticed in the asynchronous modules. Since I met Nim until today, I see such information in the asyncdispatch package: "The async procedures also offer limited support for the try statement....Unfortunately the semantics of the try statement may not always be correct, and occasionally the compilation may fail altogether. As such it is better to use the former style when possible". It's been 4 years and it's still there.
Very fair point. Indeed the docs for that module have really bitrotted. This statement is no longer valid since @yglukhov resolved issues with try statements inside closure iterators (which async/await utilises).
I've put up a PR with a quick fix here: https://github.com/nim-lang/Nim/pull/19108. Ideally these docs need to be significantly rewritten. :)
In general async/await in Nim works very well for the vast majority of use cases, it just needs some love to iron out the rough edges. I've documented the priorities here: https://github.com/nim-lang/RFCs/issues/304. But as usual, we just need folks to help with the implementation. If you're interested in helping please do get in touch :)
Maybe there isn't much documentation beyond the examples included in the docs, but there are plenty of easily found examples on github if you know how to search on github effectively. If not I highly suggest you learn to use github's code search features. It's basically how I learned to program in Nim / answer my questions about how to do things in Nim when I couldn't get answers from the community or when the community was almost exclusively European and getting help during US evenings / nights was very difficult.
Also because I do advanced game engine development with Nim, I often need to do things that not many other folks are doing, if any. Often times there is very little code or no code on github showing how to do what I need to. This is not at all the case with C/C++ interop.