3 ms·

Can someone sell me Nim in few sentences if I am a D user?

dymk 8y ago
Every feature you can possibly imagine, and then some. Not always a great thing. Features like implicit syntax rewriting macros or case-insensitive variable names are... interesting experiments in a language, but ultimately not good ideas. I’ve tried the language a few times over the years, and each time the compiler was just as buggy. Lots of corner cases to worry about with features, like generators working only if the code that invokes them can entirely be inlined.
- andrenth 8y ago
  Does it have algebraic data types and pattern matching?
  - alehander42 8y ago
    Yes. ADT are case objects: they are widely used. https://nim-lang.org/docs/tut2.html#object-oriented-programming-object-variants https://nim-lang.org/docs/tut2.html#object-oriented-programm... There are some macros for easier generation: https://github.com/andreaferretti/patty#constructing-variant-objects https://github.com/andreaferretti/patty#constructing-variant... There are pattern matching libs: pattern matching is implemented on top of metaprogramming. General pattern matching: the original https://github.com/andreaferretti/patty https://github.com/andreaferretti/patty https://github.com/alehander42/gara https://github.com/alehander42/gara (disclaimer: my lib) patty and gara should eventually combine into a single lib: including probably the current gara matching DSL(inspired by patty) and patty's variant DSL in the same place. AST pattern matching: optimized for macros, nice error reporting https://github.com/krux02/ast-pattern-matching https://github.com/krux02/ast-pattern-matching
    - andrenth 8y ago
      Cool. Do the pattern matching libraries check for exhaustiveness in the match cases? Do you see this eventually becoming part of the language?
      - dom96 8y ago
        > Do the pattern matching libraries check for exhaustiveness in the match cases? I'm not 100% sure, but I would guess yes. > Do you see this eventually becoming part of the language? I can answer this with some confidence: no. Nim is designed to have a small but very extensible core via metaprogramming. This is why we encourage users to write such macros. They may end up in our stdlib eventually but it's unlikely they'll be part of the language.
      - alehander42 8y ago
        At least gara can't check exhaustiveness now: require one to add `else` to check all cases: it might be harder in general make sure branches match each possible value. However it should be possible for sum types/enums: `case` already does it
- p0nce 8y ago
  I'll stick with D then :)
- bhauer 8y ago
  > Features like implicit syntax rewriting macros or case-insensitive variable names are... interesting experiments in a language, but ultimately not good ideas. I'm not too familiar with the specifics of Nim, but how are case-insensitive variable names a bad idea, except that notion is so unfamiliar to programmers? Flipped around, if a language were to be designed today in a vacuum, what is the argument in favor of case-sensitivity in variable names? My feeling is that we take case-sensitivity for granted because the vast majority of languages inherited that behavior from history's lineage of great programming languages. But re-evaluated without that history, case-sensitivity seems only to create potential confusion at best and opportunities for trolling and obfuscation at worst. Today's use case to indicate scope, mutability, or permissions is an artifact of this history. As programmers, we know how to read something like this in Java, but if we were able to completely erase our historical knowledge and consider language design without that baggage, this seems like bad language design: // Local variable square is instantiated equal to // SQUARE constant in class Square. Square square = Square.SQUARE; I'm not sure what alternative syntax we'd have today if we had never adopted case sensitivity in names to begin with, but my hunch is I would prefer it even if it involved more typing (e.g., prefix or suffix symbols). Admittedly, a statically analyzed language will have most case typographical mistakes found and corrected at compile time, so they are a lesser annoyance than case-sensitivity in other contexts (such as filenames or column names in database tables). Generally speaking, I would be in favor of a hard break to drop case-sensitivity across the board, but I'll put that on the same list as adopting the metric system in the US (titled: "LOL, good luck.").
  - dymk 8y ago
    A few reasons off the top of my head: * Simplifies refactoring tools. * Encourages a consistent style in the ecosystem from the beginning. * Not needing specialized tooling to grep for an identifier in a codebase. * Being able to Google a particular function name. * Consistency in identifier naming when looking at a stacktrace.
    - nitely 8y ago
      > Simplifies refactoring tools. How? we would just have case insensitive refactoring tools. > Encourages a consistent style in the ecosystem from the beginning. Python, C, Java, etc are case sensitive langs, and it's possible to define function names in all upper-case and do all kind of inconsistent styling. Python has pep8 for a reason. > Not needing specialized tooling to grep for an identifier in a codebase. If all langs were case-insensitive, all those tools would be case-insensitive by default (or we would all know the right combination of flags to make them behave). > Being able to Google a particular function name. Is google case sensitive? In any case the lang would define a preferred style, like all case-sensitive lang do anyway. > Consistency in identifier naming when looking at a stacktrace. Same as above. Parent said "if a language were to be designed today in a vacuum", I don't think any of your arguments hold.
jibal 8y ago
Not in a few sentences, no. D and Nim are comparable in many ways but use different approaches. If you like D then no reason to switch.
mratsim 8y ago
Timothee Cour who's a heavy contributor to both lang did a comparison 8 months ago: https://github.com/timotheecour/D_vs_nim https://github.com/timotheecour/D_vs_nim

