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.

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?

I've used Nim a bit, though it's been a while. I've been primarily a Python developer for the past 20 years, with a sprinkling of other languages and paradigms - including languages like Scala and Haskell, so not just OOP stuff.

I characterize Nim as Python with one major difference: where Python prioritizes "developer happiness", Nim prioritized performance. As a result, the syntax looks very similar, the edges are quite a bit rougher, and performance is exponentially better.

It still "feels like" Python in a lot of ways. The ways places if differs feel a lot like Haskell IMO.

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

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

Thanks!

> other than very robust metaprogramming

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

Syntactically, like Python compares to Ruby.

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

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

This hasn't been my experience at all.

When I first tried Nim, years ago, I came across an inconsistency in a database connector in the standard library after only a couple of weeks. I pinged him to ask if I was understanding it correctly and confirm it was a bug. He agreed it should be updated, so I put together a pull request. It was reviewed quickly, we went back and forth a couple of times over some details, he asked me to include some documentation updates, and it was merged without issue in a couple of days in total.

Given that I came to the language as a complete newcomer and had commits to the standard library less than three weeks later with the BDFL's approval, I simply can't agree that he's difficult to work with or not welcoming.

YMMV, obviously.

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

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

Unfortunately this has been my experience. Andreas was extremely abrasive towards me personally, and views he expressed to me regarding climate change were bizarre and aggressive. His behaviour led me to ditch Nim and explore Go instead, and I couldn't be happier. Sadly Nim is a permanent no-go for me.

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

If someone stumbles upon this comment, don't be quick to discard the Nim language. Please do your own research and make your own opinion on the matter.

I believe this and many of comments by tinfoilhatter under this post are not in good faith and in the most charitable interpretation written by a uninformed person or are severely outdated.

> Thanks for the offer, but there's a reason why Nim hemorrhages users as fast as it gains them, and a big reason for that, IMO, is the toxic community which definitely includes the moderation team.

I have to challenge this, because for the last couple years, there have been almost no incidents or drama. Moderation was almost exclusively dealing with spam messages. I think, on the forum, a couple posts were closed because of heated or offtopic discussions. But in all cases, participants were agreeing with the decision of mods (you can see them leaving a 'like' on mod's message).

> There was quite a bit of drama that caused the hard fork to materialize. Differences in communication styles is definitely describing the drama that unfolded, extremely mildly. I don't work on the fork or use it, but some of the more talented compiler developers who were previously contributing to Nim, left Nim to go work on Nimskull.

I know that some of people that left were also the ones causing problems with moderation and being toxic. I don't want anyone to draw strong conclusions, but Nim community was much healthier and friendly after the fork people and certain moderator leaving the project.

> He is also very difficult to work with and isn't very welcoming to newcomers. The community "leaders" / moderation team is also full of abrasive individuals with fragile egos.

This is just false. You can see Araq answering the noob questions on the forum all the time. He might be not the best person to do that, because his answers on the short side. I believe, noobs often need more context, examples and explanations than he's providing. But it's thought and effort that counts. Some people even hate when you treat them as complete beginner and try to nourture them common CS knowledge.

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

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

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.