81–86 of 86 posts
Earlier quoted context omitted.
> exception is just a type of return value No, they are part of the syntax. The compiler (in Nim and other languages) can track which exceptions are allowed to be raised in a procedure and which aren't at compile time: https://nim-lang.org/docs/tut2.html#exceptions-annotating-pr...
And golang knows what type of error can be returned at compile time. type FatalError error func foo() FatalError {}
Noob question: differences between Nim and Crystal?
[1] https://docs.google.com/spreadsheets/d/1BAiJR026ih1U8HoRw__n...
Earlier quoted context omitted.
Perhaps, but I bet that would dissuade a very large proportion of people from trying the language.
Compared to the horror of case insensitive identifiers?
Are you really only using case to distinguish different variables? That seems more error prone.
Earlier quoted context omitted.
Significant whitespace has some real benefits (enforcing proper indentation, no lines wasted for "}" or "end", etc) too. Case insensitive and _ ignoring identifiers not so much -- they just add mental burden, encourage different styles in the same codebase, make things ungreppable without special tools, etc. And for what? If the best one can say about a feature is "people still like the language despite it", it might…
Significant indentation comes with trade-offs -- real benefits, and real detriments. I agree it's entirely understandable that a language designer would include significant indentation, such as Python's use of the off-side rule (even though I don't like it in Python). Labels (e.g. variable names) coming with style insensitivity is indeed weird, and likely to be far more off-putting for many than significant indentati…
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…
> It is a strong philosophical position, but it does allow style consistency across a code base even when dealing with foreign symbols. Every language seems to have a bizarro decision that kind of breaks it for many people. This is Nim's. It could be worse, it could be "Who need's Generics? They're costly anyway", like Go's...
> How has your experience been compared to your previous tech?
IMO. Comparing to C++, Objective-C, Java, Python, JavaScript, Python, D. Nim is an amazing language from its design standpoint. First, why we have chosen Nim for a pretty significant commercial project 2 years ago? Even though at that time Nim was not as stable as it is now, the main bet was on its hackability and compilation through C. That means a lot of things. E.g. we can fix some bugs in Nim ourselves, because the entry level is much lower than, say, with LLVM-based compiler. And if things go completely wrong and we can't fix them, we could use Nim's {.emit.} pragma to actually inject C code. A hammer of last resort :). As it turned out, there were some minor problems, but all of them were fixed pretty quickly either by our team, or by friendly Nim community. As for the language itself, it's simply amazing. These key points about efficiency and expressiveness are 200% true. But you can easily learn that from some simple pet projects.
> How mature is the standard library? How abundant are third party libraries?
The standard lib is OK, still could be polished a bit. We haven't had any critical issues with it. As for the third-party libs. Of course you can't be serious comparing Nim ecosystem to some more mainstream one, like js, python, go, you name it. During our project we had to reinvent a lot. There's an interesting observation though that things in Nim may be invented a lot faster than in aforementioned techs, but yeah, someone has to do it =).
To summarize. If you're thinking whether it is worth to start a real commercial project in Nim (the answer is of course YES! DEFINITELY! =), consider the following:
1. Of your products' 100% functionality how much can be done with third-party libs? If the answer is "you take ruby on rails, write a couple of lines of code, and done!" then unfortunately Nim is not your option yet. But if this is a game, or a backend with a lot of logic, an app with simple UI and a lot of business logic, there is a good chance that Nim is your option.
2. If this is embedded code (like firmware or driver) you'd otherwise write in C or C++, you should consider Nim in the first place.
3. If so happened that Nim is a good option for you (which is rather likely), make sure your team has one or two experienced developers which can handle unexpected issues. Such developers should be fluent with C/C++ and JS (if you're using Nim JS backend or asm.js compilers). They should know how stuff works for the case, when you need a lib which is not available in Nim, and you decide whether to bind an existing one from foreign ecosystem, or to write your own.
4. Don't be afraid of the fact that Nim is still pre-1.0. Minor things may break occasionally, but nothing that single developer could not fix in a couple of hours in a 100KLoc project. Such things happened pretty rarely in our case and they are becoming even less frequent as Nim develops.