dymk 8y ago

Every feature you can possibly imagine, and then some. Not always a great thing. Features like implicit syntax rewriting macros or case-insensitive variable names are... interesting experiments in a language, but ultimately not good ideas. I’ve tried the language a few times over the years, and each time the compiler was just as buggy. Lots of corner cases to worry about with features, like generators working only if the code that invokes them can entirely be inlined.

andrenth 8y ago
Does it have algebraic data types and pattern matching?
- alehander42 8y ago
  Yes. ADT are case objects: they are widely used. https://nim-lang.org/docs/tut2.html#object-oriented-programming-object-variants https://nim-lang.org/docs/tut2.html#object-oriented-programm... There are some macros for easier generation: https://github.com/andreaferretti/patty#constructing-variant-objects https://github.com/andreaferretti/patty#constructing-variant... There are pattern matching libs: pattern matching is implemented on top of metaprogramming. General pattern matching: the original https://github.com/andreaferretti/patty https://github.com/andreaferretti/patty https://github.com/alehander42/gara https://github.com/alehander42/gara (disclaimer: my lib) patty and gara should eventually combine into a single lib: including probably the current gara matching DSL(inspired by patty) and patty's variant DSL in the same place. AST pattern matching: optimized for macros, nice error reporting https://github.com/krux02/ast-pattern-matching https://github.com/krux02/ast-pattern-matching
  - andrenth 8y ago
    Cool. Do the pattern matching libraries check for exhaustiveness in the match cases? Do you see this eventually becoming part of the language?
    - dom96 8y ago
      > Do the pattern matching libraries check for exhaustiveness in the match cases? I'm not 100% sure, but I would guess yes. > Do you see this eventually becoming part of the language? I can answer this with some confidence: no. Nim is designed to have a small but very extensible core via metaprogramming. This is why we encourage users to write such macros. They may end up in our stdlib eventually but it's unlikely they'll be part of the language.
    - alehander42 8y ago
      At least gara can't check exhaustiveness now: require one to add `else` to check all cases: it might be harder in general make sure branches match each possible value. However it should be possible for sum types/enums: `case` already does it
p0nce 8y ago
I'll stick with D then :)
bhauer 8y ago
> Features like implicit syntax rewriting macros or case-insensitive variable names are... interesting experiments in a language, but ultimately not good ideas. I'm not too familiar with the specifics of Nim, but how are case-insensitive variable names a bad idea, except that notion is so unfamiliar to programmers? Flipped around, if a language were to be designed today in a vacuum, what is the argument in favor of case-sensitivity in variable names? My feeling is that we take case-sensitivity for granted because the vast majority of languages inherited that behavior from history's lineage of great programming languages. But re-evaluated without that history, case-sensitivity seems only to create potential confusion at best and opportunities for trolling and obfuscation at worst. Today's use case to indicate scope, mutability, or permissions is an artifact of this history. As programmers, we know how to read something like this in Java, but if we were able to completely erase our historical knowledge and consider language design without that baggage, this seems like bad language design: // Local variable square is instantiated equal to // SQUARE constant in class Square. Square square = Square.SQUARE; I'm not sure what alternative syntax we'd have today if we had never adopted case sensitivity in names to begin with, but my hunch is I would prefer it even if it involved more typing (e.g., prefix or suffix symbols). Admittedly, a statically analyzed language will have most case typographical mistakes found and corrected at compile time, so they are a lesser annoyance than case-sensitivity in other contexts (such as filenames or column names in database tables). Generally speaking, I would be in favor of a hard break to drop case-sensitivity across the board, but I'll put that on the same list as adopting the metric system in the US (titled: "LOL, good luck.").
- dymk 8y ago
  A few reasons off the top of my head: * Simplifies refactoring tools. * Encourages a consistent style in the ecosystem from the beginning. * Not needing specialized tooling to grep for an identifier in a codebase. * Being able to Google a particular function name. * Consistency in identifier naming when looking at a stacktrace.
  - nitely 8y ago
    > Simplifies refactoring tools. How? we would just have case insensitive refactoring tools. > Encourages a consistent style in the ecosystem from the beginning. Python, C, Java, etc are case sensitive langs, and it's possible to define function names in all upper-case and do all kind of inconsistent styling. Python has pep8 for a reason. > Not needing specialized tooling to grep for an identifier in a codebase. If all langs were case-insensitive, all those tools would be case-insensitive by default (or we would all know the right combination of flags to make them behave). > Being able to Google a particular function name. Is google case sensitive? In any case the lang would define a preferred style, like all case-sensitive lang do anyway. > Consistency in identifier naming when looking at a stacktrace. Same as above. Parent said "if a language were to be designed today in a vacuum", I don't think any of your arguments hold.

jibal 8y ago

Not in a few sentences, no. D and Nim are comparable in many ways but use different approaches. If you like D then no reason to switch.

mratsim 8y ago

Timothee Cour who's a heavy contributor to both lang did a comparison 8 months ago: https://github.com/timotheecour/D_vs_nim https://github.com/timotheecour/D_vs_nim