[pansa2]

> with the simplicity of Python

So, not simple at all, then? Python is a very complex language hiding behind friendly syntax.

Do you just mean “with the syntax of Python”? Or does Nim’s similarity to Python go more than skin-deep?

[tinfoilhatter]

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.

[netbioserror]

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.

[Karrot_Kream]

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.

[zozbot234]

Abstraction overhead is very much worth it for non-trivial programs. The "simpler" syntax of languages like Python is a one-time initial gain (and even then, it really only "saves" a tiny bit of boilerplate) that ultimately turns into a big drawback as programs grow more complex and your abstraction possibilities are severely limited due to an overly simplistic initial approach to the code.

[Karrot_Kream]

This sounds to me like you don't like Python's syntax and abstraction model more than anything else. Which is fine, there's plenty of languages out there.

[treeform]

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?

[Ancapistani]

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.

[xigoi]

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

[vindarel]

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