11 ms·

Nim Programming Language 0.11.0 released

162 points by def- 11y ago

zyxley 11y ago
I hadn't seen this language before, but it looks neat. Coming from a Ruby background, it's very interesting to see Nim's pragmas and templates, as they look rather like type-checked and compiled cousins of metaprogramming methods.
- hliyan 11y ago
  I concur. This is the first time I'm seeing it too. I come from a C++ background, with recent experience in Python and JavaScript. I'm rarely impressed by new languages, but for some reason, Nim feels like what I wish Python was.
  - progman 11y ago
    Indeed. But Nim is much more expressive than Python. A very nice feature of Nim is clean macros. They support regular string matching in native Perl syntax. For instance. if line =~ rx"http[s]://(.+)": var url = matches[0] ... where rx is defined as: # partial regular expressions as in Perl template rx * (arg: expr): expr = re(r".*?" & arg & ".*") Another macro instance: template repeat * (body: stmt): stmt {.immediate.} = block: while (true): body template until * (cond: expr): stmt {.immediate.} = block: if cond: break # Sample: # # var i=0 # repeat: # echo i # i += 1 # until i==7 Nice, isn't it?
ziotom78 11y ago
Congratulations to the developers for the impressive list of improvements and fixes! Nim is becoming my first choice of programming language in a large number of situations. I hope to see version 1.0 soon. Keep up the good work!
keypusher 11y ago
I notice they have now included the Aporia IDE and Nimble package manager in the Windows installer. This seems like a good step toward getting newcomers up and running quickly, and getting more feedback from the community about the core tools. It seems like many new languages are going with this route of tools supported by core-dev, such as package management. For instance Go ships its code formatting tool, which seems like a good idea. Supporting an IDE seems more questionable, for instance Python never seemed to have much success with IDLE, and IDE preference is very personal. Anyway, as someone who primarily writes Python at work I find Nim to be very usable because the syntax and style is so familiar, and I really like most of the decisions they have made. I prefer Nim's static typing and compiled executables for redistribution, and they have introduced nice new concepts around concurrency and more advanced language features. Definitely looking forward to using this language more and more as it moves toward 1.0
zimbatm 11y ago
Does Nim still allow indifferent `fooBar()` and `foo_bar()` to access the same function call ? It makes grep-powered refactoring unnecessarily hard.
- def- 11y ago
  Yes, Nim still uses partial case insensitivity: http://nim-lang.org/manual.html#identifier-equality http://nim-lang.org/manual.html#identifier-equality I agree that it's a problem with grep, there's a nimgrep tool that you could use instead, but I don't. The nice part about it is that you can use a consitent naming convention even when using external libraries. My idea to solve the problems this causes without removing it would be a gofmt like tool as described here: https://github.com/Araq/Nim/wiki/GSoC-2015-Ideas#nimfmt-automatically-format-nim-code https://github.com/Araq/Nim/wiki/GSoC-2015-Ideas#nimfmt-auto...
  - gtaylor 11y ago
    Is there any way to disable this behavior? I've been curious about Nim, but this makes me cringe pretty hard. I get the intention, but this is exactly the kind of magic that I dislike.
  - krupan 11y ago
    I haven't used go or gofmt, but I don't quite understand the appeal. gofmt doesn't go both ways, right? You can't write go in one style and then gofmt it to share, and then un-gofmt it back to your preferred style, right? Seems like it would still be easiest to just get comfortable writing and reading in the style gofmt produces. At that point, gofmt is just for catching little mistakes, which, maybe the compiler could just do for you. I see python and nim's significant whitespace as a step in that direction. Why not have the compiler/interpreter enforce a certain number of spaces for indentation? Why not enforce a certain naming style?
    - kej 11y ago
      >Seems like it would still be easiest to just get comfortable writing and reading in the style gofmt produces. That's the entire point of gofmt. Like many of Go's design choices, it's there to subtly (or not so subtly) encourage doing things in one consistent way.
