8 ms·

Ask HN: Next programming language to learn: Nim vs. D?

smt88 8y ago
Do you have projects in mind? What languages are you most used to? That might help you decide. Learning a very different language is fun and useful.
- crypto-jeronimo 8y ago
  > Learning a very different language is fun and useful. Yes, that's one of my main motivations. I'm comfortable enough with Python, Java (comfortable doesn't mean I enjoy this one) and C. > Do you have projects in mind? Yes, both are solely for the purpose of enrichment of my current set of skills and knowledge: - Source control system that is a "lite" version of git. - A bit torrent client.
grawprog 8y ago
D
sdhgaiojfsa 8y ago
Need more data to compute a meaningful answer. What do you want our of your next language?
- crypto-jeronimo 8y ago
  I'm looking for a well-rounded language, which is versatile in the same direction as, e.g., Python is. Ideally, it would also enable expanding one's own set of programming skills and knowledge/practice of interesting paradigms (i.e., a mind-shift of sorts). Nice to have's: - a rich library ecosystem (like Python and Go, for instance) - as close to C as possible, in terms of speed
  - sam0x17 8y ago
    You definitely are looking for crystal language https://crystal-lang.org/ https://crystal-lang.org/
  - 3rdAccount 8y ago
    Nim is like a fast version of Python and Crystal is like a fast version of Ruby. Rust and Go also have some use in the same space, but they all differ in the details as in whether the GC exists and is enabled by default, is optional, or doesn't exist. Coming from Python, I found Nim to be the best for my mild systems programming needs. I haven't tried Crystal as it doesn't work on Windows (last I checked). Go is too simple/verbose and doesn't have enough language constructs by design. Rust seems like it is changing too much and too low level. I really wanted to like D, but had trouble getting up to speed in it. I bet it's much easier if you come from C++.
    - honewatson 8y ago
      Apart from some syntactic commonalities and expressiveness, Nim doesn't have a lot in common with Python. The idiomatic approach to solving problems in Python and Nim are different. I came from a strong Python background and now I prefer Nim to Python as a general purpose language and especially for writing scripts. Nim is highly productive and with excellent type safety. The compiler is relatively fast though maybe not as fast as D and certainly not as fast as Go. The compiler is a lot faster than Rust/Crystal/Pony and there is current work being done on incremental builds which should make it even faster. If you take a look at these benchmarks the Nim and D fastest versions are faster than Rust and on par with the fastest C++. Significantly, the fastest D version has double the lines of code as the fastest garbage collected version of Nim though the Nim version performs slightly faster. The fastest garbage collected version of Nim has exactly the same lines of code as Python. https://github.com/frol/completely-unscientific-benchmarks#linux-arch-linux-x64-intel-core-i7-4710hq-cpu-1 https://github.com/frol/completely-unscientific-benchmarks#l...
      - nimmer 8y ago
        > Apart from some syntactic commonalities and expressiveness, Nim doesn't have a lot in common with Python. > The idiomatic approach to solving problems in Python and Nim are different On a practical level, they are close enough to let you convert Python code to Nim with reformatting and replacing instead of doing a complete rewrite.
  - karmakaze 8y ago
    I've been looking for something similar to Python and Go as well. I can never seem to get the performance from Python that the great libraries do. Go is great for simple types but I haven't quite got good patterns for larger projects and run into performance issues with channels. Pony is where my current search and learning is at. I'll queue up Nim as another possibility.
deleted 8y ago
[deleted]
annywhey 8y ago
It's hard to pick between those two in particular. Nim is more fluid syntactically; D is more precise. D is also older and I would generally consider it more mature. (After trying both, I went with D. But in the future I want to use Zig for some of the lowest level code.)
- dom96 8y ago
  Other than maturity, what are the reasons you've chosen to go with D (and are now choosing to pursue Zig)?
  - annywhey 8y ago
    What I want in a language of this class is some ability to transition code from a slow/dynamic/generalized/exploratory phase to fast/static/specialized/checked. Both D and Nim offer features of that nature. (Something like Rust omits itself by forcing memory into a central role, leading to a lot of annotation boilerplate - it's correct for writing Servo or similarly complex parallelized systems, but I am not writing Servo.) When I left Nim, it was because I had serious concerns about the project being able to tame its rapid accumulation of features. I had no faith in all the things it advertised to actually work correctly. The dev process I witnessed was "cave in to toxic people who whinged a lot." D has a lot of warts from being around longer, but in the end, what I want to write code in anger with is something that can boast a well-engineered compiler, and D has not one compiler but more than one. That was years ago. To win me back you'll have to market a demonstration of similar stability. Zig is in a different category from any other option because its design allows me to tackle a piece of low-hanging fruit: a modernization of old C libraries that does not reinvent the universe, create a new ABI, introduce a runtime, or otherwise disrupt the original context. I can write basically the same kind of code in the same kind of style, but the language automatically pushes my attention to more edge cases and undefined conditions, and the compiler simplifies the build process, removing the preprocessor noise that tends to appear in substantial libraries.
    - dom96 8y ago
      That's fair. Can you name features in Nim that you feel are unnecessary? I have seen a similar sentiment in the past but rarely do people actually give examples of what they think could be removed (the biggest challenge for us right now is the removal of features in preparation for 1.0).
treeform 8y ago
I chose to learn nim coming from Python, because found C++ to be annoying and difficult. It feels like python but faster. I have compiled to to JS and integrated with complex C++ libraries. I like it so far. Metaprogramming is cool feature. Community is also really helpful.
kaushalmodi 8y ago
I have started using Nim fairly recently (past month). I actually wanted to start using it about a year back, but it never happened. But my return to Nim was a good step; this time I might be here for a while as I have started to understand the nitty-gritty details of the language [1]. Couple of reasons why I think Nim is an awesome language: 1. Syntax: It's beautiful. If you like Python syntax, you'll like this. On the other hand, it's much more concise, without losing readability. 2. Static type check, with a sprinkle of type inference only when assigning the initial value. 3. Proc/operator overloading: Have procedures (functions) named the same handle different data types differently. And the same with operators. 4. Support: Great support over Gitter, GitHub issues, Nim Forum, etc. Great devs! (though, I incorrectly thought earlier that that wasn't the case :)) 5. Makes me feel home: Hacking/coding in Nim comes the closest to coding in Emacs Lisp. In Emacs, if I want to understand what a function does, I look at its source code. I can do the same in Nim. 6. Editor support: The nim-mode Emacs major mode and ob-nim Org Babel package are awesome! 7. Documentation: Check out the Nim the index.html to search anything, and also Devdocs. 8. Whitespace: Tab not allowed, yay! 9. Not as easy as installing go/rust toolchains locally (without admin rights), but not difficult either. 10. The nimble tool (equivalent of pip) works great for building/distributing Nim projects. .. and much more! Computer science experts can talk about more benefits of Nim from systems programming point of view (GC, etc.). For my use case, where I use Nim as Python/Bash replacement, CLI utility development, it looks excellent so far. In plain terms, it's joy coding in Nim :) [1]: https://scripter.co/notes/nim/ https://scripter.co/notes/nim/
mabynogy 8y ago
Both and Chapel.
- jxub 8y ago
  Care to expand on Chapel? Is it used somewhere in prod?
  - mabynogy 8y ago
    Probably yeah as it's done by Cray. The main feature of Chapel is to handle well the many levels of parallelism.
    - rurban 8y ago
      But then I would recommend Pony which is even better on parallelism.
      - mabynogy 8y ago
        I don't think so (for example Chapel does SIMD).
        rurban 8y ago
        Pony does SIMD also, is much faster and safer.
        benstrumental 8y ago
        Do you have any performance data that supports these claims? Does Pony support distributed memory parallelism? Here are some recent Chapel performance results: shared memory: https://twitter.com/ChapelLanguage/status/1002667358928814081 https://twitter.com/ChapelLanguage/status/100266735892881408... distributed memory: https://twitter.com/ChapelLanguage/status/1002589985839595521 https://twitter.com/ChapelLanguage/status/100258998583959552...

