3 ms·

Nim is one of those things that seems very well put together yet I can't currently see what role it fills in the wider market for programming languages and diff

Nim is one of those things that seems very well put together yet I can't currently see what role it fills in the wider market for programming languages and different types of communities around them. What kind of stuff is particularly popular among Nim users compared to communities for other languages? What kind of stuff do the people working on Nim want to use it / see it used for?

jestar_jokin 10y ago
Games, or soft real-time systems (like audio tools; synths, DAWs, or editors). Potentially, cross-platform mobile apps. Thanks to its approach to GC, you can impose a limit on the time to spend on GC between ticks, so no unpredictable performance stuttering. I see it as having nice "functional-ish" syntax like Python, but with static types.
- hubert123 10y ago
  A limit on GC time might then obviously lead to high or too high memory use, potentially?
  - Meegul 10y ago
    Not OP or aware of Nim's specific implementation, but in some cases, yes. However in a fps-sensitive situation like a game, it just takes ~16ms of GC before you've missed at least one refresh. By limiting the time to something lower, we can distribute this time such that the user doesn't notice any stuttering, provided the GC events were spaced out enough.
Sir_Substance 10y ago
>I can't currently see what role it fills in the wider market for programming languages "As friendly as python or ruby, but compiles to binary for ease of deployment and speed" is currently an under-served market niche. Rust, Go and Swift are all candidates for the space (with the current defacto standard of friendliness in compiled languages being c++), but I find none is quite a match for me.
- nimmer 10y ago
  Nim is very good for small-to-medium sized services, but competing with Go is difficult for a grass-root language. Yet, Nim has a tiny memory and storage footprint and runs on microcontrollers thanks to GCC, which makes it ideal for IoT stuff.
  - Sir_Substance 10y ago
    >but competing with Go is difficult for a grass-root language. Yeah, I don't have any sound technical reasons for not using Go, I just find it to be somewhat claustrophobic to use. To paraphrase someone else, when I code in Go I feel like Rob Pike is standing over my shoulder muttering "why would you want to do that?" every 10 minutes or so.

jestar_jokin 10y ago

Games, or soft real-time systems (like audio tools; synths, DAWs, or editors). Potentially, cross-platform mobile apps. Thanks to its approach to GC, you can impose a limit on the time to spend on GC between ticks, so no unpredictable performance stuttering. I see it as having nice "functional-ish" syntax like Python, but with static types.

hubert123 10y ago
A limit on GC time might then obviously lead to high or too high memory use, potentially?
- Meegul 10y ago
  Not OP or aware of Nim's specific implementation, but in some cases, yes. However in a fps-sensitive situation like a game, it just takes ~16ms of GC before you've missed at least one refresh. By limiting the time to something lower, we can distribute this time such that the user doesn't notice any stuttering, provided the GC events were spaced out enough.

Sir_Substance 10y ago

>I can't currently see what role it fills in the wider market for programming languages "As friendly as python or ruby, but compiles to binary for ease of deployment and speed" is currently an under-served market niche. Rust, Go and Swift are all candidates for the space (with the current defacto standard of friendliness in compiled languages being c++), but I find none is quite a match for me.

nimmer 10y ago
Nim is very good for small-to-medium sized services, but competing with Go is difficult for a grass-root language. Yet, Nim has a tiny memory and storage footprint and runs on microcontrollers thanks to GCC, which makes it ideal for IoT stuff.
- Sir_Substance 10y ago
  >but competing with Go is difficult for a grass-root language. Yeah, I don't have any sound technical reasons for not using Go, I just find it to be somewhat claustrophobic to use. To paraphrase someone else, when I code in Go I feel like Rob Pike is standing over my shoulder muttering "why would you want to do that?" every 10 minutes or so.