12 ms·

Nim Programming Language v0.15.0 released

142 points by dom96 10y ago

qwertyuiop924 10y ago
I looked at Nim briefly. It seemed cool, but there were some things that I just heavily disagree with. Forcing a keyword for discard means that there's an incentive for imperative code not to return a value, whereas I argue that that should be encouraged. Also, I find the macro system unweildy to use, especially coming from Lisp.
- shakna 10y ago
  From my Python background, Nim felt great. However, once I started a reasonably sized project, getting Nim to compile it became difficult. Lots of small little quirks that weren't greatly documented. However, when it did build, it was reasonably fast, and allowed me to tweak the C code when I disagreed with the compiler. Macros were still getting developed, last I played with Nim, but I'm not sure comparing with Lisp is fair. I adore Lisp, and its macros. (Both CL style and Scheme). But most languages are designed to constrain the programmer to a way of thinking, a series of patterns. Lisp was the opposite. Even in languages that try to give the programmer flexibility, they miss the power of Lisp's homoiconity. That being said, I think Nim is trying to find a middle ground between Python's "only one way to do it" and Lisp's "get out of the programmers way". Its a decent language, albeit with a tiny, rather opinionated, development team.
  - qwertyuiop924 10y ago
    They're still in development? Well then, maybe there's hope.
    - dom96 10y ago
      The whole language is still in development. If there are things you dislike, like the macros, then please submit some bug reports on Github[1] or talk to us on IRC[2] and Gitter[3]. Ideally, help us improve it by submitting pull requests :) 1 - https://github.com/nim-lang/Nim/issues https://github.com/nim-lang/Nim/issues 2 - irc.freenode.net #nim 3 - https://gitter.im/nim-lang/Nim https://gitter.im/nim-lang/Nim
    - shakna 10y ago
      Just a shout out to dom96 below, that guy was awesome when I was blindly fumbling with the language. Snappy responses to Github Issues, with really clear, really polite responses. Even when I was an idiot.
      - dom96 10y ago
        Thanks! I don't remember exactly what you asked, but don't put yourself down, everybody has to start somewhere :)
  - progman 10y ago
    > Lots of small little quirks that weren't greatly documented. For instance? > But most languages are designed to constrain the programmer to a way of thinking, a series of patterns. Lisp was the opposite. Lisp is still the opposite. Exactly this is the problem of Lisp: It is too powerful. I admire Lisp for its power, and there actually is no other language with such a freedom. Everyone can write his own DSL to simplify his task. Writing DSLs is extremely easy in Lisp. However, this doesn't profit maintainability, and it makes sharing code with others difficult. You actually need a lot of discipline that you code in such a way that it remains maintainable. In teams you need to constrain the way of thinking otherwise you can quickly run into chaos. Java is the opposite of Lisp. You cannot code productively in Java unless you use a sophisticated framework. Such frameworks force you to a certain style of coding which profits maintainability. That is one factor which explains the huge success of Java in business. Nim and Rust combine both paradigms. They provide a certain degree of freedom, and they require a certain degree of discipline. Haskell requires an extreme amount of discipline. In case of Haskell's freedom I am not convinced.
    - shakna 10y ago
      > Lots of small little quirks that weren't greatly documented. > For instance? Nimble file naming [0]. It must end in '.nimble', and must have at least character in front of that suffix, but the prefix doesn't actually matter. I'm not convinced on the maintainability argument. Many, many projects have a coding style guide. LISPs require one too. Once you have one, maintaining the code becomes as difficult as any other language. I've encountered unmaintainable Python code [1], and insanely well documented Scheme code [2]. I'm not sure the language has much to do with it, apart from supporting a wide range of paradigms and patterns. I'm not sure black-boxing through use of a sophisticated framework is any better than the way you work in more flexible languages. Here's my take: * Nim is great. The use of the 'auto' keyword let me be productive using it. * Scheme is great. It lets me do insane things, and the compiler will optimise it to work, and well. (Rather than breaking three similar function into pieces, I can make one function that generates all three functions using their commonalities). * Java is the smart kid at college who always answers questions in the form of a thesis. He isn't wrong, but you don't really remember what he was saying. [0] https://github.com/nim-lang/nimble/issues/166 https://github.com/nim-lang/nimble/issues/166 [1] Hence why things like this exist: http://docs.python-guide.org/en/latest/writing/structure/ http://docs.python-guide.org/en/latest/writing/structure/ [2] http://cvs.savannah.gnu.org/viewvc/slib/slib/alist.scm?revision=1.6&view=markup&pathrev=MAIN http://cvs.savannah.gnu.org/viewvc/slib/slib/alist.scm?revis...