wiremine 11y ago
It's a little thing, and not uncontroversial, but I'm excited to see another language besides Python adopt whitespace. In general I wish more languages provided a way to enforce code layout. After using Python professional (and managing a team of developers) for a few years, whitespace is a great way to keep things readable as more people touch code. Whitespace isn't the only way to do it, of course. Go's "gofmt" is a good example of a different way to enforce code layout. [1] [1] https://blog.golang.org/go-fmt-your-code https://blog.golang.org/go-fmt-your-code
- progman 11y ago
  I always was strictly against whitespace in Python because it can lead to all kinds of weird errors. But Nim (and also Haskell) has static types so most wrong indentations are caught by the compiler. That's really nice to have.
  - nickbauman 11y ago
    I've been a Python dev since 2008 and I can count on one finger where this has actually been an issue. I'd love have you enumerate the "all kinds of weird errors" for me. Not saying you're wrong, mind you, just want to understand.
    - muaddirac 11y ago
      I have to agree - the only whitespace-related errors I've ever come across are "IndentationErrors" - which are pretty easy to resolve.
      - mercurial 11y ago
        I remember a bug caused by that, due to a merge, where an instruction went out of an if block.
        andybak 11y ago
        I wonder if it was an automatic merge or whether someone just didn't eyeball the code properly?
copx 11y ago
> starting with version 1.0, we will not be introducing any more breaking changes to Nim. I wonder whether they will stay committed to that. Pretty much all developers of other "living" languages I know who do not have strong industry support and thus pressure not to break working code introduce breaking changes all the time e.g. see D. Nim could distinguish itself from the crowd with such a commitment to stability. However I expect overwhelming pressure from the enthusiast crowd which currently utterly dominates among Nim users to introduce breaking changes even post-1.0. And with little pressure from the other direction..
- fragsworth 11y ago
  There will be plenty of pressure in the other direction, because of the fact that they announced it. It's a selling point for the language - a green light for companies to use the language in production environments, and when they update things they don't want their existing software to break.
