def-

Actually quite some work went into making Nim integrate better with C++ code, C++ templates especially I guess.

And there's a Nim wrapper for Urho3D:

https://github.com/3dicc/Urhonimo http://forum.nim-lang.org/t/870

You can do it a bit shorter and easier in Nim as well:

    import macros, strutils
    
    macro abcProcs(n: varargs[expr]): stmt =
      result = newStmtList()
      for c in n.children:
        result.add parseStmt("proc $1 = echo \"$1\"" % $c)
    
    abcProcs("A","B","C")
    
    proc execute(order: openarray[int], callbacks: openarray[proc]) =
      for i in order:
        callbacks[i]()
    
    execute([0,0,1,2,1,2], [A,B,C])

You can use the noSideEffect pragma for that already.

In my opinion Rust and Nim would make a nice team as complementary languages: Use Rust for everything that needs high safety and high performance at the same time, Nim for everything else.

https://andreaferretti.github.io/on-rust-and-nim/

https://arthurtw.github.io/2015/01/12/quick-comparison-nim-v...

Because of some technical reasons language renames can't be handled by Github at all currently: https://github.com/github/linguist/pull/1936

Edit: The now deleted post was asking about whether Nim code could finally be identified as "Nim" instead of "Nimrod" by Github.

And if you're into using Nim for low level programming, I got the binary from yesterday down 1 more byte and made it work on x86: http://hookrace.net/blog/nim-binary-size/#addendum

The first compilation, which is 160 KB, is totally unoptimized, contains all kinds of debugging and checks. It's just supposed to be for yourself during development of the program.

Also there is some overhead every Nim program has. But if you get to bigger programs you'll see that Nim's binary size is just fine, for example a NES emulator is just 136 KB: http://hookrace.net/blog/porting-nes-go-nim/#comparison-of-g...

You're right that most Nim users don't do it, but you should be able to use Nim for embedded environments as a replacement for C.:

- http://nim-lang.org/nimc.html#nim-for-embedded-systems

- https://github.com/sirlantis/pebble-nim

The problem is that an operation can have variable number of cycles depending on what addressing mode it uses as each opcode.

C89, so it's also compatible to Microsoft's vcc.

There are quite some compiler bugs remaining in Nim and the standard library could be improved.

I'm a big Haskell fan (it was my favorite language before discovering Nim), but here's my personal list of Nim advantages over Haskell:

    - Predictable performance (lazy evaluation is problematic)
    - Easy to achieve high performance
    - Easier to read, even for non-specialists
    - I'm much more productive in it
    - Multi-paradigm: Nim is mostly imperative, but OO and functional can be mixed as well.

http://hookrace.net/blog/conclusion-on-nim/

It does have other advantages though, like inheriting C's excellent portability.

Not all games work. Only the most popular mappers are implemented, which covers about 85% of games.

The Nim binary dynamically links against glibc and SDL2. If you really want to statically link against a C standard library, musl works just fine:

    @if musl:
      passL = "-static"
      gcc.exe = "/usr/local/musl/bin/musl-gcc"
      gcc.linkerexe = "/usr/local/musl/bin/musl-gcc"
    @end

Now it compiles like this (SDL2 is still dynamically loaded, +1 MB for that):

    $ nim -d:release -d:musl c src/nimes
    $ ls -lha src/nimes
    -rwxr-xr-x 1 def users 219K Mai  1 22:00 src/nimes*

I did it by hand, changing the code as I saw fit and learning as much about the NES as I could.

I haven't tried GopherJS, but I don't have much Go experience apart from reading it. On a related note, I read that porting the Go version to Android would be difficult and is still far in the future: https://github.com/fogleman/nes/issues/7

Two of my old posts may answer that question:

- http://hookrace.net/blog/what-is-special-about-nim/

- http://hookrace.net/blog/what-makes-nim-practical/

Summary by benhoyt: https://news.ycombinator.com/item?id=8822918

  * Run regular code at compile time
  * Extend the language (AST templates and macros);
    this can be used to add a form of list comprehensions to the language!
  * Add your own optimizations to the compiler!
  * Bind (easily) to your favorite C functions and libraries
  * Control when and for how long the garbage collector runs
  * Type safe sets and arrays of enums; this was cool:
    "Internally the set works as an efficient bitvector."
  * Unified Call Syntax, so mystr.len() is equivalent to len(mystr)
  * Good performance -- not placing too much emphasis on this,
    but it's faster than C++ in his benchmark
  * Compile to JavaScript

Yes, Nim still uses partial case insensitivity: 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-auto...

Those are full, runnable programs. Nim's boilerplate is similar to Python's here.

This uses the code snippets from http://rosettacode.org/wiki/Rosetta_Code . I wrote many of the Nim ones and collected them over at http://github.com/def-/nim-unsorted/ . But since the Rosetta Code tasks are often not 100% specified, I'm not sure how useful this comparison is. For what it's worth I mostly oriented on Python and C when writing the Nim ones. I also don't know why this comparison uses the old Nimrod name, seems to work with Nim as well: http://rosetta.alhur.es/compare/nim/go/#

Now that I think about it, I could have used implicit converters to make it look more like Python, but that would probably lead to confusion.

I have no idea, I didn't run the benchmarks. I only have a few of these languages on my system.

Yes, I updated it already.

It wasn't a direct port of the Python one. Instead I mostly followed the guide and looked at the Python code when something was unclear to me. Nim being statically typed meant I had to create many MalTypes instead of just using the built in Python ones. But nothing particularly challenging.

While unsigned arithmetic is not "enabled by-default", a simple `import unsigned` and you have it.

If you want the language to handle overflows for you, you can enable runtime overflow checks for your whole code or any specific part of it.

Otherwise, if you opt for no runtime checks and release builds with all optimizations, you indeed go into the same undefined behaviour territority as in C, so you'd have to prevent overflows before they happen.

Well, it was named "Nimrod" before, but there were other problems with that name, which prompted the rename. "Nim" was a good choice because it was the file ending already. Also, easier to google than C and Go at least. Usually "nim-lang" works fine.

Instead of ADTs there are object variants in Nim: http://nim-lang.org/manual.html#object-variants

With ADTs:

  data Shape a =
    Rectangle
      { x :: Float
      , y :: Float
      , width :: Float
      , height :: Float
      }
    | Circle
      { x :: Float
      , y :: Float
      , radius :: Float
      }

With Object Variants, note that we don't have to repeat x and y:

  type
    ShapeKind = enum Rectangle, Circle
  
    Shape = object
      x, y: float
  
      case kind: ShapeKind
      of Rectangle: width, height: float
      of Circle: radius: float

The pattern matching in Nim is quite limited. Something like this works:

  let (x, y) = getCoordinates()

But Nim doesn't have (x,y) = (y,x) for example, instead swap can be used.

You could implement your own pattern matching using metaprogramming: http://www.drdobbs.com/open-source/nimrod-a-new-systems-prog...

> Rust is more of a 'big idea' language, so it makes sense a corporation is pushing it.

Araq just announced that Nim has financial backing now: http://forum.nim-lang.org/t/870