- KirinDave 10y ago
  I don't see how a keyword that allows return values to be ignored creates an incentive to create void functions. I sort of find the idea refreshing myself. As a full time Clojure developer, I consider Nim to be the closest thing I can find to what I want for a great experience coding closer to the bare metal.
  - drewr 10y ago
    Can you say more about what you like?
  - qwertyuiop924 10y ago
    It's not so much that it allows it to be ignored, it's that if you want it to be ignored, you have to use that keyword. It means that there's syntactic noise in cases where you don't care about the return value of a function that has one, and thus discourages you from writing functions like that.
    - dom96 10y ago
      The idea behind this feature is to ensure that you don't lose important data, not to discourage you from writing functions which return values. For cases where a functions return value is truly optional, you can use the {.discardable.} pragma.
      - qwertyuiop924 10y ago
        Huh. Interesting idea. I suppose that could work. I'm still not wholly convinced that Nim is for me, but you've definitely alleviated some of my biggest concerns.
- FraaJad 10y ago
  It's hard to please a Lisper about any other language's macro system. So, this is a wash.
  - ternaryoperator 10y ago
    It's hard to please a Lisper about any other language's features. FTFY.
    - deleted 10y ago
      [deleted]
    - progman 10y ago
      I disagree. I have written a lot of Lisp and Scheme code, and now I am very content with Nim. I also tried Rust and Haskell but those languages are too cluttering for me. Nim is compact, well readable, powerful and performant. Nim developed from the bottom up, being closely related to C which is nice and makes porting to other platforms easy. The Nim development team adds only features which really make sense. If they just remove those immature ugly features like strong spaces and the redundancy of underscores then Nim 2.0 could be a really great language.
      - qwertyuiop924 10y ago
        OTOH, as a schemer, I much prefer Haskell and Rust to Nim, both theoretically and in practice. What syntax and abstractions you like are down to how you think, and Lisp programmers are programmers like any other, not incarnations of the spirit of smugness, as many people paint us.
        progman 10y ago
        > What syntax and abstractions you like are down to how you think Obviously this is not only my problem because there are only sparely applications written in Haskell. It is possible to write real world applications in Haskell, as proven by Leksah and the window manager xmonad. However, would you write an MS Office clone in Haskell? I wouldn't. I am still honestly interested in Haskell but I cannot understand why the cabal hell has not been fixed yet. Sandboxes and VMs are no option for me. Rust, Nim, and many other languages don't have this problem which points out that the cabal hell is due to Haskell's nature. Rust is another story. It is way more practical than Haskell, and I would use it for safety and systems programming. Nim however has become my favorite after a long journey of languages because I am really productive with it. Only Lisp has a similar productivity, and sometimes I still use it. Nim has the advantage of being very close to C which makes porting to other platforms extremely easy -- and hence also all my Nim code.
- agentgt 10y ago
  I have the same problem with almost all new languages including Rust: everything should be an expression and not a statement. Even conditional logic constructs (if/else) should be an expression (i.e. return a value). The language doesn't even have to be pure or hard core FP to follow this philosophy.
  - nathancahill 10y ago
    I highly agree, especially about the if/else. The more I code, the more I try to elimante branching. If statements as expressions would be ideal.
    - qznc 10y ago
      Most mainstream languages (C, Java, etc) have this. The ternary operator ?:
      - 35bge57dtjku 10y ago
        That's like farting in the bathtub and calling it a hot tub.
        tigershark 10y ago
        Why? It is an expression, not a statement regardless of your farting nonsense.
        35bge57dtjku 10y ago
        Because they aren't the same thing.
  - hermanradtke 10y ago
    Based on my understanding, Rust is an expressive language. What have you seen that is not expressive?
  - captainmuon 10y ago