Cyph0n 11y ago
Congratulations to the Nim team! I did a quick comparison between the up and coming compiled languages (D, Rust, Nim, Go) and C++ a week or so back. My main aim was to assess the final statically linked binary size for a simple hello world program. Here are the results on x64 Mint: 1. C++: 1.6 MB 2. Go: 1.9 MB 3. Rust: 550 KB with dependencies (I was not able to figure out how to pass a static option to rustc) 4. D: 710 KB, same as Rust 5. Nim: 970 KB, statically linked Nim wins, by a large margin. I did not remove any of the runtime checks by the way. Removing them actually saves 100 KB+, depending on the program. Furthermore, the Nim program was actually a naive Fibonacci number calculator, not a simple hello world, meaning that Nim should have been at a disadvantage! Amazing stuff.
- kevinnk 11y ago
  For C++ most of that is iostream. $ cat hello.cpp #include <cstdio> int main(void) { puts("Hello, World!"); } $ g++ -static hello.cpp $ du -h a.out 857K a.out Compiling for size (-Os -fdata-sections -ffunction-sections hello.c -Wl,--gc-sections) gives 816K With iostream I get 1.6M
  - Cyph0n 11y ago
    Interesting point. It makes sense to use stdio.h in applications where size is the priority.
    - yoklov 11y ago
      Or where performance is a priority, in my experience. iostream is both slow and bloated. ... I don't like it's API either (it's a horrible abuse of operator<<, and is the exact kind of thing you tell people not to do with operator overloading...)
      - Cyph0n 11y ago
        Does stdio.h work well with std::string? Or do you mean dumping strings entirely and just working with char arrays?
mwcampbell 11y ago
Good to see the Nim project moving closer to a solid 1.0. Now all we need is a cross-platform GUI library that uses native widgets on each platform, such as a set of bindings for wxWidgets or (better yet) a translation of SWT from Java to Nim, and we'd have an excellent foundation for self-contained, cross-platform desktop apps. Yes, I know desktop apps aren't trendy (at least on platforms other than Mac), but they're still important.
stefantalpalaru 11y ago
> Negative indexing for slicing does not work anymore! Instead of a[0.. -1] you can use a[0.. ^1]. What's the justification for this change?
- dom96 11y ago
  The following discussion on Github may answer your question https://github.com/Araq/Nim/issues/1979 https://github.com/Araq/Nim/issues/1979
- deleted 11y ago
  [deleted]
phantom_oracle 11y ago
I really wish I had a use-case for this powerful static language, but alas I am no ninja, guru, zen-master, sensei or rocket-scientist who is working on a problem that really needs this level of power/performance. Python will always be "good enough".
- rakoo 11y ago
  Maybe you don't need performance, but you like laziness; by being compiled and statically checked, nim can catch many bugs automatically with default tools.
- federico3 11y ago
  As much as I love it, Python is far from "good enough" for writing a system library.
blt 11y ago
It's very exciting that Nim has generator syntax in a compiled, statically typed language. To me, recursive generators with "yield" and "yield from" expressions are the most natural way to express iterative algorithms. The Ranges proposal for C++17 is great for consuming generic algorithms, but it's far behind generators for creating generic algorithms. Simple example: try to write an iterator for a tree that doesn't have parent pointers. With ranges or iterators, you must maintain a stack as a data member. With recursive generators, the variables on the stack are captured implicitly in the language. I only know a little about compilers, but it seems like a compiler with syntax tree knowledge of the entire program should be able to optimize generators into machine code that's just as good as iterators - i.e. not copying all the caller-save registers onto the stack every time a generator recurses. I think generator syntax is truly a killer feature for any kind of serious algorithmic work. C++11 made it a lot easier to write and use generic algorithms, but writing iterators is still a big task that reluctant C++ programmers avoid. IMO, fear (and actual difficulty) of writing iterators is the main reason most people don't enjoy C++. If C++ had shipped with generators from the beginning, I think the programming language landscape would be very different today. Nim seems to have a small community and limited promotion, so I do not feel especially hopeful that it will compete with C++ at the same level as Rust. (I am not sure if Rust will upset C++ in any significant way either!) Perhaps a well curated set of Nim/Rust/C++ comparisons could convince the C++ standards committee or the Rust team to add generator syntax.
- kibwen 11y ago
  Indeed, ever since making the switch to external iteration, Rust has had a far-future desire for a `yield` construct to simplify the creation of iterators (inspired by C#). See https://github.com/rust-lang/rfcs/issues/388 https://github.com/rust-lang/rfcs/issues/388
bernardt32z 11y ago
Maybe off-topic, but why exactly do we have hard and soft real-time? I think this is terrible, either you have deadlines or you don't. E.g. in games which lag you are missing deadlines and the result is terrible. Currently it seems that we distinguish between hard-real-time, soft-real-time and no-real-time, but probably we should just have hard realtime everywhere and if we do not care, we just give big numbers. I mean even if you are not hard realtime you're are probably expecting results before the heat death of the universe, so maybe it would be a nice idea to NOT abstract time in programming languages but give the possibility to the programmer to annotate timing constraints in e.g. function's definitions? E.g. such information could be crucial to the GC. Maybe we could build such a mechanism into a fancy type theory?
- xiaq 11y ago
  Network service is a good example for soft real-time systems. Under high load, it is preferable to delay the responses a bit instead of starting to drop requests.
  - bernardt32z 11y ago
    Yeah, but isn't that just hard real-time with bigger deadlines?
    - xiaq 11y ago
      No. Say we choose 100ms as the (soft) deadline, since some study showed users consider a response time anywhere within 100ms to be "instant". Under light load, all requests are served within 100ms. Under heavy load, response time of some requests can exceed 100ms, but the scheduling algorithm will (likely) try to minimize the quality loss. If we increase the deadline to be 200ms, then even under light load, the response time of some requests can exceed 100ms. That's not what you want.
      - bernardt32z 11y ago
        But in a hypothetical real-time programming environment you could switch strategy at runtime (which of course limits your heuristics as it also has to be hard real-time; that is probably the hardest part). E.g. you could have different code path depending on "load" (which is probably a vague term) and switch to different GC's implementations on the fly. What I mean is, that you always have hard real-time in the end. E.g. you could make your network service with a hard real-time limit of 100ms. On light load you serve all requests as you mentioned with ease, if load gets heavier you hit an uncommon situation (by definition, otherwise you would not be satisfied with soft-realtime) and everything changes, as you hit a rare situation. You could do different things, e.g. in case of a news page just serve plain text and get rid of images and while you are doing that you also change to a different GC that only guarantees 500ms.
jlebrech 11y ago
I want to build something like meteor that leverages nim's compile to JS and C.

162 points by def- 11y ago

I hadn't seen this language before, but it looks neat. Coming from a Ruby background, it's very interesting to see Nim's pragmas and templates, as they look rather like type-checked and compiled cousins of metaprogramming methods.

hliyan 11y ago
I concur. This is the first time I'm seeing it too. I come from a C++ background, with recent experience in Python and JavaScript. I'm rarely impressed by new languages, but for some reason, Nim feels like what I wish Python was.
- progman 11y ago
  Indeed. But Nim is much more expressive than Python. A very nice feature of Nim is clean macros. They support regular string matching in native Perl syntax. For instance. if line =~ rx"http[s]://(.+)": var url = matches[0] ... where rx is defined as: # partial regular expressions as in Perl template rx * (arg: expr): expr = re(r".*?" & arg & ".*") Another macro instance: template repeat * (body: stmt): stmt {.immediate.} = block: while (true): body template until * (cond: expr): stmt {.immediate.} = block: if cond: break # Sample: # # var i=0 # repeat: # echo i # i += 1 # until i==7 Nice, isn't it?

ziotom78 11y ago

Congratulations to the developers for the impressive list of improvements and fixes! Nim is becoming my first choice of programming language in a large number of situations. I hope to see version 1.0 soon. Keep up the good work!

keypusher 11y ago

I notice they have now included the Aporia IDE and Nimble package manager in the Windows installer. This seems like a good step toward getting newcomers up and running quickly, and getting more feedback from the community about the core tools. It seems like many new languages are going with this route of tools supported by core-dev, such as package management. For instance Go ships its code formatting tool, which seems like a good idea. Supporting an IDE seems more questionable, for instance Python never seemed to have much success with IDLE, and IDE preference is very personal. Anyway, as someone who primarily writes Python at work I find Nim to be very usable because the syntax and style is so familiar, and I really like most of the decisions they have made. I prefer Nim's static typing and compiled executables for redistribution, and they have introduced nice new concepts around concurrency and more advanced language features. Definitely looking forward to using this language more and more as it moves toward 1.0

zimbatm 11y ago

Does Nim still allow indifferent `fooBar()` and `foo_bar()` to access the same function call ? It makes grep-powered refactoring unnecessarily hard.

def- 11y ago
Yes, Nim still uses partial case insensitivity: http://nim-lang.org/manual.html#identifier-equality http://nim-lang.org/manual.html#identifier-equality I agree that it's a problem with grep, there's a nimgrep tool that you could use instead, but I don't. The nice part about it is that you can use a consitent naming convention even when using external libraries. My idea to solve the problems this causes without removing it would be a gofmt like tool as described here: https://github.com/Araq/Nim/wiki/GSoC-2015-Ideas#nimfmt-automatically-format-nim-code https://github.com/Araq/Nim/wiki/GSoC-2015-Ideas#nimfmt-auto...
- gtaylor 11y ago
  Is there any way to disable this behavior? I've been curious about Nim, but this makes me cringe pretty hard. I get the intention, but this is exactly the kind of magic that I dislike.
- krupan 11y ago
  I haven't used go or gofmt, but I don't quite understand the appeal. gofmt doesn't go both ways, right? You can't write go in one style and then gofmt it to share, and then un-gofmt it back to your preferred style, right? Seems like it would still be easiest to just get comfortable writing and reading in the style gofmt produces. At that point, gofmt is just for catching little mistakes, which, maybe the compiler could just do for you. I see python and nim's significant whitespace as a step in that direction. Why not have the compiler/interpreter enforce a certain number of spaces for indentation? Why not enforce a certain naming style?
  - kej 11y ago
    >Seems like it would still be easiest to just get comfortable writing and reading in the style gofmt produces. That's the entire point of gofmt. Like many of Go's design choices, it's there to subtly (or not so subtly) encourage doing things in one consistent way.

wiremine 11y ago

It's a little thing, and not uncontroversial, but I'm excited to see another language besides Python adopt whitespace. In general I wish more languages provided a way to enforce code layout. After using Python professional (and managing a team of developers) for a few years, whitespace is a great way to keep things readable as more people touch code. Whitespace isn't the only way to do it, of course. Go's "gofmt" is a good example of a different way to enforce code layout. [1] [1] https://blog.golang.org/go-fmt-your-code https://blog.golang.org/go-fmt-your-code

progman 11y ago
I always was strictly against whitespace in Python because it can lead to all kinds of weird errors. But Nim (and also Haskell) has static types so most wrong indentations are caught by the compiler. That's really nice to have.
- nickbauman 11y ago
  I've been a Python dev since 2008 and I can count on one finger where this has actually been an issue. I'd love have you enumerate the "all kinds of weird errors" for me. Not saying you're wrong, mind you, just want to understand.
  - muaddirac 11y ago
    I have to agree - the only whitespace-related errors I've ever come across are "IndentationErrors" - which are pretty easy to resolve.
    - mercurial 11y ago
      I remember a bug caused by that, due to a merge, where an instruction went out of an if block.
      - andybak 11y ago
        I wonder if it was an automatic merge or whether someone just didn't eyeball the code properly?

copx 11y ago

> starting with version 1.0, we will not be introducing any more breaking changes to Nim. I wonder whether they will stay committed to that. Pretty much all developers of other "living" languages I know who do not have strong industry support and thus pressure not to break working code introduce breaking changes all the time e.g. see D. Nim could distinguish itself from the crowd with such a commitment to stability. However I expect overwhelming pressure from the enthusiast crowd which currently utterly dominates among Nim users to introduce breaking changes even post-1.0. And with little pressure from the other direction..

fragsworth 11y ago
There will be plenty of pressure in the other direction, because of the fact that they announced it. It's a selling point for the language - a green light for companies to use the language in production environments, and when they update things they don't want their existing software to break.

Cyph0n 11y ago

Congratulations to the Nim team! I did a quick comparison between the up and coming compiled languages (D, Rust, Nim, Go) and C++ a week or so back. My main aim was to assess the final statically linked binary size for a simple hello world program. Here are the results on x64 Mint: 1. C++: 1.6 MB 2. Go: 1.9 MB 3. Rust: 550 KB with dependencies (I was not able to figure out how to pass a static option to rustc) 4. D: 710 KB, same as Rust 5. Nim: 970 KB, statically linked Nim wins, by a large margin. I did not remove any of the runtime checks by the way. Removing them actually saves 100 KB+, depending on the program. Furthermore, the Nim program was actually a naive Fibonacci number calculator, not a simple hello world, meaning that Nim should have been at a disadvantage! Amazing stuff.

kevinnk 11y ago
For C++ most of that is iostream. $ cat hello.cpp #include <cstdio> int main(void) { puts("Hello, World!"); } $ g++ -static hello.cpp $ du -h a.out 857K a.out Compiling for size (-Os -fdata-sections -ffunction-sections hello.c -Wl,--gc-sections) gives 816K With iostream I get 1.6M
- Cyph0n 11y ago
  Interesting point. It makes sense to use stdio.h in applications where size is the priority.
  - yoklov 11y ago
    Or where performance is a priority, in my experience. iostream is both slow and bloated. ... I don't like it's API either (it's a horrible abuse of operator<<, and is the exact kind of thing you tell people not to do with operator overloading...)
    - Cyph0n 11y ago
      Does stdio.h work well with std::string? Or do you mean dumping strings entirely and just working with char arrays?

mwcampbell 11y ago

Good to see the Nim project moving closer to a solid 1.0. Now all we need is a cross-platform GUI library that uses native widgets on each platform, such as a set of bindings for wxWidgets or (better yet) a translation of SWT from Java to Nim, and we'd have an excellent foundation for self-contained, cross-platform desktop apps. Yes, I know desktop apps aren't trendy (at least on platforms other than Mac), but they're still important.

stefantalpalaru 11y ago

> Negative indexing for slicing does not work anymore! Instead of a[0.. -1] you can use a[0.. ^1]. What's the justification for this change?

dom96 11y ago
The following discussion on Github may answer your question https://github.com/Araq/Nim/issues/1979 https://github.com/Araq/Nim/issues/1979
deleted 11y ago
[deleted]

phantom_oracle 11y ago

I really wish I had a use-case for this powerful static language, but alas I am no ninja, guru, zen-master, sensei or rocket-scientist who is working on a problem that really needs this level of power/performance. Python will always be "good enough".

rakoo 11y ago
Maybe you don't need performance, but you like laziness; by being compiled and statically checked, nim can catch many bugs automatically with default tools.
federico3 11y ago
As much as I love it, Python is far from "good enough" for writing a system library.

blt 11y ago

It's very exciting that Nim has generator syntax in a compiled, statically typed language. To me, recursive generators with "yield" and "yield from" expressions are the most natural way to express iterative algorithms. The Ranges proposal for C++17 is great for consuming generic algorithms, but it's far behind generators for creating generic algorithms. Simple example: try to write an iterator for a tree that doesn't have parent pointers. With ranges or iterators, you must maintain a stack as a data member. With recursive generators, the variables on the stack are captured implicitly in the language. I only know a little about compilers, but it seems like a compiler with syntax tree knowledge of the entire program should be able to optimize generators into machine code that's just as good as iterators - i.e. not copying all the caller-save registers onto the stack every time a generator recurses. I think generator syntax is truly a killer feature for any kind of serious algorithmic work. C++11 made it a lot easier to write and use generic algorithms, but writing iterators is still a big task that reluctant C++ programmers avoid. IMO, fear (and actual difficulty) of writing iterators is the main reason most people don't enjoy C++. If C++ had shipped with generators from the beginning, I think the programming language landscape would be very different today. Nim seems to have a small community and limited promotion, so I do not feel especially hopeful that it will compete with C++ at the same level as Rust. (I am not sure if Rust will upset C++ in any significant way either!) Perhaps a well curated set of Nim/Rust/C++ comparisons could convince the C++ standards committee or the Rust team to add generator syntax.

kibwen 11y ago
Indeed, ever since making the switch to external iteration, Rust has had a far-future desire for a `yield` construct to simplify the creation of iterators (inspired by C#). See https://github.com/rust-lang/rfcs/issues/388 https://github.com/rust-lang/rfcs/issues/388

bernardt32z 11y ago

Maybe off-topic, but why exactly do we have hard and soft real-time? I think this is terrible, either you have deadlines or you don't. E.g. in games which lag you are missing deadlines and the result is terrible. Currently it seems that we distinguish between hard-real-time, soft-real-time and no-real-time, but probably we should just have hard realtime everywhere and if we do not care, we just give big numbers. I mean even if you are not hard realtime you're are probably expecting results before the heat death of the universe, so maybe it would be a nice idea to NOT abstract time in programming languages but give the possibility to the programmer to annotate timing constraints in e.g. function's definitions? E.g. such information could be crucial to the GC. Maybe we could build such a mechanism into a fancy type theory?

xiaq 11y ago
Network service is a good example for soft real-time systems. Under high load, it is preferable to delay the responses a bit instead of starting to drop requests.
- bernardt32z 11y ago
  Yeah, but isn't that just hard real-time with bigger deadlines?
  - xiaq 11y ago
    No. Say we choose 100ms as the (soft) deadline, since some study showed users consider a response time anywhere within 100ms to be "instant". Under light load, all requests are served within 100ms. Under heavy load, response time of some requests can exceed 100ms, but the scheduling algorithm will (likely) try to minimize the quality loss. If we increase the deadline to be 200ms, then even under light load, the response time of some requests can exceed 100ms. That's not what you want.
    - bernardt32z 11y ago
      But in a hypothetical real-time programming environment you could switch strategy at runtime (which of course limits your heuristics as it also has to be hard real-time; that is probably the hardest part). E.g. you could have different code path depending on "load" (which is probably a vague term) and switch to different GC's implementations on the fly. What I mean is, that you always have hard real-time in the end. E.g. you could make your network service with a hard real-time limit of 100ms. On light load you serve all requests as you mentioned with ease, if load gets heavier you hit an uncommon situation (by definition, otherwise you would not be satisfied with soft-realtime) and everything changes, as you hit a rare situation. You could do different things, e.g. in case of a news page just serve plain text and get rid of images and while you are doing that you also change to a different GC that only guarantees 500ms.

jlebrech 11y ago

I want to build something like meteor that leverages nim's compile to JS and C.