9 ms·

I started using Nim recently and have been very impressed. It feels like a better Rust than Rust, and a better Go than Go. Why doesn’t Nim get more attention?

• davidkunz 5y ago
  I think one reason is that there's no big corporation behind it, for Rust it was Mozilla and now the members of the Rust Foundation, for Go it is Google. But I totally agree, Nim is an awesome language and definitely deserves more attention!
  • open-source-ux 5y ago
    "I think one reason is that there's no big corporation behind it" I agree. The popularity of some programming languages is undoubtedly buoyed by corporate sponsorship or the association with a company. This is not a bad thing, but it means other languages struggle to generate as much interest. Also, without a generous benefactor, open source languages have to scrape funding together piecemeal from different sources. For example, both Rust and Go have had (or still have) dedicated staff writing documentation for the language. This is a luxury that other languages cannot fund or afford. I actually posted a Ask HN question of this very topic recently: Can new programming languages attract developers without funding?" https://news.ycombinator.com/item?id=27043717 https://news.ycombinator.com/item?id=27043717
    • darthrupert 5y ago
      > For example, both Rust and Go have had (or still have) dedicated staff writing documentation for the language. And PR most importantly.
  • m_mueller 5y ago
    Didn't python start this way 25ish years ago? It then has slowly and steadily gained developers. Nim might also be there in another 15 years.
    • pjmlp 5y ago
      Python did had a couple of smallish killer applications like Zope, being used as scripting language in 3D applications, and gaining adoption among Perl users after Perl 6 never ending story. Additionally Guido has always worked in well known companies, and Microsoft and IBM have toyed with Python on their products as well.
      • m_mueller 5y ago
        I think that‘s a possible path for Nim to develop. Win over a trickle of python devs who‘ve learned the problems arising once you hit a certain performance ceiling / scale. This is being accentuated by hardware & cloud developments - startup time & compute efficiency becoming increasingly important (containerization/serverless driving one, I/O performance outgrowing CPU perf. driving the other). If those trends continue, Python will increasingly be ill fitted. And I‘m saying this as a Python dev.
        • pjmlp 5y ago
          Except that Guido went to Microsoft to work on their new JIT project, while Instagram is also pursuing their own, and there is Cython which follows the same compile to native code workflow (C based backed) as Nim. The biggest problem in Python slowness isn't that solutions don't exist, rather the community at large tends not to embrace them as other ecosystems do.
          • m_mueller 5y ago
            My experience with optimizing Python code after ~10y is that after a certain point it's just not worth it and you'd be better off rewriting in a more performant runtime once you hit that. That includes experiments I did with pypy, Cython and Numba for various projects.
    • nimmer 5y ago
      At the time no companies were heavily marketing FOSS projects. Also, today large companies have a fanbase.
• sp33der89 5y ago
  "a better Go than Go", this is exactly how I use Nim currently, and I couldn't have said it better myself!
• serverholic 5y ago
  Nim has a garbage-collector right? In that case I don't see how you can compare Nim and Rust. The Go comparison makes more sense.
  • fastball 5y ago
    Yes garbage-collected, with a caveat. From the website: > Nim's memory management is deterministic and customizable with destructors and move semantics, inspired by C++ and Rust. It is well-suited for embedded, hard-realtime systems.
    • throwaway894345 5y ago
      This is interesting. The hard-realtime folks are a conservative bunch (understandably so); I wonder how much traction Nim is getting in that space.
      • elcritch 5y ago
        There’s a few of us working in this area, well rather Nim on embedded microcontrollers. :-) It works fantastically, though most of us aren’t traditional hard real time folks. Nevertheless Nim’s new ARC is excellent for this area. The overhead of the GC basically is just an increment/decrement on an integer (no atomic). That means it’s fast and predictable for modern MCUs and plays well with C code. If you want a tight interrupt function you can stick an object in global variable and know it won’t incur GC overhead. It’s relatively easy to reason about where and when you want memory to be free’ed (actually easier than Rust). Also allocator pools are easy to utilize. On a side note, as the Nim compiler improves moves and sinks analysis, the runtime overhead of ARC approaches that of Rust’s compile time memory management, especially with a lot of Rust code that use lots of Rc wrappers. P.S. I’m planning to write a Nim wrapper for Zephyr RTOS when I get time later in the summer, and improve the existing FreeRTOS support too.
        • throwaway894345 5y ago
          This sounds really cool. I'm glad to hear that there's something rivaling Rust.