- nnq 10y ago
  Imperative code benefits a lot in readability and maintainability if it follows some kind of CQS pattern ( https://en.wikipedia.org/wiki/Command%E2%80%93query_separation https://en.wikipedia.org/wiki/Command%E2%80%93query_separati... , http://martinfowler.com/bliki/CommandQuerySeparation.html http://martinfowler.com/bliki/CommandQuerySeparation.html ). Never used Nim but its `discard` keyword seems to nudge people in this direction. Yeah, looking at it from the perspective an utopical pure functional world this seems as much of an abomination as "out arguments" in C# ...but in real world code things look different :)
  - qwertyuiop924 10y ago
    CQS is neat, but return values on imperative functions are really useful. For one thing, it allows you to compress your API, have an action that can be used solely for the side effect, or for the value of that expression. In addition, you can use it to determine success or failure, and other important information about the function.
anta40 10y ago
I do like Python (my work mostly done in Java, though). A few years ago, I was looking for a language with Python-like expressiveness, with system programming capabilities ala C. Seems like Nim is the answer :)
- borplk 10y ago
  Yes Nim has the reputation of being a Python-like system programming language.
  - progman 10y ago
    Not only that. Nim also has benefits like Ada's range types, a sophisticated macro system, and Perl's native regular expression syntax. It also compiles to C which makes porting to other platforms easy.
    - vram22 10y ago
      >Nim also has benefits like Ada's range types Are Ada's range types similar to D's, or quite different? https://dlang.org/phobos/std_range.html https://dlang.org/phobos/std_range.html The above page links to the one below - the one below is about the concepts, by Andrei Alexandrescu (who joined Walter Bright in developing D). http://www.informit.com/articles/printerfriendly/1407357 http://www.informit.com/articles/printerfriendly/1407357
      - progman 10y ago
        I know Ada not D. Nim's subrange are close to Ada. If you define a type t1 = range [5..20] and you assign a value of 1 to a variable of type t1 then you get a compilation or runtime error.
        vram22 10y ago
        Ah, then that is similar to Pascal too, from its early versions, IIRC, not just Turbo Pascal onwards.
mastax 10y ago
> The multisync macro was implemented to enable you to define both synchronous and asynchronous IO procedures without having to duplicate a lot of code. This is great! There are a lot of little things like this in the nim standard library that make life a lot easier. I should write more nim.
- lmm 10y ago
  That shouldn't need a macro though. With higher-kinded types you can just write generic code that operates on futures or regular values.
  - nnq 10y ago
    That shouldn't need a higher-kinded type though. With macros you can just write generic code that operates on futures or regular values.
    - lmm 10y ago
      Code that uses macros is no longer just code. You can't reason about them like normal code, nor use automated tools the way you usually would.
    - virtualwhys 10y ago
      > that operates on futures or regular values. but what is the return type? The multisync example shows separate generated methods that return `string` and `Future[string]` depending on the method argument. If that's the case then blocking and non-blocking operations need to be treated separately since operations defined on a result of `Future[string]` are not the same as those available on `string`. HKTs not only allow for both method argument and return type to be polymorphic, but also allow one to define the same operations (like map, flatMap/bind, fold, etc.) on the wrapped type.
- dom96 10y ago
  Glad you like it! I wrote it while I was improving the httpclient module which otherwise would have a lot of duplication. Now it has an (almost) perfectly symmetrical API for both synchronous and asynchronous sockets :)
Annatar 10y ago
Nim is a powerful statically typed language that allows the programmer expressiveness without compromising run-time performance. As a general purpose programming language, it gives the same sort of power and performance as C++, but in a nicer package and with even more powerful tools! (Exasperated) nooo, nooo, nooooo, not YET ANOTHER language! How many do we need?!? Stop inventing new languages, this is getting to be ridiculous, where every Joe Blow with an ego wants to make his mark upon the world! STOP! This is one of the reasons why computers suck.
- minitech 10y ago
  > where every Joe Blow with an ego wants to make his mark upon the world Yeah, definitely couldn’t have anything to do with trying to improve tooling for everyone.
  - hobo_mark 10y ago
    Incidentally, Jon Blow (the game developer) is actually creating a new language (primarily targeted at games though). https://youtube.com/channel/UCCuoqzrsHlwv1YyPKLuMDUQ https://youtube.com/channel/UCCuoqzrsHlwv1YyPKLuMDUQ
    - Annatar 10y ago
      Yet another object oriented language? No, no, no, enough! We already have (persistent) objects: they're called files. Object oriented programming in the 21st century, in times of ANSI Common LISP and functional, stateless programming? Wow. No!!!
  - Annatar 10y ago
    Every single nimrod out there thinks his way is better, and that they're improving the tooling. What if the assumption is wrong, the tooling is just fine, and the problem is in the nimrod?
