7 ms·

Nim is fantastic, I especially like that it takes a pragmatic approach to all its features, so that it doesn't get bogged down in theory but lets you get produc

Nim is fantastic, I especially like that it takes a pragmatic approach to all its features, so that it doesn't get bogged down in theory but lets you get productive with it right away. One example is that even though it says it's a systems (and application) language, it has GC (ref counting + cycle detection), which means you don't have to worry about memory management and can focus on the core of your application. Honestly I think Nim is comparable to Go, so if you're thinking of adopting Go, look into Nim, you might like what you find.

OskarS 8y ago
The realtime support for the GC is really fucking cool. In many game-dev situations, you would happily give up a millisecond per frame for GC deterministically instead of the GC occassionally taking 20-40 milliseconds.
enitihas 8y ago
I too was enthusiastic about using Nim, as it is clearly a much superior language to go. However, the ecosystems are not at all comparable. Even without considering the huge amount of 3rd party packages for go, the go stdlib itself is too good and has almost all batteries included. For Nim, if you are going to develop any non trivial program, it is going to be really difficult to find the relevant libraries.
- treeform 8y ago
  I thought so too about Nim, but then I realized how easy it is to call c libs from nim. There is infinate amount of c and c++ libs out there.
  - jhasse 8y ago
    Does calling C++ libs work in the latest version of Nim though? I mean real C++ interfaces, not C ones that just happen to use C++ in their implementation.
    - mratsim 8y ago
      Works for me: Wrapping a C++ header-only template library: https://github.com/status-im/nim-ttmath https://github.com/status-im/nim-ttmath Generating Cuda C++ Functor: https://github.com/mratsim/Arraymancer/blob/master/src/tensor/private/incl_kernels_cuda.nim https://github.com/mratsim/Arraymancer/blob/master/src/tenso...
    - dom96 8y ago
      Yes, and as far as I'm concerned Nim has one of the best C++ interop capabilities out of any language bar C++ itself.
- nepeckman 8y ago
  I disagree. Nim is very much a batteries included language and has a very healthy range of libraries available in the set of standard libraries. The lack of of 3rd party modules is a little problematic, but the large number of standard libraries and good C FFI can help mitigate this. Go is definitely the more supported and mature language, but Nim still has a lot going for it.
- mlevental 8y ago
  i don't understand why people make these kinds of criticisms. everyone already understand that the assumption for a new language that the ecosystem won't be as rich. you're basically saying something akin to "x high school football player is much worse than y professional football player in a professional game". of course. judge them in context.
  - overcast 8y ago
    If we're using that logic, then nim is only ready for high school level applications?
    - mlevental 8y ago
      >If we're using that logic, then nim is only ready for high school level applications? i see no problem with this but i think JS is only ready for high school level applications too.
    - jerf 8y ago
      Objectively, it's very hard to say. But practically, yes. Smart people building critical systems do not run to relatively untested languages, no matter how good they may look. But... there's a loooooot of "high school level" applications out there in the world. And the way a language graduates up to the higher classes is getting tried out in the "lower criticality" systems, and getting experience. I wouldn't try to build an S3 competitor in Nim right now, no matter how good it may look. But even a company building an S3 competitor in some other language could still have tons of other places Nim would be a fit.
      - nimmer 8y ago
        Nim generates C and compiles it using GCC. It does not inject a runtime that runs its own threads or any other magic. All the usual static analysis tools, debuggers and even formal methods can be used on the generated C code.
      - yawaramin 8y ago
        > Smart people building critical systems do not run to relatively untested languages, no matter how good they may look. Except they do, if the new untested language is qualitatively better than the old one. For example, a critical crypto algorithm in Firefox is written in F* and compiled to C: https://blog.mozilla.org/security/2017/09/13/verified-cryptography-firefox-57/ https://blog.mozilla.org/security/2017/09/13/verified-crypto... . The new implementation is formally verified free of certain classes of bugs (like buffer overflows), and significantly faster than the hand-written C implementation.