Do you have projects in mind? What languages are you most used to? That might help you decide. Learning a very different language is fun and useful.

crypto-jeronimo 8y ago
> Learning a very different language is fun and useful. Yes, that's one of my main motivations. I'm comfortable enough with Python, Java (comfortable doesn't mean I enjoy this one) and C. > Do you have projects in mind? Yes, both are solely for the purpose of enrichment of my current set of skills and knowledge: - Source control system that is a "lite" version of git. - A bit torrent client.

grawprog 8y ago

sdhgaiojfsa 8y ago

Need more data to compute a meaningful answer. What do you want our of your next language?

crypto-jeronimo 8y ago
I'm looking for a well-rounded language, which is versatile in the same direction as, e.g., Python is. Ideally, it would also enable expanding one's own set of programming skills and knowledge/practice of interesting paradigms (i.e., a mind-shift of sorts). Nice to have's: - a rich library ecosystem (like Python and Go, for instance) - as close to C as possible, in terms of speed
- sam0x17 8y ago
  You definitely are looking for crystal language https://crystal-lang.org/ https://crystal-lang.org/
- 3rdAccount 8y ago
  Nim is like a fast version of Python and Crystal is like a fast version of Ruby. Rust and Go also have some use in the same space, but they all differ in the details as in whether the GC exists and is enabled by default, is optional, or doesn't exist. Coming from Python, I found Nim to be the best for my mild systems programming needs. I haven't tried Crystal as it doesn't work on Windows (last I checked). Go is too simple/verbose and doesn't have enough language constructs by design. Rust seems like it is changing too much and too low level. I really wanted to like D, but had trouble getting up to speed in it. I bet it's much easier if you come from C++.
  - honewatson 8y ago
    Apart from some syntactic commonalities and expressiveness, Nim doesn't have a lot in common with Python. The idiomatic approach to solving problems in Python and Nim are different. I came from a strong Python background and now I prefer Nim to Python as a general purpose language and especially for writing scripts. Nim is highly productive and with excellent type safety. The compiler is relatively fast though maybe not as fast as D and certainly not as fast as Go. The compiler is a lot faster than Rust/Crystal/Pony and there is current work being done on incremental builds which should make it even faster. If you take a look at these benchmarks the Nim and D fastest versions are faster than Rust and on par with the fastest C++. Significantly, the fastest D version has double the lines of code as the fastest garbage collected version of Nim though the Nim version performs slightly faster. The fastest garbage collected version of Nim has exactly the same lines of code as Python. https://github.com/frol/completely-unscientific-benchmarks#linux-arch-linux-x64-intel-core-i7-4710hq-cpu-1 https://github.com/frol/completely-unscientific-benchmarks#l...
    - nimmer 8y ago
      > Apart from some syntactic commonalities and expressiveness, Nim doesn't have a lot in common with Python. > The idiomatic approach to solving problems in Python and Nim are different On a practical level, they are close enough to let you convert Python code to Nim with reformatting and replacing instead of doing a complete rewrite.
- karmakaze 8y ago
  I've been looking for something similar to Python and Go as well. I can never seem to get the performance from Python that the great libraries do. Go is great for simple types but I haven't quite got good patterns for larger projects and run into performance issues with channels. Pony is where my current search and learning is at. I'll queue up Nim as another possibility.

deleted 8y ago

[deleted]

annywhey 8y ago

It's hard to pick between those two in particular. Nim is more fluid syntactically; D is more precise. D is also older and I would generally consider it more mature. (After trying both, I went with D. But in the future I want to use Zig for some of the lowest level code.)

dom96 8y ago
Other than maturity, what are the reasons you've chosen to go with D (and are now choosing to pursue Zig)?
- annywhey 8y ago
  What I want in a language of this class is some ability to transition code from a slow/dynamic/generalized/exploratory phase to fast/static/specialized/checked. Both D and Nim offer features of that nature. (Something like Rust omits itself by forcing memory into a central role, leading to a lot of annotation boilerplate - it's correct for writing Servo or similarly complex parallelized systems, but I am not writing Servo.) When I left Nim, it was because I had serious concerns about the project being able to tame its rapid accumulation of features. I had no faith in all the things it advertised to actually work correctly. The dev process I witnessed was "cave in to toxic people who whinged a lot." D has a lot of warts from being around longer, but in the end, what I want to write code in anger with is something that can boast a well-engineered compiler, and D has not one compiler but more than one. That was years ago. To win me back you'll have to market a demonstration of similar stability. Zig is in a different category from any other option because its design allows me to tackle a piece of low-hanging fruit: a modernization of old C libraries that does not reinvent the universe, create a new ABI, introduce a runtime, or otherwise disrupt the original context. I can write basically the same kind of code in the same kind of style, but the language automatically pushes my attention to more edge cases and undefined conditions, and the compiler simplifies the build process, removing the preprocessor noise that tends to appear in substantial libraries.
  - dom96 8y ago
    That's fair. Can you name features in Nim that you feel are unnecessary? I have seen a similar sentiment in the past but rarely do people actually give examples of what they think could be removed (the biggest challenge for us right now is the removal of features in preparation for 1.0).

treeform 8y ago

I chose to learn nim coming from Python, because found C++ to be annoying and difficult. It feels like python but faster. I have compiled to to JS and integrated with complex C++ libraries. I like it so far. Metaprogramming is cool feature. Community is also really helpful.

kaushalmodi 8y ago

I have started using Nim fairly recently (past month). I actually wanted to start using it about a year back, but it never happened. But my return to Nim was a good step; this time I might be here for a while as I have started to understand the nitty-gritty details of the language [1]. Couple of reasons why I think Nim is an awesome language: 1. Syntax: It's beautiful. If you like Python syntax, you'll like this. On the other hand, it's much more concise, without losing readability. 2. Static type check, with a sprinkle of type inference only when assigning the initial value. 3. Proc/operator overloading: Have procedures (functions) named the same handle different data types differently. And the same with operators. 4. Support: Great support over Gitter, GitHub issues, Nim Forum, etc. Great devs! (though, I incorrectly thought earlier that that wasn't the case :)) 5. Makes me feel home: Hacking/coding in Nim comes the closest to coding in Emacs Lisp. In Emacs, if I want to understand what a function does, I look at its source code. I can do the same in Nim. 6. Editor support: The nim-mode Emacs major mode and ob-nim Org Babel package are awesome! 7. Documentation: Check out the Nim the index.html to search anything, and also Devdocs. 8. Whitespace: Tab not allowed, yay! 9. Not as easy as installing go/rust toolchains locally (without admin rights), but not difficult either. 10. The nimble tool (equivalent of pip) works great for building/distributing Nim projects. .. and much more! Computer science experts can talk about more benefits of Nim from systems programming point of view (GC, etc.). For my use case, where I use Nim as Python/Bash replacement, CLI utility development, it looks excellent so far. In plain terms, it's joy coding in Nim :) [1]: https://scripter.co/notes/nim/ https://scripter.co/notes/nim/

mabynogy 8y ago

Both and Chapel.

jxub 8y ago
Care to expand on Chapel? Is it used somewhere in prod?
- mabynogy 8y ago
  Probably yeah as it's done by Cray. The main feature of Chapel is to handle well the many levels of parallelism.
  - rurban 8y ago
    But then I would recommend Pony which is even better on parallelism.
    - mabynogy 8y ago
      I don't think so (for example Chapel does SIMD).
      - rurban 8y ago
        Pony does SIMD also, is much faster and safer.
        benstrumental 8y ago
        Do you have any performance data that supports these claims? Does Pony support distributed memory parallelism? Here are some recent Chapel performance results: shared memory: https://twitter.com/ChapelLanguage/status/1002667358928814081 https://twitter.com/ChapelLanguage/status/100266735892881408... distributed memory: https://twitter.com/ChapelLanguage/status/1002589985839595521 https://twitter.com/ChapelLanguage/status/100258998583959552...