6 ms·

> I am still wondering why so few people use it. While Nim is my favorite language, I can understand that it has a small userbase, for these reasons: 1. No ma

by def- 10y ago

> I am still wondering why so few people use it. While Nim is my favorite language, I can understand that it has a small userbase, for these reasons: 1. No major backer like Google for Go or Mozilla for Rust 2. No killer feature like "memory safety and performance without GC" for Rust, instead a mix of all the reasonable down-to-earth features I want in a programming language 3. Some unique decisions instead of what you're used to from other languages, for example partial case sensitivity

untothebreach 10y ago
I used both nim (back when it was still nimrod) and rust for a while, before eventually settling on rust. I tried to give nim a chance, and was told that "they will grow on you" ("they" being the things you mentioned that were "unique decisions instead of what you're used to from other languages"). They never did, and though I got used to avoiding the problems I initially had with them, the language just never "felt good" to me.
valarauca1 10y ago
4. The fact that operator order is changed by the amount of white space between symbols 2+2 * 5 = 20 2 + 2 * 5 = 12
- adrusi 10y ago
  If you're consistent about how you space your infix operators, this will have no impact on your code. If you put space around some operators and not around others, in a way that doesn't correspond to precedence, you're going to confuse anyone who reads your code, in any language.
  - valarauca1 10y ago
    Being confused by code is no excuse for code not doing what ya know... every other programming language has done for the past 50 years. I get that trying new things, but somethings are pretty well agreed upon.
- xutopia 10y ago
  damn... I actually like that a lot!
  - qu4z-2 10y ago
    I like it for distinguishing homonym operators, but not for the precedence stuff they seem to have there. I'd like something like this though: let a = 10; a / 5 output> 2 let b = pwd(); b/temp output> Directory<"~/temp"> b / 2 error> b:Directory does not implement method "divide(:number)" a/temp error> a:int does not implement method "get(:string)"
- progman 10y ago
  I am a strong proponent of Nim but this is probably the worst idea I have ever encountered in language development. Honestly! Partial case sensitivity and the special underscore case are features I can live with. Unfortunately this has actually become a stumbling block for a wider adoption of Nim. All strange special features should be optional, not default.
  - dom96 10y ago
    What makes you think this is default? It most certainly is not and will be removed completely in the future. Edit: here is a source: http://nim-lang.org/docs/manual.html#syntax-strong-spaces http://nim-lang.org/docs/manual.html#syntax-strong-spaces ("... if the experimental parser directive #?strongSpaces is used..."). The last time this was discussed I said that it would be removed completely, and I still believe it will be. It's simply not a priority for us right now.
    - progman 10y ago
      > What makes you think this is default? Some of those features are default in Nim, some (strongspaces) are not. I say that all such weird features should be optional in general so that newcomers don't get scared off. Also case and underscore should work like in C per default since Nim interoperates with C seamlessly anyway. Case insensitivity and ignoring underscore are ok if optional.
ericfrederich 10y ago
wow... have never heard of that partial case sensitivity before. I think this goes beyond syntactic sugar. Holding the hand of the developer too much? Personally, as a Python programmer I like interfacing with C++ code like Qt via PyQt. If I see a camelCase method I know where it came from, but if I see a PEP-8 style name or method I know it's our own code, not from Qt.

by def- 10y ago

untothebreach 10y ago

I used both nim (back when it was still nimrod) and rust for a while, before eventually settling on rust. I tried to give nim a chance, and was told that "they will grow on you" ("they" being the things you mentioned that were "unique decisions instead of what you're used to from other languages"). They never did, and though I got used to avoiding the problems I initially had with them, the language just never "felt good" to me.

valarauca1 10y ago

4. The fact that operator order is changed by the amount of white space between symbols 2+2 * 5 = 20 2 + 2 * 5 = 12

adrusi 10y ago
If you're consistent about how you space your infix operators, this will have no impact on your code. If you put space around some operators and not around others, in a way that doesn't correspond to precedence, you're going to confuse anyone who reads your code, in any language.
- valarauca1 10y ago
  Being confused by code is no excuse for code not doing what ya know... every other programming language has done for the past 50 years. I get that trying new things, but somethings are pretty well agreed upon.
xutopia 10y ago
damn... I actually like that a lot!
- qu4z-2 10y ago
  I like it for distinguishing homonym operators, but not for the precedence stuff they seem to have there. I'd like something like this though: let a = 10; a / 5 output> 2 let b = pwd(); b/temp output> Directory<"~/temp"> b / 2 error> b:Directory does not implement method "divide(:number)" a/temp error> a:int does not implement method "get(:string)"
progman 10y ago
I am a strong proponent of Nim but this is probably the worst idea I have ever encountered in language development. Honestly! Partial case sensitivity and the special underscore case are features I can live with. Unfortunately this has actually become a stumbling block for a wider adoption of Nim. All strange special features should be optional, not default.
- dom96 10y ago
  What makes you think this is default? It most certainly is not and will be removed completely in the future. Edit: here is a source: http://nim-lang.org/docs/manual.html#syntax-strong-spaces http://nim-lang.org/docs/manual.html#syntax-strong-spaces ("... if the experimental parser directive #?strongSpaces is used..."). The last time this was discussed I said that it would be removed completely, and I still believe it will be. It's simply not a priority for us right now.
  - progman 10y ago
    > What makes you think this is default? Some of those features are default in Nim, some (strongspaces) are not. I say that all such weird features should be optional in general so that newcomers don't get scared off. Also case and underscore should work like in C per default since Nim interoperates with C seamlessly anyway. Case insensitivity and ignoring underscore are ok if optional.

ericfrederich 10y ago

wow... have never heard of that partial case sensitivity before. I think this goes beyond syntactic sugar. Holding the hand of the developer too much? Personally, as a Python programmer I like interfacing with C++ code like Qt via PyQt. If I see a camelCase method I know where it came from, but if I see a PEP-8 style name or method I know it's our own code, not from Qt.