- AnIdiotOnTheNet 8y ago
  For a while (before I found zig) I was looking for a language to do my hobby development in. Most newer languages lack a comprehensive library ecosystem, but I'm not a fan of having a giant web of dependencies anyway so one of my criteria was "how much would I dread writing my own X?". You always take a productivity hit when starting out in a language anyway, and making your own libs that interact with real code and data gives you a much better feel for how a language is going to work in the real world than more common "hello world"-like exercises do in my opinion.
- progman 8y ago
  > However, the ecosystems are not at all comparable. Really? https://github.com/VPashkov/awesome-nim https://github.com/VPashkov/awesome-nim You can install Nim packages easily with nimble. https://github.com/nim-lang/nimble https://github.com/nim-lang/nimble
  - qaq 8y ago
    Not a fan of Go and actually like nim but https://github.com/avelino/awesome-go https://github.com/avelino/awesome-go Also for people actually targeting production there is hufe dif. between say DB driver that is used in literally millions of projects and has a large number of active maintainers and DB driver written by 1 dude that has not commited any fixes in 12 month
    - progman 8y ago
      Looks impressive. However, since Nim has such an easy C/C++ FFI you have to consider also all C and C++ APIs. That looks superior even to Go, unless Go's C FFI is as easy as Nim's. https://github.com/kozross/awesome-c https://github.com/kozross/awesome-c https://github.com/aleksandar-todorovic/awesome-c https://github.com/aleksandar-todorovic/awesome-c https://cpp.libhunt.com/ https://cpp.libhunt.com/ https://github.com/fffaraz/awesome-cpp https://github.com/fffaraz/awesome-cpp
      - qaq 8y ago
        That is true but up to a point say I want production ready async PG driver FFI does not help me much
Serow225 8y ago
How would you compare go and Nim? What's better and worse in each (setting aside ecosystem size)? Are there any core architectural decisions made in Nim that you would see as mistakes that will eventually drag the language down? Go and NIm kinda sorta seem to sit in a similar solution space, from the little that I've had time to really read about Nim so far. Thanks for your thoughts!
- Phillips126 8y ago
  In my experience, Nim was the more enjoyable language to write. I had initially written an application in Golang that effectively keeps our DNS records in sync with CloudFlare across ~100+ machines (A, AAAA, CNAME, etc). The application was simple enough to write in Golang but I still wasn't crazy about the error handling (if err != nil...) after every few lines, as well as the large binary size once compiled (although I understand the reason for its size). To see if I could do better, I re-wrote the application in Nim, a language I've always had a lot of interest in. With the logic already figured out the code writing was quick and easy. I found the finished code to be cleaner and more concise and when it came time to compile I was excited to find a binary that was only 83kb in comparison to the 6mb binary of the Golang version. Of course your miles may vary and there are many advantages/disadvantages to every language but I personally look forward to writing more Nim in the future :)