- lazzlazzlazz 10y ago
  Nim has been around for years and years - it's a regular feature on Hacker News. Where are you coming from?
dom96 10y ago
Nim developer here, I'm glad to see so much enthusiasm for Nim. I'm currently writing a book about it called Nim in Action[1] and would love to know what you guys think about it. The first chapter is free[2], so even if you don't intend to buy it you can still take a look at it. We also have a BountySource campaign[3], so if you would like to support us please consider making a donation. Finally, please feel free to AMA! 1 - https://manning.com/books/nim-in-action?a_aid=niminaction&a_bid=78a27e81 https://manning.com/books/nim-in-action?a_aid=niminaction&a_... 2 - https://manning.com/books/nim-in-action?a_aid=niminaction&a_bid=78a27e81#downloads https://manning.com/books/nim-in-action?a_aid=niminaction&a_... 3 - https://salt.bountysource.com/teams/nim https://salt.bountysource.com/teams/nim
- progman 10y ago
  I have purchased Nim in Action at the first version, and I recommend it to anyone who is seriously interested in Nim.
- bjourne 10y ago
  I wonder how Nim's cycle detection work? It is said in the docs that Nim never scans the whole heap, but I believe in worst cases you have to scan the whole heap to detect cycles. Also how does the gc trace variables on the stack? How do you determine if a value is a pointer to an object or an integer?
  - dom96 10y ago
    I'm afraid I don't know enough about Nim's GC to answer these questions. As far as I know, variables are only traced if their type is `ref`. So the type system helps the GC a lot here I think.
  - Araq 10y ago
    Good questions. I'm afraid the documentation is seriously out of date about the GC: It used to implement a variant of "trial deletion" so that "never scans the whole heap" used to refer to the fact that it doesn't use traditional mark&sweep, but only scans the subgraph(s) leading to the cycles. Of course you can always create a "subgraph" that spans the whole heap, so even for trial deletion it is a dubious claim. Since version 0.14 (iirc) however, Nim uses a traditional mark&sweep backup GC to collect cycles. Reasons: Trial deletion in practice is much slower. For all versions of the GC is stack is scanned conservatively as precise stack scanning is simply too expensive when C is your main target.
sharpercoder 10y ago
With so many programming languages around looking very similar, and realising the enourmous tough challenge to get adoption: why do programmers pursue writing a general purpose language and trying to have it adopted?
- throwaway7645 10y ago
  Every language has pros/cons and applicable use cases. Think of Python. It is a beautiful language that is high level, uses white space, but requires the python VM and is very slow. Nim has a somewhat pythonic syntax, compiles to C and then binary executables and is very fast with good metaprogramming facilities. That is appealing to a lot of people. I encourage you to read the free chapter of Nim In Action as the author does a good job explaining why.
  - JadeNB 10y ago
    > I encourage you to read the free chapter of Nim In Action as the author does a good job explaining why. Links: https://www.manning.com/books/nim-in-action https://www.manning.com/books/nim-in-action and (for the free chapter) https://manning-content.s3.amazonaws.com/download/1/f2a2c55-0538-4405-8b5f-4ee6a104d860/Picheta_Nim_MEAP_V08_ch1.pdf https://manning-content.s3.amazonaws.com/download/1/f2a2c55-... .
- gokr 10y ago
  A solid good enough reason is because it's fun! But in the specific case of Nim - AFAIK there aren't that many languages around with a similar set of characteristics. For me the killer is the combination of GC (I am quite fine with not having to bother with memory management), readability, reasonable high levelness including closures etc, nice OO support, extremely good C and C++ interop and really good performance.

