> other than very robust metaprogramming

lol then i guess zig's comptime isn't a "whiz-bang-pow killer feature" either

With hard fork do you mean the 2.x.x version?

Zig seems to be even more in flux than Nim yet people can't get enough of it.

> language like his personal compiler development playground

re personal compiler development playground: I don't see this for Nim 2. Nimony/Nim3 is more of a "playground", but rightfully so: he is creating a new major version of the language and aiming to improve the architecture of the compiler.

> He is also very difficult to work with and isn't very welcoming to newcomers

I don't have full context on the drama behind the fork, but I don't see Araq not being very "welcoming". Araq replies on the forums very consistently, replying to new-comer questions, which one might consider as "simple questions". Araq will state his personal & honest opinions, which may come off as abrasive or "un-welcoming" in your opinion. I don't agree with everything he says but that's OK.

From what I can tell the fork seems to be due to differences in direction of the language and w.r.t working together: differences in communication styles. But again, I don't know.

Personally, I see no reason to use the fork (Nimskull) over Nim, nor would I ever see any individual or company picking up Nimskull unless they were very deeply familiar with Nim (this is a small population of people). From a skim of the Nimskull repo, there is no website (there is a copy of the Nim manual), no forums (just some chatrooms), no clear documentation on the future direction, no documentation on differences for someone not familiar with Nim, etc. - why would anyone pick up Nimskull unless they knew Nim well? Please take this as constructive criticism. e.g. if any feature of the language/compiler/tooling is "better" or planned to be better: highlight it, summarize the long GitHub issue/projects discussions in a blog, etc.

> He is also very difficult to work with and isn't very welcoming to newcomers.

That's a charitable way to describe him. In our one direct interaction, he was condescending to the point of insult. (I believe he was incorrect as well, but even if he was always correct, I would consider it wrong to treat someone badly.) After browsing the Nim forum and issue tracker, I found that this was routine behavior for him.

Nim has some nice features, but I don't want to depend on anything that's subject to the whims of a personality like that, and I certainly don't want to interact with him again.

> The community "leaders" / moderation team is also full of abrasive individuals with fragile egos.

I certainly hope this isn't the case any longer. As one of the moderators I feel the current group is very patient and welcoming. At least that's what we're trying for, no one is perfect so I'm certain you can find counter examples. But as a whole I think we're doing pretty well. If you have any specific complaints we would love to hear them. They can be left anonymously in our community feedback form, or you can find we anywhere in the community for a chat.

Syntactically, like Python compares to Ruby.

One of the main differences is that Nim is not object-oriented.

What are the `@` characters for? Are they what makes it feel like Perl?

Because other than them I don’t think the equivalent Python code would look much different. Maybe more concise, e.g. you could replace the second section with something like `sorted = entries.sorted(key=lambda entry: entry.timestamp)`.

    let sorted = entries.sorted(proc (a, b: Entry): int = cmp(a.timestamp, b.timestamp))
    let sorted = entries.sorted((a, b) => cmp(a.timestamp, b.timestamp))
    let sorted = entries.sortedByIt(it.timestamp)

    proc groupIntoThreads(entries: seq[Entry], threshold: int): seq[seq[Entry]] =
      let sorted = entries.sortedByIt(it.timestamp)

      for i, entry in sorted:
        if i == 0 or entry.timestamp - sorted[i - 1].timestamp > threshold:
          result.add(@[sorted[i]])
        else:
          result[^1].add(sorted[i])

Nim is indeed a different language, which was the point of my comment, for those who got past the first sentence. However, if folks are going to tout its “python-like” syntax as a selling point, it’s not really fair to then turn around and say, “no, it’s a different language”, when a Python programmer points out that it’s not really all that python-like after all, and maybe it could be more so.

If one is going to take pains to point out that there are good reasons why it is different from Python, then we can carry that as far as we like. There’s no particular reason to use indentation to denote blocks. BEGIN and END worked just fine, after all, and would be more true to Nim’s intellectual heritage. Or maybe just END, and continue to open the block with a colon.

Thanks!

Not the OP, but as an individual who has programmed in Nim on and off for a decade, I feel qualified to answer. The similarities are definitely only skin-deep, and Nim is just as complex, if not more complex than Python.

Nim is much closer to Pascal / Modula / Oberon than Python. The whole - ease/simplicity of Python and speed of C is mostly marketing jargon that the Nim community has been using as long as I've been aware of the project.

In practice, it means that unlike most native-compiled languages, if you want a data-oriented approach without having to worry about system details at all, you can do that. Your program will still be strongly typed, but you're not obligated to worry about allocation, reference vs value semantics, ownership, or initialization details. For programs that shouldn't have to worry about those details, the Nim team has done a lot of work to make sure the language gets out of the way and lets you process data. Then, you get a fast binary comparable to the results you'd get from C++ (with a lot more effort).

In buzzword-speak, it's easy to write programs composed of nearly pure business logic while getting C++-level performance.

How do you find a simple language with abstraction? Pretty much all the "complexity" of the language is juggling its abstraction overhead. Whether that's Haskell's monad transformer stacks or Rust's Send + Sync.

Given the space it's tackling I think Nim is a great effort and refreshing as it keeps a Python like syntax with a Pascal-like feel, which I feel is an underexplored evolution of languages.

> with the syntax of Python

this library should allow that: https://github.com/hraban/metabang-bind (never tried)

with some limitations: https://github.com/nimpylib/nimpylib/tree/master/doc/mustRew... no "end" argument in print, no triple quote and newline, no "a not in b" (write not (a in b)), no variable named _ (underscore), or double underscore, no slice as foo[:b] where the left part of the slice is not specified, rewrite foo[0:b], etc.

I find that python has this simplicity other languages lack. Nim has it too. It's hard to strictly define it? Its a bit syntax, a bit lists or dicts, batteries included? A bit how you run it. Maybe a culture of straightforward code - at least in the python 2.x days. Maybe its just you write an algorithm and its easy to follow?

Nim is a complex language, but unlike C/C++/Rust, you can write useful and efficient programs without knowing much about the language.