dagenix 8y ago
Something about the phrase "it doesn't get bogged down in theory" really bothers me. What's wrong with having a good theoretical foundation?
- athenot 8y ago
  When theoretical purity is a main goal, very often usability suffers if your problem doesn't 100% model in said theory.
  - fb03 8y ago
    [stares at haskell seductively]
  - ilaksh 8y ago
    In my opinion Rust suffers from this type of problem. I actually suspect but haven't proven that I can make very memory or type 'safe' programs with Nim. I guess it goes back to practical necessity or reality for starters though. Do we need to or can we really prove that our programs are safe somehow? Is that something we generally need to the expense of everything else? But Rust ergonomics have been getting better and in my opinion some of the Rust guarantees may put it in an elite category of languages along with Nim but for totally different reasons.
    - rafaelvasco 8y ago
      Yeah, I tried reading some code to see if I could get a grasp on Rust, but found that the language puts too much friction on the developer, when writing or reading code. The syntax ends up too dense. For gamedev particularly, I think Rust is just too much, though I can understand it's value if you're coding highly concurrent code with huge memory safety needs.
  - joel_ms 8y ago
    Do you have any examples? In my experience theoretical purity is largely independent of usability, which I find is more a function of the language's expressibility and the available abstractions (and how well those abstractions play together.) Take Elm, Haskell and Agda/Idris as examples of four programming languages with strong theoretical foundations, that also vary widely in expressibility and usability Elm is (imho) very usable even when teaching beginners unfamiliar with the ML-style syntax. The main abstraction is parametric polymorphism (generics in oop-terms), no subtyping with inheritance and no typeclass/interface mechanism. The language has a carefully crafted culture to maintain the beginner-friendliness of the language, explicitly at the expense of expressibility (but not usability.) I personally find elm to be an incredibly usable language, specifically because it's both simple and theoretically pure. Less to understand, for more gained reliability. More practically, I often prototype completely without type signatures, relying on type inference to make sure that I'm not doing anything nonsensical. The end result (for me at least) is the speed and ease of a dynamic language, with the reliability of a statically typed language. Haskell (without GHC extensions) offers more abstractions and is consequently "less usable" in the sense that you need to understand more theory to use things like Higher Kinded Types and whatnot. By adding GHC extensions you can gradually ramp up the expressibility (by adding abstractions,) while at the same time making the language (slightly) more difficult to use. You can get almost all the way to dependent types which brings us to.. Agda and Idris offers an incredibly powerful mechanism for abstraction called dependent types, where you essentially program your type checker as a logic. But they are (somewhat infamously) difficult to use due to having to understand the consequences of having computations at the type-level (and beyond) and consequently at compile time. If any of those are any less pure than the other it's probably Haskell, and that's more due to the ad hoc nature of the GHC extension system, which allows you to combine extensions in problematic ways that can hide impurity. They all compile based on some type theory as a model of computation, but those type theories can vary widely in how complex they are to understand, but the level of complexity doesn't make anything more or less pure. All of them also offers some degree of escape hatch from their "theoretical purity"-prison. Elm has its ports for js interop, Haskell has unsafeIO and friends, Agda has FFI to both js and haskell depending on backend, and I'm guessing Idris has some way of doing this as well. In this sense Elm is probably the most pure.

OskarS 8y ago

The realtime support for the GC is really fucking cool. In many game-dev situations, you would happily give up a millisecond per frame for GC deterministically instead of the GC occassionally taking 20-40 milliseconds.

enitihas 8y ago

I too was enthusiastic about using Nim, as it is clearly a much superior language to go. However, the ecosystems are not at all comparable. Even without considering the huge amount of 3rd party packages for go, the go stdlib itself is too good and has almost all batteries included. For Nim, if you are going to develop any non trivial program, it is going to be really difficult to find the relevant libraries.

treeform 8y ago
I thought so too about Nim, but then I realized how easy it is to call c libs from nim. There is infinate amount of c and c++ libs out there.
- jhasse 8y ago
  Does calling C++ libs work in the latest version of Nim though? I mean real C++ interfaces, not C ones that just happen to use C++ in their implementation.
  - mratsim 8y ago
    Works for me: Wrapping a C++ header-only template library: https://github.com/status-im/nim-ttmath https://github.com/status-im/nim-ttmath Generating Cuda C++ Functor: https://github.com/mratsim/Arraymancer/blob/master/src/tensor/private/incl_kernels_cuda.nim https://github.com/mratsim/Arraymancer/blob/master/src/tenso...
  - dom96 8y ago
    Yes, and as far as I'm concerned Nim has one of the best C++ interop capabilities out of any language bar C++ itself.
