14 ms·

I feel like the author dismissed Nim pretty unfairly. Github stars and issues are one signal for a project status, but its hardly conclusive. Nim's development

I feel like the author dismissed Nim pretty unfairly. Github stars and issues are one signal for a project status, but its hardly conclusive. Nim's development has been pretty consistent and is approaching 1.0. Ultimately, a lot of language choice is subjective, but I think anyone looking for a language in the fast-but-expressive category should at least try Nim.

gtycomb 8y ago
I agree. I am taken by surprise at the all-round strong performance of Nim. Python-like syntax, a pleasing type system, efficient compilation and packaging. I am waiting to hear more on this. As I understand it they are a small team too and their implementation is truly worth following up.
rishav_sharan 8y ago
I came to Crystal from Nim. I really like Nim. But I feel that the language maintainers do not have an idea on how to grow the ecosystem. Even after all these years, Nim doesn't have any good web framework. Jester, is the only one I know of has no website of its own and is very lacking in documentation.
- dom96 8y ago
  Hi, one of the Nim core devs here. Any ideas how we can fix that? Crystal has a surprising amount of web frameworks with great marketing behind them. Could that just be because it's a Ruby-like language, and Rubyists are far more interested in web frameworks? That's my theory, but I could be totally wrong. I'd love to know how we could improve here. Perhaps it's because I created a web framework that is good enough (jester) early on and so nobody feels like stepping in with their own implementation. A website for jester would be great and it is on my to-do list, but so are many more things.
  - brokencode 8y ago
    Personally, the first thing I look at when I look into a new server side language is how it does in benchmarks conpared to other similar languages (such as the TechEmpower benchmarks). I know that those types of benchmarks are flawed in a lot of ways, but performance is probably the only objective way to evaluate a language, and I’m much more likely to learn about a language if it looks like it’s fast. From what I’ve seen for Jester/Nim, it’s not really benchmarked a lot, and it doesn’t seem particularly fast where it is benchmarked. This could perhaps be fixed by better implementations for the benchmarks or some optimization in Jester itself. I think a strong story for performance would go a long way towards improving awareness of Nim. Crystal does very well in such tests, and I think that is one of the most appealing parts of the language. In fact, I evaluated both Nim and Crystal for server side development a while back, and quickly dismissed Nim because it didn’t seem to be all that fast. I eventually dismissed Crystal too because of the compile times and syntax, but I put a lot more time into it.
    - dom96 8y ago
      I would say that you should look at the language's theoretical performance as much as its actual performance. A lot of these benchmarks are just a result of someone putting in a lot of time tweaking things until they are perfectly suited to the specific benchmark, in real-life you will get nowhere near that. Additionally, you won't actually need to get anywhere near it. If you do, then you will have the time to tweak things and get to know the language inside out. In that case, all that will matter is the theoretical performance of that language. So what do I mean by theoretical performance? Well, Nim is a statically typed and compiled language, it stands to reason that these attributes make it very performant indeed. Even if certain aspects of the language are not efficient right now, you can bet that it will be fairly trivial to improve their performance. For languages like Python, Ruby, etc. you are heavily limited by the dynamic typing (which restricts the amount of information you have about the code) and the fact that they are primarily interpreted languages. You will need to put far more effort into optimising them than compiled languages. As a side note, I do intend to improve the performance of Jester as well. But I'm not the only one doing this, the mofuw framework is #24 on the TechEmpower benchmarks right now.[1] 1 - https://twitter.com/nim_lang/status/1004849910699712513 https://twitter.com/nim_lang/status/1004849910699712513
  - bb88 8y ago
    The very first thing should be a package manager, with packages behind a CDN, so I can go between development and deployment easier.
    - dom96 8y ago
      huh? Nim has a package manager, not sure what you mean.
      - bb88 8y ago
        Apologies. I meant production ready package manager. The one I'm aware about is in beta. https://github.com/nim-lang/nimble https://github.com/nim-lang/nimble
  - gtycomb 8y ago
    Thanks for asking. I had stopped looking at newer languages long time ago and I can't tell quite how I decided to check out this Nim. Perhaps its finding your well written book, Nim in Action. Nim language has this one characteristic that means a lot to me -- to be able to learn the core concepts very quickly enough to get productive in some of the routine work (back-end system interactions, distributing compiled modules to other locations, numerical/data processing). Nim won my heart in this regard hands-down. Well, along the lines of what is already mentioned, I stumbled on web communication aspects (I like the available template system, it performs well) and ran into glitches with the mongo or postgresql drivers as I got deeper. I am glad that Nim doesn't have a Ruby-like syntax -- Nim's current type structure/syntax is its strength, IMHO. (I wanted to contribute some money to the team but PayPal is the only option even if the site says it can take Visa etc. PayPal is something that I avoid due to past experiences)
    - dom96 8y ago
      > Perhaps its finding your well written book, Nim in Action. Thanks! :) > I wanted to contribute some money to the team but PayPal is the only option even if the site says it can take Visa etc. PayPal is something that I avoid due to past experiences There are many ways to donate to us, I guess we need to spruce up the donation page, the "Other ways to donate" is buried at the bottom: https://nim-lang.org/donate.html https://nim-lang.org/donate.html