• one2three4 5y ago
  How's Nim faring with regards to easy programming for multicores? (I think that's the main selling point of Go).
  • cb321 5y ago
    First, I like that you said "multicores" and not "multithreads". Default-sharing of all memory is overrated. Sometimes it is useful/necessary, but people reach for threads too readily, IMO. For multiprocessing (like Python's module of that name), you can roll your own little system in probably 100 lines of code or use something like this [1] with an example program [2]. For me, that toy program runs 1.5-2x faster than ripgrep on the same (admittedly limited) problem on Linux. { I suspect this perf diff is due to mmap IO being faster than syscall IO due to SIMD register use as discussed here [3], but this deserves deeper investigation than I have time for right now. If my hunch is right, that may constitute further argumentative support for not leaping to threads even if the programming language "makes them 'easy'", though. } As for threads/parallelism with shared memory in Nim..Honestly, there is probably too much to recap. Weave [4] would be a good place to start reading, though, or searching the Nim Forum. [1] https://github.com/c-blake/cligen/blob/master/cligen/procpool.nim [2] https://github.com/c-blake/cligen/blob/master/examples/grl.nim [3] https://news.ycombinator.com/item?id=24842648 [4] https://github.com/mratsim/weave
    • burntsushi 5y ago
      Is it possible to share the commands/inputs you used to run a benchmark with your code against ripgrep? (Including commands to compile your Nim program.)
      • cb321 5y ago
        This has some Zsh-isms but should get you going, assuming it is even reproducible across machines. $ cd cligen-github-root/examples # default system nim.cfg $ nim c -d:danger --gc:arc -d:useMalloc --passC:-flto --passL:-flto grl # best to fetch this while you can as they get updated regularly # oh yeah, just unpacked; not configured/anything. $ cd /dev/shm/linux-5.12.5 # Zsh-ism to eliminate file tree traversal variation $ fs=(**.[ch]) # On an Intel i7-6700K $ repeat 5 utime ~1/grl -sburntsushi $fs 0.143836198 0.23 0.21 305.9% 0.137177744 0.22 0.22 320.8% 0.136714417 0.22 0.22 321.8% 0.149867097 0.23 0.22 300.3% 0.139042282 0.22 0.22 316.5% # make sure there is no ripgreprc file. $ repeat 5 utime rg burntsushi $fs 0.204383740 0.33 0.26 288.7% 0.200495993 0.34 0.25 294.3% 0.205767854 0.37 0.22 286.7% 0.200485116 0.33 0.25 289.3% 0.201692769 0.34 0.24 287.6% $ rg --version ripgrep 12.1.1 -SIMD -AVX (compiled) +SIMD +AVX (runtime) 200.5/136.7 =~ 1.47x OS for the above is Linux 5.12 running on bare metal. When I do a gcc PGO build I can squeeze about another 7 ms off that 136.7 time, but this is probably not very informative. Honestly, even 1.5x is kinda small, too. Anyway, were I to study this in more detail, as it sounds like you may be wanting to do, my recommendation would be to just factor out the substring/regex search (rg's vs glibc memmem, etc.) and study a more "pure IO" case. E.g., just switch to memchr(non-existent char) or such (e.g. Daniel Lemire's Faster 64-bit universal hashing using carry-less multiplications, Journal of Cryptographic Engineering is very fast or maybe even a SIMD-summation) to force all the IO but do other things SIMD-efficiently/at the highest GB/sec easily achievable. Then try that same simplified program with ripgrep's file size heuristics with threads vs the grl N-kid processes + always mmap. Just fewer moving parts/better isolation of behaviors. This also might lead to more general/re-applicable knowledge for the best way to do read-only multi-core file IO, not only tuning ripgrep or only Rust or only any PL. If it all holds up, and that same "test setup" could be applied to differing OS contexts like OSX/Win/etc. and then maybe it might be worthwhile re-jiggering ripgrep IO. (It is not a foregone conclusion the answer will be the same across OSes or CPUs, or even that my hunches/hypotheses are correct. I am trying to help here without making strong, general claims to be cross-examined upon, as is the Internet's way...)
• eikenberry 5y ago
  How is the compiler, speed wise? One thing I really like about Go and really don't like about Rust are their relative compiler speeds. I think it makes a big different for the language and Nim has a chance to get this right as they didn't make the mistake of using LLVM and it's bad compiler UX.
  • TylerE 5y ago
    Pretty good. The actual compilation is via clang, so there's a lot of heavy lifting done by that. So basically nim actually compiles .nim -> .c -> binary
    • elcritch 5y ago
      It’s good to note that the C/C++ generated by Nim compiles much faster than normal C/C++ code since they don’t include a lot of headers.
  • nimmer 5y ago
    Nim compiles to C and then runs GCC (not LLVM) to compile the binary. Overall, it's much faster than Go and Rust.
    • isubasinghe 5y ago
      I get that Nim can be faster than Go but I don't see how it can be faster than Rust, could you please elaborate as to why?
      • FridgeSeal 5y ago
        They probably mean the compilation is much faster than Rust.
      • nimmer 5y ago
        I was referring to compilation time... given the question.
    • 5y ago
• forgotpwd16 5y ago
  It may be better than Go but I don't see how it is comparable to Rust. Rust's biggest selling point is compilation-checked memory and thread safety guarantee without garbage collection. Nim instead uses a garbage collector, or a reference counter similar (but deterministic) to Swift which can cause memory leaks, or manual memory management.
  • nimmer 5y ago
    Nim is getting very close to Rust in terms of safety (but without the verbose ownership management) https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc... https://nim-lang.org/blog/2020/12/08/introducing-orc.html https://nim-lang.org/blog/2020/12/08/introducing-orc.html
    • searealist 5y ago
      Memory safety with GC is easy. Rust is novel because it offers memory safety without GC. Your links mention GC.
      • planetis 5y ago
        Can Rust deal with linked lists as well? Nim has a cycle collector based on the trial deletion algorithm https://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon01Concurrent.pdf https://researcher.watson.ibm.com/researcher/files/us-bacon/... It's different than the usual GC algorithms.
      • deleted 5y ago
        [deleted]
  • planetis 5y ago
    It was discussed recently: https://forum.nim-lang.org/t/7905 https://forum.nim-lang.org/t/7905 > to Swift which can cause memory leaks The Nim compiler can detect cycles and warn you. And --gc:orc collects them successfully at runtime. Orc is going to be the default.
• ilaksh 5y ago
  It would be interesting to see a compilation of all of the times people asked that question. Like literally every time anything about Nim is posted, someone asks that.
• mrweasel 5y ago
  What made me pick Go over Nim is a bigger standard library. For my use Nim is missing a good http server package/module and templating. If those two things had been present I would pick Nim over Go, it’s just a nice language for some like me, who have mostly done Python. I’m not sure if this was a bug in a third party module, but I also struggled a little with unicode support.
  • otherme123 5y ago
    Templating as in Jinja? I'm using Karax (https://github.com/karaxnim/karax#server-side-html-rendering https://github.com/karaxnim/karax#server-side-html-rendering) and it's awesome.
    • mrweasel 5y ago
      That’s nothing like Jinja, it’s more like React. I just want text templating and not a virtual dom and I don’t want to build my HTML in Nim.
      • planetis 5y ago
        We have many https://nimble.directory/search?query=template https://nimble.directory/search?query=template Also karax can also work as on server side, no virtual dom in that scenario. People prefer it because of type checking over string templates.
        • mrweasel 5y ago
          I think I tried most of those templating options, but some seems to have been abandoned, many try to abstract the html away and most are incomplete. Nwt seemed like the most promising, but it don’t even allow loops in your template.
          • planetis 5y ago
            I really don't understand what your requirements are. Again karax is well known and better alternative than all these (i.e loops and other control flow work as expected).
• ferdowsi 5y ago
  Including inheritance in nim was a design mistake and is enough to make me pass on it. Go and Rust were correct in avoiding inheritance in the language.
  • xigoi 5y ago
    In idiomatic Nim, you don't have inheritance. It's mostly there for the people who love their OOP.