nepeckman 8y ago
I disagree. Nim is very much a batteries included language and has a very healthy range of libraries available in the set of standard libraries. The lack of of 3rd party modules is a little problematic, but the large number of standard libraries and good C FFI can help mitigate this. Go is definitely the more supported and mature language, but Nim still has a lot going for it.
mlevental 8y ago
i don't understand why people make these kinds of criticisms. everyone already understand that the assumption for a new language that the ecosystem won't be as rich. you're basically saying something akin to "x high school football player is much worse than y professional football player in a professional game". of course. judge them in context.
- overcast 8y ago
  If we're using that logic, then nim is only ready for high school level applications?
  - mlevental 8y ago
    >If we're using that logic, then nim is only ready for high school level applications? i see no problem with this but i think JS is only ready for high school level applications too.
  - jerf 8y ago
    Objectively, it's very hard to say. But practically, yes. Smart people building critical systems do not run to relatively untested languages, no matter how good they may look. But... there's a loooooot of "high school level" applications out there in the world. And the way a language graduates up to the higher classes is getting tried out in the "lower criticality" systems, and getting experience. I wouldn't try to build an S3 competitor in Nim right now, no matter how good it may look. But even a company building an S3 competitor in some other language could still have tons of other places Nim would be a fit.
    - nimmer 8y ago
      Nim generates C and compiles it using GCC. It does not inject a runtime that runs its own threads or any other magic. All the usual static analysis tools, debuggers and even formal methods can be used on the generated C code.
    - yawaramin 8y ago
      > Smart people building critical systems do not run to relatively untested languages, no matter how good they may look. Except they do, if the new untested language is qualitatively better than the old one. For example, a critical crypto algorithm in Firefox is written in F* and compiled to C: https://blog.mozilla.org/security/2017/09/13/verified-cryptography-firefox-57/ https://blog.mozilla.org/security/2017/09/13/verified-crypto... . The new implementation is formally verified free of certain classes of bugs (like buffer overflows), and significantly faster than the hand-written C implementation.
AnIdiotOnTheNet 8y ago
For a while (before I found zig) I was looking for a language to do my hobby development in. Most newer languages lack a comprehensive library ecosystem, but I'm not a fan of having a giant web of dependencies anyway so one of my criteria was "how much would I dread writing my own X?". You always take a productivity hit when starting out in a language anyway, and making your own libs that interact with real code and data gives you a much better feel for how a language is going to work in the real world than more common "hello world"-like exercises do in my opinion.
progman 8y ago
> However, the ecosystems are not at all comparable. Really? https://github.com/VPashkov/awesome-nim https://github.com/VPashkov/awesome-nim You can install Nim packages easily with nimble. https://github.com/nim-lang/nimble https://github.com/nim-lang/nimble
- qaq 8y ago
  Not a fan of Go and actually like nim but https://github.com/avelino/awesome-go https://github.com/avelino/awesome-go Also for people actually targeting production there is hufe dif. between say DB driver that is used in literally millions of projects and has a large number of active maintainers and DB driver written by 1 dude that has not commited any fixes in 12 month
  - progman 8y ago
    Looks impressive. However, since Nim has such an easy C/C++ FFI you have to consider also all C and C++ APIs. That looks superior even to Go, unless Go's C FFI is as easy as Nim's. https://github.com/kozross/awesome-c https://github.com/kozross/awesome-c https://github.com/aleksandar-todorovic/awesome-c https://github.com/aleksandar-todorovic/awesome-c https://cpp.libhunt.com/ https://cpp.libhunt.com/ https://github.com/fffaraz/awesome-cpp https://github.com/fffaraz/awesome-cpp
    - qaq 8y ago
      That is true but up to a point say I want production ready async PG driver FFI does not help me much

Serow225 8y ago

How would you compare go and Nim? What's better and worse in each (setting aside ecosystem size)? Are there any core architectural decisions made in Nim that you would see as mistakes that will eventually drag the language down? Go and NIm kinda sorta seem to sit in a similar solution space, from the little that I've had time to really read about Nim so far. Thanks for your thoughts!