142 points by dom96 10y ago

I looked at Nim briefly. It seemed cool, but there were some things that I just heavily disagree with. Forcing a keyword for discard means that there's an incentive for imperative code not to return a value, whereas I argue that that should be encouraged. Also, I find the macro system unweildy to use, especially coming from Lisp.

shakna 10y ago
From my Python background, Nim felt great. However, once I started a reasonably sized project, getting Nim to compile it became difficult. Lots of small little quirks that weren't greatly documented. However, when it did build, it was reasonably fast, and allowed me to tweak the C code when I disagreed with the compiler. Macros were still getting developed, last I played with Nim, but I'm not sure comparing with Lisp is fair. I adore Lisp, and its macros. (Both CL style and Scheme). But most languages are designed to constrain the programmer to a way of thinking, a series of patterns. Lisp was the opposite. Even in languages that try to give the programmer flexibility, they miss the power of Lisp's homoiconity. That being said, I think Nim is trying to find a middle ground between Python's "only one way to do it" and Lisp's "get out of the programmers way". Its a decent language, albeit with a tiny, rather opinionated, development team.
- qwertyuiop924 10y ago
  They're still in development? Well then, maybe there's hope.
  - dom96 10y ago
    The whole language is still in development. If there are things you dislike, like the macros, then please submit some bug reports on Github[1] or talk to us on IRC[2] and Gitter[3]. Ideally, help us improve it by submitting pull requests :) 1 - https://github.com/nim-lang/Nim/issues https://github.com/nim-lang/Nim/issues 2 - irc.freenode.net #nim 3 - https://gitter.im/nim-lang/Nim https://gitter.im/nim-lang/Nim
  - shakna 10y ago
    Just a shout out to dom96 below, that guy was awesome when I was blindly fumbling with the language. Snappy responses to Github Issues, with really clear, really polite responses. Even when I was an idiot.
    - dom96 10y ago
      Thanks! I don't remember exactly what you asked, but don't put yourself down, everybody has to start somewhere :)
- progman 10y ago
  > Lots of small little quirks that weren't greatly documented. For instance? > But most languages are designed to constrain the programmer to a way of thinking, a series of patterns. Lisp was the opposite. Lisp is still the opposite. Exactly this is the problem of Lisp: It is too powerful. I admire Lisp for its power, and there actually is no other language with such a freedom. Everyone can write his own DSL to simplify his task. Writing DSLs is extremely easy in Lisp. However, this doesn't profit maintainability, and it makes sharing code with others difficult. You actually need a lot of discipline that you code in such a way that it remains maintainable. In teams you need to constrain the way of thinking otherwise you can quickly run into chaos. Java is the opposite of Lisp. You cannot code productively in Java unless you use a sophisticated framework. Such frameworks force you to a certain style of coding which profits maintainability. That is one factor which explains the huge success of Java in business. Nim and Rust combine both paradigms. They provide a certain degree of freedom, and they require a certain degree of discipline. Haskell requires an extreme amount of discipline. In case of Haskell's freedom I am not convinced.
  - shakna 10y ago
    > Lots of small little quirks that weren't greatly documented. > For instance? Nimble file naming [0]. It must end in '.nimble', and must have at least character in front of that suffix, but the prefix doesn't actually matter. I'm not convinced on the maintainability argument. Many, many projects have a coding style guide. LISPs require one too. Once you have one, maintaining the code becomes as difficult as any other language. I've encountered unmaintainable Python code [1], and insanely well documented Scheme code [2]. I'm not sure the language has much to do with it, apart from supporting a wide range of paradigms and patterns. I'm not sure black-boxing through use of a sophisticated framework is any better than the way you work in more flexible languages. Here's my take: * Nim is great. The use of the 'auto' keyword let me be productive using it. * Scheme is great. It lets me do insane things, and the compiler will optimise it to work, and well. (Rather than breaking three similar function into pieces, I can make one function that generates all three functions using their commonalities). * Java is the smart kid at college who always answers questions in the form of a thesis. He isn't wrong, but you don't really remember what he was saying. [0] https://github.com/nim-lang/nimble/issues/166 https://github.com/nim-lang/nimble/issues/166 [1] Hence why things like this exist: http://docs.python-guide.org/en/latest/writing/structure/ http://docs.python-guide.org/en/latest/writing/structure/ [2] http://cvs.savannah.gnu.org/viewvc/slib/slib/alist.scm?revision=1.6&view=markup&pathrev=MAIN http://cvs.savannah.gnu.org/viewvc/slib/slib/alist.scm?revis...