freedomben 8y ago
Definitely. He dismissed it mostly because he doesn't like camelCase? seems like a silly reason to dismiss a language. I've been around enough different ecosystems to know that style is something you get used to. snake case, camel case, same-line curly brace, give it a few weeks and you won't really notice. It's a silly reason to dismiss a language.
- fgimian 8y ago
  True, I REALLY hate camelCase though ... hahaha But seriously, I do need to spend more time on Nim and give it a fair chance on a project :) Ultimately, I had to choose something to commit to for a while as there are just not enough hours for me to learn multiple new languages outside of work and with my various other hobbies. But rest assured that Nim was absolutely a front-runner and I'm happy to update the post to reflect this.
  - beagle3 8y ago
    > True, I REALLY hate camelCase though ... I do too, and that's exactly why you should use Nim. It is, perhaps, the only language in which the variables "camelCase", "camelcase" and "camel_case" are the same (though CamelCase isn't) -- so you don't have to follow braindead Java principles if you don't like them.
    - skocznymroczny 8y ago
      I'd consider it even worse. I like consistency in my codebases. Good luck grepping for variable, when half of the folks will use variable_name, the other half will use variableName and the last half will do variablename.
      - mcbits 8y ago
        People still grep for variables in $current_millennium? I have to agree with the other comment about tooling being an important factor in language selection.
      - 8y ago
siddhant 8y ago
Nim is pretty amazing. I spent last week writing some toy programs and it reminded me of Python - in the sense that it allowed me to write working code within a few hours of picking up the language. The “optional namespaces” thing is something which bugs me a lot though. That importing a module works similar to `from module import *` in Python. It makes code confusing to read and grasp IMO (which module does this symbol come from?). Other than that, a pretty cool language.
- dom96 8y ago
  > The “optional namespaces” thing is something which bugs me a lot though. That importing a module works similar to `from module import *` in Python. It makes code confusing to read and grasp IMO (which module does this symbol come from?). Other than that, a pretty cool language. This is a common complaint, but there is rarely a solution proposed alongside the complaint. Nim is significantly different from Python to warrant these semantics, but I am really open to hearing ideas of how this could be improved keeping in mind these differences (operator overloading, no classes). A recent proposal was made here, and it looks like it will be adopted, I'd love to know what you think about it: https://forum.nim-lang.org/t/3783 https://forum.nim-lang.org/t/3783
fgimian 8y ago
You're right about this point. I really should have spent more time on Nim, and I still intend to. In fact, Nim was my main choice prior to learning about Crystal. So no offence intended at all to any Nim fans, and I hope to dive into it more thoroughly in the near future.

gtycomb 8y ago

I agree. I am taken by surprise at the all-round strong performance of Nim. Python-like syntax, a pleasing type system, efficient compilation and packaging. I am waiting to hear more on this. As I understand it they are a small team too and their implementation is truly worth following up.

rishav_sharan 8y ago

I came to Crystal from Nim. I really like Nim. But I feel that the language maintainers do not have an idea on how to grow the ecosystem. Even after all these years, Nim doesn't have any good web framework. Jester, is the only one I know of has no website of its own and is very lacking in documentation.

dom96 8y ago
Hi, one of the Nim core devs here. Any ideas how we can fix that? Crystal has a surprising amount of web frameworks with great marketing behind them. Could that just be because it's a Ruby-like language, and Rubyists are far more interested in web frameworks? That's my theory, but I could be totally wrong. I'd love to know how we could improve here. Perhaps it's because I created a web framework that is good enough (jester) early on and so nobody feels like stepping in with their own implementation. A website for jester would be great and it is on my to-do list, but so are many more things.
- brokencode 8y ago
  Personally, the first thing I look at when I look into a new server side language is how it does in benchmarks conpared to other similar languages (such as the TechEmpower benchmarks). I know that those types of benchmarks are flawed in a lot of ways, but performance is probably the only objective way to evaluate a language, and I’m much more likely to learn about a language if it looks like it’s fast. From what I’ve seen for Jester/Nim, it’s not really benchmarked a lot, and it doesn’t seem particularly fast where it is benchmarked. This could perhaps be fixed by better implementations for the benchmarks or some optimization in Jester itself. I think a strong story for performance would go a long way towards improving awareness of Nim. Crystal does very well in such tests, and I think that is one of the most appealing parts of the language. In fact, I evaluated both Nim and Crystal for server side development a while back, and quickly dismissed Nim because it didn’t seem to be all that fast. I eventually dismissed Crystal too because of the compile times and syntax, but I put a lot more time into it.
  - dom96 8y ago
    I would say that you should look at the language's theoretical performance as much as its actual performance. A lot of these benchmarks are just a result of someone putting in a lot of time tweaking things until they are perfectly suited to the specific benchmark, in real-life you will get nowhere near that. Additionally, you won't actually need to get anywhere near it. If you do, then you will have the time to tweak things and get to know the language inside out. In that case, all that will matter is the theoretical performance of that language. So what do I mean by theoretical performance? Well, Nim is a statically typed and compiled language, it stands to reason that these attributes make it very performant indeed. Even if certain aspects of the language are not efficient right now, you can bet that it will be fairly trivial to improve their performance. For languages like Python, Ruby, etc. you are heavily limited by the dynamic typing (which restricts the amount of information you have about the code) and the fact that they are primarily interpreted languages. You will need to put far more effort into optimising them than compiled languages. As a side note, I do intend to improve the performance of Jester as well. But I'm not the only one doing this, the mofuw framework is #24 on the TechEmpower benchmarks right now.[1] 1 - https://twitter.com/nim_lang/status/1004849910699712513 https://twitter.com/nim_lang/status/1004849910699712513
