6 ms·

I've always been surprised Nim hasn't taken off more. All the productivity of a language like Python but with the performance of C.

nerdponx 4y ago
I have really enjoyed using it for random scripts and small programs, but it definitely is slower than plain C for simple things like "loop over lines of stdin and do some basic calculations". Of course, you also get a lot of nice abstraction, memory safety, GC, a great standard library, compiler-checked effects (!), less-noisy syntax, and a nice easy compiler CLI, and that's a tradeoff I'm happy to make. Not to mention that I would feel much more comfortable writing a bigger application in Nim than in C.
- monetus 4y ago
  That slowness is tied to the GC, which you can swap in and out with others or turn off. I feel like this is a really undersold feature of the language.
  - cb321 4y ago
    It's a mixture of allocation, copying, and reclamation. You can actually side-step a lot of such issues in a mostly mm-agnostic way with a `var` like interface in Nim -- sticking to one initial allocation like the common pattern of caller-allocated storage in C. These days on three-level cache server CPUs the real cost of hitting virgin, uncached memory is probably worse than other pieces..DRAM latency is >10x L3, but almost everything "depends on..".
    - arc776 4y ago
      100% my experience too. GC in Nim is a rounding error at worst and is often statically elided, anyway. Performance is almost entirely about memory access patterns and you have the same access to this as C. In other words, performance in Nim is entirely down to the algorithm used, which is a nice place to be.
- cb321 4y ago
  I have not found this slower-than-C to be the case. You may need to use something like `iterator getDelims` in https://github.com/c-blake/cligen/blob/master/cligen/osUt.nim https://github.com/c-blake/cligen/blob/master/cligen/osUt.ni... to manage memory with fewer copies/less alloc "more like C", though or perhaps `std/memfiles` memory mapped IO. More pithy ways to put it are that "there are no speed limits" or "Nim responds to optimization effort about as well as other low level languages like C". You can deploy SIMD intrinsics, for example. In my experience, it's not that hard to "pay only for what you use". As a more concrete thing, I have timed (yes, on one CPU, one test case, etc..many caveats) the tokenizer used in https://github.com/c-blake/bu/blob/main/rp.nim https://github.com/c-blake/bu/blob/main/rp.nim to be faster than that used by the Rust xsv. Of course, you really shouldn't tokenize a lot if it's costly/data is big, but rather save a binary answer that does not need parsing (or perhaps more accurately is natively parsed by the CPU).
  - nerdponx 4y ago
    This stuff honestly goes over my head and beyond my current skillset, but it's useful to know that there is no "speed limit" in the hands of someone who knows what they're doing. My experience has been with basically translating Python and shell scripts into Nim, and occasionally comparing them with my own feeble attempts at doing the same in C.
    - elcritch 4y ago
      Just a note that the "loop over lines of stdin and do some basic calculations" use case highlights probably one of the places where it's really easy to blow up Nim's performance benefits -- string or seq copies. :/ The issue is that Nim's string library ends up making copies when doing things. It's a sane default and ensures sane behavior. However, it often leads beginner's to make slower programs, sometimes even slower than equivalent Python ones. If you used `strcopy` in C a lot, you'd get similar results. Often the solution is trivial and is just to use the `var` or `openArray[T]` variants of proc's. It's one of the points in the blog post and is crucial for good real time code. I'm hopeful the new `lent` and `view` features will make it easier to use non-copy slices on strings. That'd be nice!
- xigoi 4y ago
  Just to be sure, did you compile it with -d:release/-d:danger? This is a common mistake people make when benchmarking Nim.