KirinDave 10y ago
I don't see how a keyword that allows return values to be ignored creates an incentive to create void functions. I sort of find the idea refreshing myself. As a full time Clojure developer, I consider Nim to be the closest thing I can find to what I want for a great experience coding closer to the bare metal.
- drewr 10y ago
  Can you say more about what you like?
- qwertyuiop924 10y ago
  It's not so much that it allows it to be ignored, it's that if you want it to be ignored, you have to use that keyword. It means that there's syntactic noise in cases where you don't care about the return value of a function that has one, and thus discourages you from writing functions like that.
  - dom96 10y ago
    The idea behind this feature is to ensure that you don't lose important data, not to discourage you from writing functions which return values. For cases where a functions return value is truly optional, you can use the {.discardable.} pragma.
    - qwertyuiop924 10y ago
      Huh. Interesting idea. I suppose that could work. I'm still not wholly convinced that Nim is for me, but you've definitely alleviated some of my biggest concerns.
FraaJad 10y ago
It's hard to please a Lisper about any other language's macro system. So, this is a wash.
- ternaryoperator 10y ago
  It's hard to please a Lisper about any other language's features. FTFY.
  - deleted 10y ago
    [deleted]
  - progman 10y ago
    I disagree. I have written a lot of Lisp and Scheme code, and now I am very content with Nim. I also tried Rust and Haskell but those languages are too cluttering for me. Nim is compact, well readable, powerful and performant. Nim developed from the bottom up, being closely related to C which is nice and makes porting to other platforms easy. The Nim development team adds only features which really make sense. If they just remove those immature ugly features like strong spaces and the redundancy of underscores then Nim 2.0 could be a really great language.
    - qwertyuiop924 10y ago
      OTOH, as a schemer, I much prefer Haskell and Rust to Nim, both theoretically and in practice. What syntax and abstractions you like are down to how you think, and Lisp programmers are programmers like any other, not incarnations of the spirit of smugness, as many people paint us.
      - progman 10y ago
        > What syntax and abstractions you like are down to how you think Obviously this is not only my problem because there are only sparely applications written in Haskell. It is possible to write real world applications in Haskell, as proven by Leksah and the window manager xmonad. However, would you write an MS Office clone in Haskell? I wouldn't. I am still honestly interested in Haskell but I cannot understand why the cabal hell has not been fixed yet. Sandboxes and VMs are no option for me. Rust, Nim, and many other languages don't have this problem which points out that the cabal hell is due to Haskell's nature. Rust is another story. It is way more practical than Haskell, and I would use it for safety and systems programming. Nim however has become my favorite after a long journey of languages because I am really productive with it. Only Lisp has a similar productivity, and sometimes I still use it. Nim has the advantage of being very close to C which makes porting to other platforms extremely easy -- and hence also all my Nim code.
agentgt 10y ago
I have the same problem with almost all new languages including Rust: everything should be an expression and not a statement. Even conditional logic constructs (if/else) should be an expression (i.e. return a value). The language doesn't even have to be pure or hard core FP to follow this philosophy.
- nathancahill 10y ago
  I highly agree, especially about the if/else. The more I code, the more I try to elimante branching. If statements as expressions would be ideal.
  - qznc 10y ago
    Most mainstream languages (C, Java, etc) have this. The ternary operator ?:
    - 35bge57dtjku 10y ago
      That's like farting in the bathtub and calling it a hot tub.
      - tigershark 10y ago
        Why? It is an expression, not a statement regardless of your farting nonsense.
        35bge57dtjku 10y ago
        Because they aren't the same thing.
- hermanradtke 10y ago
  Based on my understanding, Rust is an expressive language. What have you seen that is not expressive?