- bb88 8y ago
  The very first thing should be a package manager, with packages behind a CDN, so I can go between development and deployment easier.
  - dom96 8y ago
    huh? Nim has a package manager, not sure what you mean.
    - bb88 8y ago
      Apologies. I meant production ready package manager. The one I'm aware about is in beta. https://github.com/nim-lang/nimble https://github.com/nim-lang/nimble
- gtycomb 8y ago
  Thanks for asking. I had stopped looking at newer languages long time ago and I can't tell quite how I decided to check out this Nim. Perhaps its finding your well written book, Nim in Action. Nim language has this one characteristic that means a lot to me -- to be able to learn the core concepts very quickly enough to get productive in some of the routine work (back-end system interactions, distributing compiled modules to other locations, numerical/data processing). Nim won my heart in this regard hands-down. Well, along the lines of what is already mentioned, I stumbled on web communication aspects (I like the available template system, it performs well) and ran into glitches with the mongo or postgresql drivers as I got deeper. I am glad that Nim doesn't have a Ruby-like syntax -- Nim's current type structure/syntax is its strength, IMHO. (I wanted to contribute some money to the team but PayPal is the only option even if the site says it can take Visa etc. PayPal is something that I avoid due to past experiences)
  - dom96 8y ago
    > Perhaps its finding your well written book, Nim in Action. Thanks! :) > I wanted to contribute some money to the team but PayPal is the only option even if the site says it can take Visa etc. PayPal is something that I avoid due to past experiences There are many ways to donate to us, I guess we need to spruce up the donation page, the "Other ways to donate" is buried at the bottom: https://nim-lang.org/donate.html https://nim-lang.org/donate.html

freedomben 8y ago

Definitely. He dismissed it mostly because he doesn't like camelCase? seems like a silly reason to dismiss a language. I've been around enough different ecosystems to know that style is something you get used to. snake case, camel case, same-line curly brace, give it a few weeks and you won't really notice. It's a silly reason to dismiss a language.

fgimian 8y ago
True, I REALLY hate camelCase though ... hahaha But seriously, I do need to spend more time on Nim and give it a fair chance on a project :) Ultimately, I had to choose something to commit to for a while as there are just not enough hours for me to learn multiple new languages outside of work and with my various other hobbies. But rest assured that Nim was absolutely a front-runner and I'm happy to update the post to reflect this.
- beagle3 8y ago
  > True, I REALLY hate camelCase though ... I do too, and that's exactly why you should use Nim. It is, perhaps, the only language in which the variables "camelCase", "camelcase" and "camel_case" are the same (though CamelCase isn't) -- so you don't have to follow braindead Java principles if you don't like them.
  - skocznymroczny 8y ago
    I'd consider it even worse. I like consistency in my codebases. Good luck grepping for variable, when half of the folks will use variable_name, the other half will use variableName and the last half will do variablename.
    - mcbits 8y ago
      People still grep for variables in $current_millennium? I have to agree with the other comment about tooling being an important factor in language selection.
    - 8y ago

siddhant 8y ago

Nim is pretty amazing. I spent last week writing some toy programs and it reminded me of Python - in the sense that it allowed me to write working code within a few hours of picking up the language. The “optional namespaces” thing is something which bugs me a lot though. That importing a module works similar to `from module import *` in Python. It makes code confusing to read and grasp IMO (which module does this symbol come from?). Other than that, a pretty cool language.

dom96 8y ago
> The “optional namespaces” thing is something which bugs me a lot though. That importing a module works similar to `from module import *` in Python. It makes code confusing to read and grasp IMO (which module does this symbol come from?). Other than that, a pretty cool language. This is a common complaint, but there is rarely a solution proposed alongside the complaint. Nim is significantly different from Python to warrant these semantics, but I am really open to hearing ideas of how this could be improved keeping in mind these differences (operator overloading, no classes). A recent proposal was made here, and it looks like it will be adopted, I'd love to know what you think about it: https://forum.nim-lang.org/t/3783 https://forum.nim-lang.org/t/3783

fgimian 8y ago

You're right about this point. I really should have spent more time on Nim, and I still intend to. In fact, Nim was my main choice prior to learning about Crystal. So no offence intended at all to any Nim fans, and I hope to dive into it more thoroughly in the near future.