Phillips126 8y ago
In my experience, Nim was the more enjoyable language to write. I had initially written an application in Golang that effectively keeps our DNS records in sync with CloudFlare across ~100+ machines (A, AAAA, CNAME, etc). The application was simple enough to write in Golang but I still wasn't crazy about the error handling (if err != nil...) after every few lines, as well as the large binary size once compiled (although I understand the reason for its size). To see if I could do better, I re-wrote the application in Nim, a language I've always had a lot of interest in. With the logic already figured out the code writing was quick and easy. I found the finished code to be cleaner and more concise and when it came time to compile I was excited to find a binary that was only 83kb in comparison to the 6mb binary of the Golang version. Of course your miles may vary and there are many advantages/disadvantages to every language but I personally look forward to writing more Nim in the future :)

dagenix 8y ago

Something about the phrase "it doesn't get bogged down in theory" really bothers me. What's wrong with having a good theoretical foundation?

athenot 8y ago
When theoretical purity is a main goal, very often usability suffers if your problem doesn't 100% model in said theory.
- fb03 8y ago
  [stares at haskell seductively]
- ilaksh 8y ago
  In my opinion Rust suffers from this type of problem. I actually suspect but haven't proven that I can make very memory or type 'safe' programs with Nim. I guess it goes back to practical necessity or reality for starters though. Do we need to or can we really prove that our programs are safe somehow? Is that something we generally need to the expense of everything else? But Rust ergonomics have been getting better and in my opinion some of the Rust guarantees may put it in an elite category of languages along with Nim but for totally different reasons.
  - rafaelvasco 8y ago
    Yeah, I tried reading some code to see if I could get a grasp on Rust, but found that the language puts too much friction on the developer, when writing or reading code. The syntax ends up too dense. For gamedev particularly, I think Rust is just too much, though I can understand it's value if you're coding highly concurrent code with huge memory safety needs.
- joel_ms 8y ago
  Do you have any examples? In my experience theoretical purity is largely independent of usability, which I find is more a function of the language's expressibility and the available abstractions (and how well those abstractions play together.) Take Elm, Haskell and Agda/Idris as examples of four programming languages with strong theoretical foundations, that also vary widely in expressibility and usability Elm is (imho) very usable even when teaching beginners unfamiliar with the ML-style syntax. The main abstraction is parametric polymorphism (generics in oop-terms), no subtyping with inheritance and no typeclass/interface mechanism. The language has a carefully crafted culture to maintain the beginner-friendliness of the language, explicitly at the expense of expressibility (but not usability.) I personally find elm to be an incredibly usable language, specifically because it's both simple and theoretically pure. Less to understand, for more gained reliability. More practically, I often prototype completely without type signatures, relying on type inference to make sure that I'm not doing anything nonsensical. The end result (for me at least) is the speed and ease of a dynamic language, with the reliability of a statically typed language. Haskell (without GHC extensions) offers more abstractions and is consequently "less usable" in the sense that you need to understand more theory to use things like Higher Kinded Types and whatnot. By adding GHC extensions you can gradually ramp up the expressibility (by adding abstractions,) while at the same time making the language (slightly) more difficult to use. You can get almost all the way to dependent types which brings us to.. Agda and Idris offers an incredibly powerful mechanism for abstraction called dependent types, where you essentially program your type checker as a logic. But they are (somewhat infamously) difficult to use due to having to understand the consequences of having computations at the type-level (and beyond) and consequently at compile time. If any of those are any less pure than the other it's probably Haskell, and that's more due to the ad hoc nature of the GHC extension system, which allows you to combine extensions in problematic ways that can hide impurity. They all compile based on some type theory as a model of computation, but those type theories can vary widely in how complex they are to understand, but the level of complexity doesn't make anything more or less pure. All of them also offers some degree of escape hatch from their "theoretical purity"-prison. Elm has its ports for js interop, Haskell has unsafeIO and friends, Agda has FFI to both js and haskell depending on backend, and I'm guessing Idris has some way of doing this as well. In this sense Elm is probably the most pure.