- captainmuon 10y ago
nnq 10y ago
Imperative code benefits a lot in readability and maintainability if it follows some kind of CQS pattern ( https://en.wikipedia.org/wiki/Command%E2%80%93query_separation https://en.wikipedia.org/wiki/Command%E2%80%93query_separati... , http://martinfowler.com/bliki/CommandQuerySeparation.html http://martinfowler.com/bliki/CommandQuerySeparation.html ). Never used Nim but its `discard` keyword seems to nudge people in this direction. Yeah, looking at it from the perspective an utopical pure functional world this seems as much of an abomination as "out arguments" in C# ...but in real world code things look different :)
- qwertyuiop924 10y ago
  CQS is neat, but return values on imperative functions are really useful. For one thing, it allows you to compress your API, have an action that can be used solely for the side effect, or for the value of that expression. In addition, you can use it to determine success or failure, and other important information about the function.

anta40 10y ago

I do like Python (my work mostly done in Java, though). A few years ago, I was looking for a language with Python-like expressiveness, with system programming capabilities ala C. Seems like Nim is the answer :)

borplk 10y ago
Yes Nim has the reputation of being a Python-like system programming language.
- progman 10y ago
  Not only that. Nim also has benefits like Ada's range types, a sophisticated macro system, and Perl's native regular expression syntax. It also compiles to C which makes porting to other platforms easy.
  - vram22 10y ago
    >Nim also has benefits like Ada's range types Are Ada's range types similar to D's, or quite different? https://dlang.org/phobos/std_range.html https://dlang.org/phobos/std_range.html The above page links to the one below - the one below is about the concepts, by Andrei Alexandrescu (who joined Walter Bright in developing D). http://www.informit.com/articles/printerfriendly/1407357 http://www.informit.com/articles/printerfriendly/1407357
    - progman 10y ago
      I know Ada not D. Nim's subrange are close to Ada. If you define a type t1 = range [5..20] and you assign a value of 1 to a variable of type t1 then you get a compilation or runtime error.
      - vram22 10y ago
        Ah, then that is similar to Pascal too, from its early versions, IIRC, not just Turbo Pascal onwards.

mastax 10y ago

> The multisync macro was implemented to enable you to define both synchronous and asynchronous IO procedures without having to duplicate a lot of code. This is great! There are a lot of little things like this in the nim standard library that make life a lot easier. I should write more nim.

lmm 10y ago
That shouldn't need a macro though. With higher-kinded types you can just write generic code that operates on futures or regular values.
- nnq 10y ago
  That shouldn't need a higher-kinded type though. With macros you can just write generic code that operates on futures or regular values.
  - lmm 10y ago
    Code that uses macros is no longer just code. You can't reason about them like normal code, nor use automated tools the way you usually would.
  - virtualwhys 10y ago
    > that operates on futures or regular values. but what is the return type? The multisync example shows separate generated methods that return `string` and `Future[string]` depending on the method argument. If that's the case then blocking and non-blocking operations need to be treated separately since operations defined on a result of `Future[string]` are not the same as those available on `string`. HKTs not only allow for both method argument and return type to be polymorphic, but also allow one to define the same operations (like map, flatMap/bind, fold, etc.) on the wrapped type.
dom96 10y ago
Glad you like it! I wrote it while I was improving the httpclient module which otherwise would have a lot of duplication. Now it has an (almost) perfectly symmetrical API for both synchronous and asynchronous sockets :)

Annatar 10y ago

Nim is a powerful statically typed language that allows the programmer expressiveness without compromising run-time performance. As a general purpose programming language, it gives the same sort of power and performance as C++, but in a nicer package and with even more powerful tools! (Exasperated) nooo, nooo, nooooo, not YET ANOTHER language! How many do we need?!? Stop inventing new languages, this is getting to be ridiculous, where every Joe Blow with an ego wants to make his mark upon the world! STOP! This is one of the reasons why computers suck.

