Hacker News Reader

Comment by mumblemumble | Hacker News Reader

At first blush, it's easy to describe Nim as C-flavored Python, but I'm not sure that quite captures it. The syntax is similar, but that's about where the similarities end - Python is deeply, fundamentally a dynamic language, and Nim one of the more firmly statically typed non-functional languages out there.

You could also describe it as being competitive with Rust, but with more compromises for the sake of developer ergonomics. Garbage collection, for example.

For my part, I'm finding it attractive as a potential Java-killer. It isn't write-once-run-everywhere, but, now that x86 and Linux have eaten the world, that's not quite such a compelling feature anymore. And Nim smooths things over a bit by making cross compiling dead easy. In return, I get better type safety, better performance, a much better C FFI, and less verbose, easier-to-understand code.

View on HN

I disagree in quite a few respects.

I think there's not much merit in discussing "C-flavored Python" as a description of nim, as that description seems just wrong.

Aside from significant whitespace, I don't find that many similarities with Python syntax.

Describing Nim as non-functional is misleading. Nim does have functional constructs and is a mixed-paradigm language involving both procedural and functional elements, just like Python.

"Firmly statically typed" is misleading. It's actually strongly-typed with great capabilities around type-inference so that, at times, you start to forget that it's typed in the first place and gives you a similar feel to a dynamically-typed language like Python.

Nim can run with garbage collection disabled. As a matter of fact, I seem to recall that the authors postulated that as a basic requirement that the language should be able to run in a low-level systems programming mode with garbage collection disabled (where it would be able to compete with Rust), and in a more high-level mode where it would rather compete on developer ergonomics/productivity.

I find Java-killer a potentially misleading analogy. I do think that it captures the kind of platform-independence that matters nowadays. And that is no longer Intel vs Sparc and Windows versus Linux, but rather the native ecosystem versus the JavaScript ecosystem.

Not agreeing or disagreeing with either of you just wanted to add some details to the garbage collector thing.

Nims GC is able to either be controlled in terms of when and how long it runs, and it can be completely disabled in favour of manual memory management. In fact people have gotten it to run on really low-powered microcontrollers like the Attiny85, as well of course as various Arduino boards. The benefit of Nim in these systems is that since it compiles and has such a rich macro system your are able to write abstractions that the compiler will turn into highly efficient code. So you can still write business logic level readable and maintainable code, while the compiler spits out super-optimised versions. This of course requires you to first write these macros, but often times a little goes a long way.

In fairness, Python is the first language the Nim team compares itself to in the first paragraph of their homepage.

Well: Nim is similar to Python in many respects, it's just not "C-flavored Python".

It has significant whitespace like Python. But since it has a lot of language constructs that are different from Python, it's a bit tedious to try to otherwise compare the syntax a great deal, and it has many elements to its syntax that are quite unique.

Saying that Nim is statically typed whereas Python is dynamically typed is exactly a feature that's a slightly unfortunate pick for trying to contrast the two, because type inference is trying to bridge the gap and give you something that's a bit in-between in terms of how it feels to the programmer.

Nim is similar to Python in that (a) It's very cleaned-up and allows you to do a lot of stuff and complex stuff with little code, without sacrificing clarity and readability. (b) It puts the programmer in a cognitive mode where he can think first and foremost about the problem at hand and not have to concentrate on the programming language so much. (c) It gently guides the programmer towards good programming practice without being patronizing. (d) It has a fast learning curve,...

Essentially all the things that make Python great are found here as well. But nim gets there on its own, not by replicating elements found in Python a lot. It's very unique in a way that makes nim a great choice of language in situations where Python isn't (like systems programming or writing code for the Browser ecosystem).

</subjective>

I'm not sure I should be getting involved, here, but I haven't had my morning tea yet, so what the hey --

It seems like you're hyper-focused on a rather skewed interpretation of my first sentence, to the point that you largely ignore the second sentence. Or at least you seem to ignore everything after the word "but", which, given what the word "but" is often used for, is a rhetorical move that has a way of enabling interpretations that tend to be close to the opposite of whatever was originally intended.

Parent poster has it right. I picked that initial comparison to Python by way of introducing one of the more popular summarizations of Nim, so that I could say why I don't think it's a good summary. If I didn't put it emphatically enough to satisfy you, I apologize. I apparently don't have anywhere near as strong of feelings on the subject; Nim's just a language I like to program in sometimes.

> In fairness, Python is the first language the Nim team compares itself to in the first paragraph of their homepage.

Probably because most people are more familiar with Python than Ada and Modula (combined) ;)

I guess it depends on your previous experience. Some people will only see Python, others might think of Nim and its syntax as "Pascal for 21st century" (fun fact: the original Nim compiler was written in Pascal).

We already got a Java-killer: Kotlin

Don't get me wrong; Kotlin is a great language and, if I have to work on the JVM, it's one of my top two picks.

But, being a JVM language, it's still stuck with all of the Java shortcomings that I had listed before: Achieving a decent level of type safety is impossible, the FFI is still a pain to use, and you've got to go through contortions to get really good numeric performance. Because all of those problems are characteristics of the JVM's run-time environment, not the language you're using to target it.

Most of those Java shortcomings are in the process of being fixed, while still enjoying one of the best language eco-systems currently available, with libraries for almost any kind of problem domain.

Kotlin is no Java killer.

The only KVM in town is Android.

Nim's syntax is very similar to Python simply because both are expressive, lean and have no braces. Naturally Python is dynamically typed and this, unfortunately, affects performance and maintainability.

Reply on news.ycombinator.com