3 ms·

People don't use Nim because the ecosystem is small, and the ecosystem is small because people don't use Nim. The solution is to make the ecosystem bigger by c

People don't use Nim because the ecosystem is small, and the ecosystem is small because people don't use Nim. The solution is to make the ecosystem bigger by contributing to it. Good news! The ecosystem is small, so there's a lot of low-hanging fruit. I'm a "random guy" writing Nim in my spare time, and I develop & maintain a handful of Nimble packages. Someone might actually be using them, too. None of my packages require regular maintenance because Nim's tooling is dead simple and the language is really easy to work with. It's a great opportunity for an enthusiastic hobbyist to be a big fish in a small pond.

vaylian 5y ago
It's been a while since I last played around with Nim (back when it was still called Nimrod). But doesn't Nim compile to C and therefore it can interact with the entire C ecosystem? And afaik it is also camel-case-insensitive, so that you can call C functions without having to worry about different naming conventions?
- ryukoposting 5y ago
  > But doesn't Nim compile to C and therefore it can interact with the entire C ecosystem? You can directly call C code, yes. You can even work with macros! It's a lot nicer when you can import a package that provides an abstraction layer over the C code, though (for example, my `ruby' package) > call C functions without having to worry about different naming conventions Yes. In fact, if you hand-write your C bindings instead of using something like c2nim, you can completely change the name of the function. This is a snippet from my aforementioned `ruby' package: proc evalString*(code: cstring): RawValue {.importc: "rb_eval_string".}
jdrek1 5y ago
The ecosystem might be small but as you said it can grow and I think there's enough people out there willing to give a new language a try if it seems appealing enough, it's quite common to try a new language for Advent of Code for example. That being said, honestly the thing that stops me from trying/using Nim that the compiler enforces a style and that style is just wrong (it enforces spaces). Same goes for Go which enforces the opening brace on same line style. The people writing those languages can have whatever style they like for their code, but forcing me to use it is very off-putting to say the least. I get that this is probably a minor issue for most people but I can't deal with change that well and things like this are super annoying, especially since there is not one single reason for forcing a certain style on everyone. I'm aware that `#? replace(sub = "\t", by = " ")` works, but it's a hack and I'd have to inject it everywhere, not a good solution. But at least it's better than Go in this regard.
- ryukoposting 5y ago
  > That being said, honestly the thing that stops me from trying/using Nim that the compiler enforces a style and that style is just wrong (it enforces spaces) I agree that the spaces thing is weird. Personally, I don't care what style anyone uses in any language. Nim doesn't care either (besides tabs, for some reason). All I ask is that your style is readable and consistent. It seems like every developer has hot takes about code style. With Nim, no matter what hot takes you have about code style, I can import your module without you forcing your style into my code. I'm a firmware engineer by day, and it seems like every embedded C codebase on earth uses a different style. For me, it's refreshing to be able to write code that's styled consistently, regardless of the styles used by dependencies.
  - jdrek1 5y ago
    Exactly, as long as it's readable and consistent I don't care what style other people write their code in, all I ask is that they and the compiler give me the same freedom and Nim and Go don't do that. > It seems like every developer has hot takes about code style. With Nim, no matter what hot takes you have about code style, I can import your module without you forcing your style into my code. I assume you're talking about the partial case insensitivity of Nim? I find that a bit weird tbh but I can see the appeal, you no longer would have things like a dependency doing weird things like all caps function names and forcing you to have that in your code.
    - ryukoposting 5y ago
      To some extent, Nim has a valid excuse because Whitespace is syntax. Forcing spaces should (ostensibly) make parsing more reliable, and users are less likely to have weird problems caused by their editors. Regardless, it's a negligible problem in my eyes. > I assume you're talking about the partial case insensitivity of Nim? That's one part of it, yes. I include UFCS in that as well. Case-insensitivity isn't as weird once you start using the language. Everything in the stdlib (and every Nimble package I've used) is in camelCase anyway, so I often forget that feature even exists. If anything, I'm grateful the language punishes people for trying to name one function `doHttpThing' and another function `doHTTPThing'.

vaylian 5y ago

It's been a while since I last played around with Nim (back when it was still called Nimrod). But doesn't Nim compile to C and therefore it can interact with the entire C ecosystem? And afaik it is also camel-case-insensitive, so that you can call C functions without having to worry about different naming conventions?

ryukoposting 5y ago
> But doesn't Nim compile to C and therefore it can interact with the entire C ecosystem? You can directly call C code, yes. You can even work with macros! It's a lot nicer when you can import a package that provides an abstraction layer over the C code, though (for example, my `ruby' package) > call C functions without having to worry about different naming conventions Yes. In fact, if you hand-write your C bindings instead of using something like c2nim, you can completely change the name of the function. This is a snippet from my aforementioned `ruby' package: proc evalString*(code: cstring): RawValue {.importc: "rb_eval_string".}

jdrek1 5y ago

The ecosystem might be small but as you said it can grow and I think there's enough people out there willing to give a new language a try if it seems appealing enough, it's quite common to try a new language for Advent of Code for example. That being said, honestly the thing that stops me from trying/using Nim that the compiler enforces a style and that style is just wrong (it enforces spaces). Same goes for Go which enforces the opening brace on same line style. The people writing those languages can have whatever style they like for their code, but forcing me to use it is very off-putting to say the least. I get that this is probably a minor issue for most people but I can't deal with change that well and things like this are super annoying, especially since there is not one single reason for forcing a certain style on everyone. I'm aware that `#? replace(sub = "\t", by = " ")` works, but it's a hack and I'd have to inject it everywhere, not a good solution. But at least it's better than Go in this regard.

ryukoposting 5y ago
> That being said, honestly the thing that stops me from trying/using Nim that the compiler enforces a style and that style is just wrong (it enforces spaces) I agree that the spaces thing is weird. Personally, I don't care what style anyone uses in any language. Nim doesn't care either (besides tabs, for some reason). All I ask is that your style is readable and consistent. It seems like every developer has hot takes about code style. With Nim, no matter what hot takes you have about code style, I can import your module without you forcing your style into my code. I'm a firmware engineer by day, and it seems like every embedded C codebase on earth uses a different style. For me, it's refreshing to be able to write code that's styled consistently, regardless of the styles used by dependencies.
- jdrek1 5y ago
  Exactly, as long as it's readable and consistent I don't care what style other people write their code in, all I ask is that they and the compiler give me the same freedom and Nim and Go don't do that. > It seems like every developer has hot takes about code style. With Nim, no matter what hot takes you have about code style, I can import your module without you forcing your style into my code. I assume you're talking about the partial case insensitivity of Nim? I find that a bit weird tbh but I can see the appeal, you no longer would have things like a dependency doing weird things like all caps function names and forcing you to have that in your code.
  - ryukoposting 5y ago
    To some extent, Nim has a valid excuse because Whitespace is syntax. Forcing spaces should (ostensibly) make parsing more reliable, and users are less likely to have weird problems caused by their editors. Regardless, it's a negligible problem in my eyes. > I assume you're talking about the partial case insensitivity of Nim? That's one part of it, yes. I include UFCS in that as well. Case-insensitivity isn't as weird once you start using the language. Everything in the stdlib (and every Nimble package I've used) is in camelCase anyway, so I often forget that feature even exists. If anything, I'm grateful the language punishes people for trying to name one function `doHttpThing' and another function `doHTTPThing'.