minitech 10y ago
> where every Joe Blow with an ego wants to make his mark upon the world Yeah, definitely couldn’t have anything to do with trying to improve tooling for everyone.
- hobo_mark 10y ago
  Incidentally, Jon Blow (the game developer) is actually creating a new language (primarily targeted at games though). https://youtube.com/channel/UCCuoqzrsHlwv1YyPKLuMDUQ https://youtube.com/channel/UCCuoqzrsHlwv1YyPKLuMDUQ
  - Annatar 10y ago
    Yet another object oriented language? No, no, no, enough! We already have (persistent) objects: they're called files. Object oriented programming in the 21st century, in times of ANSI Common LISP and functional, stateless programming? Wow. No!!!
- Annatar 10y ago
  Every single nimrod out there thinks his way is better, and that they're improving the tooling. What if the assumption is wrong, the tooling is just fine, and the problem is in the nimrod?
lazzlazzlazz 10y ago
Nim has been around for years and years - it's a regular feature on Hacker News. Where are you coming from?

dom96 10y ago

Nim developer here, I'm glad to see so much enthusiasm for Nim. I'm currently writing a book about it called Nim in Action[1] and would love to know what you guys think about it. The first chapter is free[2], so even if you don't intend to buy it you can still take a look at it. We also have a BountySource campaign[3], so if you would like to support us please consider making a donation. Finally, please feel free to AMA! 1 - https://manning.com/books/nim-in-action?a_aid=niminaction&a_bid=78a27e81 https://manning.com/books/nim-in-action?a_aid=niminaction&a_... 2 - https://manning.com/books/nim-in-action?a_aid=niminaction&a_bid=78a27e81#downloads https://manning.com/books/nim-in-action?a_aid=niminaction&a_... 3 - https://salt.bountysource.com/teams/nim https://salt.bountysource.com/teams/nim

progman 10y ago
I have purchased Nim in Action at the first version, and I recommend it to anyone who is seriously interested in Nim.
bjourne 10y ago
I wonder how Nim's cycle detection work? It is said in the docs that Nim never scans the whole heap, but I believe in worst cases you have to scan the whole heap to detect cycles. Also how does the gc trace variables on the stack? How do you determine if a value is a pointer to an object or an integer?
- dom96 10y ago
  I'm afraid I don't know enough about Nim's GC to answer these questions. As far as I know, variables are only traced if their type is `ref`. So the type system helps the GC a lot here I think.
- Araq 10y ago
  Good questions. I'm afraid the documentation is seriously out of date about the GC: It used to implement a variant of "trial deletion" so that "never scans the whole heap" used to refer to the fact that it doesn't use traditional mark&sweep, but only scans the subgraph(s) leading to the cycles. Of course you can always create a "subgraph" that spans the whole heap, so even for trial deletion it is a dubious claim. Since version 0.14 (iirc) however, Nim uses a traditional mark&sweep backup GC to collect cycles. Reasons: Trial deletion in practice is much slower. For all versions of the GC is stack is scanned conservatively as precise stack scanning is simply too expensive when C is your main target.

sharpercoder 10y ago

With so many programming languages around looking very similar, and realising the enourmous tough challenge to get adoption: why do programmers pursue writing a general purpose language and trying to have it adopted?

throwaway7645 10y ago
Every language has pros/cons and applicable use cases. Think of Python. It is a beautiful language that is high level, uses white space, but requires the python VM and is very slow. Nim has a somewhat pythonic syntax, compiles to C and then binary executables and is very fast with good metaprogramming facilities. That is appealing to a lot of people. I encourage you to read the free chapter of Nim In Action as the author does a good job explaining why.
- JadeNB 10y ago
  > I encourage you to read the free chapter of Nim In Action as the author does a good job explaining why. Links: https://www.manning.com/books/nim-in-action https://www.manning.com/books/nim-in-action and (for the free chapter) https://manning-content.s3.amazonaws.com/download/1/f2a2c55-0538-4405-8b5f-4ee6a104d860/Picheta_Nim_MEAP_V08_ch1.pdf https://manning-content.s3.amazonaws.com/download/1/f2a2c55-... .
gokr 10y ago
A solid good enough reason is because it's fun! But in the specific case of Nim - AFAIK there aren't that many languages around with a similar set of characteristics. For me the killer is the combination of GC (I am quite fine with not having to bother with memory management), readability, reasonable high levelness including closures etc, nice OO support, extremely good C and C++ interop and really good performance.