0cf8612b2e1e 4y ago
No 800 pound gorilla has taken the language under its wing, so really difficult to build mindshare. Without a Google, Microsoft, etc who can throw unlimited funding to have full time developers polishing rough edges, writing docs, or implementing libraries, a new language is always lacking vs established alternatives.
- olah_1 4y ago
  The only thing close is some ethereum tools like these: - https://github.com/status-im/nwaku https://github.com/status-im/nwaku - https://github.com/status-im/nimbus-eth2 https://github.com/status-im/nimbus-eth2 But I think the real killer feature to me is the javascript target. It seems like a real dream for a fullstack experience.
  - arc776 4y ago
    > the real killer feature to me is the javascript target Agree, this is amazing because you can share code and data structures between front and backend (for example: https://github.com/karaxnim/karax https://github.com/karaxnim/karax). Also, it's really nice having high level stuff like metaprogramming and static typing spanning both targets. Things like reading a spec file and generating statically checked APIs for server/client is straightforward, which opens up a lot of possibilities.
    - dom96 4y ago
      Honestly as someone that has used Nim for this extensively, I think that these days with WASM and TypeScript available this isn’t much of a killer feature anymore.
      - arc776 4y ago
        Only if you consider the web side. Backend and frontend in the same language is a massive feature for many reasons, not least performance and uniformity. Adding TypeScript is increasing interface friction and complexity, instead of simplifying things. Of course, right now this may or may not be easier/harder/feasible with just Nim depending on the project, and many more people know TypeScript, but the ideal of one language > many languages is a worthy one.
winrid 4y ago
The reason is tooling. The Clion plugin doesn't even do type checking and is a year out of date. The language server has been in progress for five years and is still not done. The VSCode plugin is okay, but refactoring, auto-imports, and autocomplete are nowhere near as easy as other languages like Java in jetbrains products. Not to mention a good debugger. I hope Jetbrains can prioritize the Clion plugin. It would help a lot.
- fuckstick 4y ago
  Without disagreeing on the specific points about the tooling, I’m not convinced. Golang took off with a far weaker tooling story. Maybe the table stakes have changed in a decade - but I believe other factors are more important. Moreover I remain skeptical that even if those tooling issues were fixed tomorrow it would help Nim turn the corner.
  - winrid 4y ago
    Maybe! It would get me on board, though :) I'm working on a new server side project and am using Java for now, because of this reason. I hope someday I have time to help build IDE plugins and so on :)
  - 0cf8612b2e1e 4y ago
    > Golang took off with a far weaker tooling story All Go had to do was say, “Built by Google” and people came running.
    - elcritch 4y ago
      Well, the "designed by UNIX co-creator" piece helped too I'm sure.
    - silisili 4y ago
      Dart was built by Google, and nobody wants to touch it. Well, a few diehard fans. Go is a nice language that gets a lot right. Saying people only use it because of Google is kinda shortsighted.

nerdponx 4y ago

I have really enjoyed using it for random scripts and small programs, but it definitely is slower than plain C for simple things like "loop over lines of stdin and do some basic calculations". Of course, you also get a lot of nice abstraction, memory safety, GC, a great standard library, compiler-checked effects (!), less-noisy syntax, and a nice easy compiler CLI, and that's a tradeoff I'm happy to make. Not to mention that I would feel much more comfortable writing a bigger application in Nim than in C.

monetus 4y ago
That slowness is tied to the GC, which you can swap in and out with others or turn off. I feel like this is a really undersold feature of the language.
- cb321 4y ago
  It's a mixture of allocation, copying, and reclamation. You can actually side-step a lot of such issues in a mostly mm-agnostic way with a `var` like interface in Nim -- sticking to one initial allocation like the common pattern of caller-allocated storage in C. These days on three-level cache server CPUs the real cost of hitting virgin, uncached memory is probably worse than other pieces..DRAM latency is >10x L3, but almost everything "depends on..".
  - arc776 4y ago
    100% my experience too. GC in Nim is a rounding error at worst and is often statically elided, anyway. Performance is almost entirely about memory access patterns and you have the same access to this as C. In other words, performance in Nim is entirely down to the algorithm used, which is a nice place to be.
