Hacker News Reader

Comment by johnisgood | Hacker News Reader

I consider Nim to be a compiled, faster Python. Nim is very easy to read and understand, and prototype in, vs. Rust.

Nim looks Pytonish (and has some Python-inspired syntax), but it is very much NOT Python.

People coming from Python that expect a "compiled, faster" Python often find a compiled, faster language but have very weird concepts expecting that language to behave like Python though it isn't.

When I started learning Nim, I did not really expect anything, but time and again I caught myself thinking, ‘This is so much like Python!’ Eventually I lost interest because I do not need a faster Python that is not Python, and I didn’t find much else to be enthusiastic about.

I've written a large-ish amount of Nim code on personal projects while using Python day to day at work, and almost every time I'm working with Nim my brain is screaming at me at how unlike Python it is.

Nim took some inspiration from Python's syntax, but the similarity is only skin deep. The construct of the language is very, very different resulting in code that usually looks and is structured differently.

IMO going into Nim thinking it will be like Python but compiled! and faster! with types! is not a good way to approach it. It is an entirely different language altogether.

I'm curious - how would you describe the qualitative differences in code structure that results?

Are there ways in which Nim nudges you to structure your code in better ways than you would in Python? Are there footguns?

Yeah, it values composition over inheritance (mentioned in the official tutorials) and discourages you from using methods and other OOP concepts. It's by far a procedural language. Functional style is also not preferred either, imho a good thing, fp does not result in fast code.

Actually it feels more like a Python flavoured Object Pascal.

I mentioned in what ways it is similar to Python, but of course it is different to it in other ways.

When I first found Nim I was looking for a faster compiled Python. I've found something that is much better: static types, less of an emphasis on OOP, static dependency-free fast binaries and macros all work together well to make Nim awesome to work with but what makes Python great is retained: speed of development, ergonomic syntax, and a small learning curve.

> very weird concepts

I'm curious, what weird concepts are you referring to?

The Nim forum has recurring questions about deserializing JSON that only make sense if you assume Nim is runtime dynamic like Python.

And many random question start with “Python let’s you..” or “shouldn’t we make this more like Python” to which Araq rather consistently (and rightly) replies “no, because this is not Python”

> The Nim forum has recurring questions about deserializing JSON that only make sense if you assume Nim is runtime dynamic like Python.

Nim is a statically typed Python, and actually the way you can deserialise JSON is very Python-like, so I'm not sure where you got this from. Here is an example:

Python:

    >>> import json
    >>> j = json.loads('{"foo": 42}')
    >>> j["foo"]
    42

Nim:

    import json
    let j = parseJson("{\"foo\": 42}")
    echo(j["foo"]) # 42

https://play.nim-lang.org/#ix=2KpU

But replace the last line with 3+j["foo"] in python (and respectively, echo (3+j["foo"]) in Nim), and the Python prints 45 whereas the Nim compiler greets you with ~40 lines of output asking you what exactly you meant.

Just to clarify: I'm not complaining. I'm happy that the compiler bugs you to do 3+int(j["foo"]) if you're going to treat it as an int. But I don't consider Nim a statically typed Python.

(Also: am a very satisfied owner of a dead-tree version of the Nim book. Thanks! Highly recommended. And dom96 is awesome in general)

Which post, the one forgetting that string literals in JSON are quoted or the other one that paid no attention on the nesting of JSON objects :P

I consider Nim to be a better Go.

Reply on news.ycombinator.com