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#l...

> 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.

Thank you, this is what I meant when I said similar to Python. Someone with Python familiarity should have zero issues with writing a Nim program and will mostly feel comfortable with the syntax.

I found getting F# dev environment set up on Ubuntu was super easy. That said that I found Merlin in Vim to be better than Jetbrains Rider. With Ocaml/Reason you should be able deploy via native binary. The build times and deployment story are going to be similar to Golang on the backend - if it works. With F# you have to deploy the CLR too.

Crystal is closer to C performance wise. The compiler is much slower than Go due to the aggresive type inference.

I believe this is partially due to the lack of incremental compilation, which is on the roadmap [0] for 1.0. The compiler itself builds in ~10 seconds. [1]

[0]: https://github.com/crystal-lang/crystal/wiki/Roadmap

[1]: https://crystal-lang.org/2015/12/24/the-future-of-crystal.ht...

Can't agree with that. Having used both Lua and Moonscript quite a bit I think Moonscript is what most dynamic scripting languages should be. Simple, succinct and does what you need for a scripting language.

I really enjoy using it.

Care to give an example?

The list comprehensions are really great. Most of the time when I'm writing Lua I can't be bothered to write exactly what Moonscript outputs for a list comprehension because it's noisy, but it's what I really would write if I cared about tiny amounts of performance.

Idk. Still not sold. You can do list comprehensions in regular Lua with something like this:

    function listcomp(t, f)
        local r = {}
        for k,v in pairs(t) do
            r[k] = v
        end
        return r
    end

And then, your Lua code would be like:

    listcomp({1, 2, 3, 4}, function(k, v)
        return v*2
    end)

Which would be the equivalent to this in MoonScript:

    [v*2 for k,v in pairs({1, 2, 3 ,4})]

I dunno. Just seems like a wash to me. And then you think about the extra compile step to run MoonScript, and the potential performance hits, and I'm just turned off completely from it.

There are no potential performance hits. In particular the code generated for list comprehensions would be faster than your example because there is no extra function call per item.

Over here it generated

  local b
  do
    local _accum_0 = { }
    local _len_0 = 1
    for k, v in pairs({
      1,
      2,
      3,
      4
    }) do
      _accum_0[_len_0] = v * 2
      _len_0 = _len_0 + 1
    end
    b = _accum_0
  end

It did a pretty good job. Unlike your code, it doesn't have any function calls, and unlike the code I would probably write, it doesn't use the # operator.

The difference is you or your team have the option to use the magic in moderation vs no magic at all.

I think only time can tell if that sort of argument works. Your team's habits matter, but so does the rest of the ecosystem. Strangers with libraries too central to ignore might end up forcing inscruitable templates and macros on you.

As far as I can see, the Python community has done a pretty good job of using magic sensibly. The Ruby and C++ communities, not so much.

Yes time will tell. Its basically like giving someone Jedi powers with the risk they could fall to the dark side while Golang is like Han Solo just getting things done in a much less sophisticated yet practical manner.

To be fair, "magic in moderation" is subjective. It may seem to be moderate until you have a new dev that is struggling to spin up on the codebase.

I'd lie about my age to for $510 million dollars.

could have sworn it was $580?