cb321 4y ago
I have not found this slower-than-C to be the case. You may need to use something like `iterator getDelims` in https://github.com/c-blake/cligen/blob/master/cligen/osUt.nim https://github.com/c-blake/cligen/blob/master/cligen/osUt.ni... to manage memory with fewer copies/less alloc "more like C", though or perhaps `std/memfiles` memory mapped IO. More pithy ways to put it are that "there are no speed limits" or "Nim responds to optimization effort about as well as other low level languages like C". You can deploy SIMD intrinsics, for example. In my experience, it's not that hard to "pay only for what you use". As a more concrete thing, I have timed (yes, on one CPU, one test case, etc..many caveats) the tokenizer used in https://github.com/c-blake/bu/blob/main/rp.nim https://github.com/c-blake/bu/blob/main/rp.nim to be faster than that used by the Rust xsv. Of course, you really shouldn't tokenize a lot if it's costly/data is big, but rather save a binary answer that does not need parsing (or perhaps more accurately is natively parsed by the CPU).
- nerdponx 4y ago
  This stuff honestly goes over my head and beyond my current skillset, but it's useful to know that there is no "speed limit" in the hands of someone who knows what they're doing. My experience has been with basically translating Python and shell scripts into Nim, and occasionally comparing them with my own feeble attempts at doing the same in C.
  - elcritch 4y ago
    Just a note that the "loop over lines of stdin and do some basic calculations" use case highlights probably one of the places where it's really easy to blow up Nim's performance benefits -- string or seq copies. :/ The issue is that Nim's string library ends up making copies when doing things. It's a sane default and ensures sane behavior. However, it often leads beginner's to make slower programs, sometimes even slower than equivalent Python ones. If you used `strcopy` in C a lot, you'd get similar results. Often the solution is trivial and is just to use the `var` or `openArray[T]` variants of proc's. It's one of the points in the blog post and is crucial for good real time code. I'm hopeful the new `lent` and `view` features will make it easier to use non-copy slices on strings. That'd be nice!
xigoi 4y ago
Just to be sure, did you compile it with -d:release/-d:danger? This is a common mistake people make when benchmarking Nim.

0cf8612b2e1e 4y ago

No 800 pound gorilla has taken the language under its wing, so really difficult to build mindshare. Without a Google, Microsoft, etc who can throw unlimited funding to have full time developers polishing rough edges, writing docs, or implementing libraries, a new language is always lacking vs established alternatives.

olah_1 4y ago
The only thing close is some ethereum tools like these: - https://github.com/status-im/nwaku https://github.com/status-im/nwaku - https://github.com/status-im/nimbus-eth2 https://github.com/status-im/nimbus-eth2 But I think the real killer feature to me is the javascript target. It seems like a real dream for a fullstack experience.
- arc776 4y ago
  > the real killer feature to me is the javascript target Agree, this is amazing because you can share code and data structures between front and backend (for example: https://github.com/karaxnim/karax https://github.com/karaxnim/karax). Also, it's really nice having high level stuff like metaprogramming and static typing spanning both targets. Things like reading a spec file and generating statically checked APIs for server/client is straightforward, which opens up a lot of possibilities.
  - dom96 4y ago
    Honestly as someone that has used Nim for this extensively, I think that these days with WASM and TypeScript available this isn’t much of a killer feature anymore.
    - arc776 4y ago
      Only if you consider the web side. Backend and frontend in the same language is a massive feature for many reasons, not least performance and uniformity. Adding TypeScript is increasing interface friction and complexity, instead of simplifying things. Of course, right now this may or may not be easier/harder/feasible with just Nim depending on the project, and many more people know TypeScript, but the ideal of one language > many languages is a worthy one.

winrid 4y ago

The reason is tooling. The Clion plugin doesn't even do type checking and is a year out of date. The language server has been in progress for five years and is still not done. The VSCode plugin is okay, but refactoring, auto-imports, and autocomplete are nowhere near as easy as other languages like Java in jetbrains products. Not to mention a good debugger. I hope Jetbrains can prioritize the Clion plugin. It would help a lot.

fuckstick 4y ago
Without disagreeing on the specific points about the tooling, I’m not convinced. Golang took off with a far weaker tooling story. Maybe the table stakes have changed in a decade - but I believe other factors are more important. Moreover I remain skeptical that even if those tooling issues were fixed tomorrow it would help Nim turn the corner.
- winrid 4y ago
  Maybe! It would get me on board, though :) I'm working on a new server side project and am using Java for now, because of this reason. I hope someday I have time to help build IDE plugins and so on :)
- 0cf8612b2e1e 4y ago
  > Golang took off with a far weaker tooling story All Go had to do was say, “Built by Google” and people came running.
  - elcritch 4y ago
    Well, the "designed by UNIX co-creator" piece helped too I'm sure.
  - silisili 4y ago
    Dart was built by Google, and nobody wants to touch it. Well, a few diehard fans. Go is a nice language that gets a lot right. Saying people only use it because of Google is kinda shortsighted.