Live data from Hacker News

What makes Nim practical?

hookrace.net

11–20 of 132 posts

Re: What makes Nim practical?

#11
post #9
post #5

I just realized something: Nim is like a faster Python or a better Go lang It's not really competing in quite the same space as say, D or Rust. It's like a statically typed scripting language.

Care elaborating on why is it a better Golang?

Without pointing out specifics: Nim has comparable ambitions to Go but Nim actually has escape hatches for people that desire "more."

Re: What makes Nim practical?

#12
post #6
post #5

I just realized something: Nim is like a faster Python or a better Go lang It's not really competing in quite the same space as say, D or Rust. It's like a statically typed scripting language.

Why would you say it's not competing with D and Rust? Performance-wise Nim should be in the same ball-park, and you can do systems programming in it. For me Nim is a universal language which I can use for almost anything.

Rust is where you can write code that relies on a custom allocator. Or a program that doesn't allocate memory. It's usable for the really low level stuff. Because of this everything must be explicit. Nim is implicit. It doesn't require you to declare a main() function, for example.

Re: What makes Nim practical?

#13
post #7

I read the Nim manual a while ago ( http://nim-lang.org/manual.html ), back when it was Nimrod. As a Python user, I loved it. Every single problem I had with Python, Nim seemed to have solved elegantly. Performance, distribution, typing... Everything looked perfect, and none of the Python expressiveness seemed to have been sacrificed. But it was transpiled to C, and the abstraction was leaky. Every once in a while th…

Nested functions like this?:

  proc a =
    proc b =
      proc c =
        proc d = echo "Hello World"
        d()
      c()
    b()
  a()
Works fine.

Re: What makes Nim practical?

#14
post #9
post #5

I just realized something: Nim is like a faster Python or a better Go lang It's not really competing in quite the same space as say, D or Rust. It's like a statically typed scripting language.

Care elaborating on why is it a better Golang?

Better metaprogramming, significant whitespace, generics, etc.

Re: What makes Nim practical?

#15
I tried it and it is easy and fast. But the ecosystem is still not very large. I think that it should support building libriaries directly accessible from python including passing numpy arrays directly to nim. That would make a lot of people to jump right in creating libraries and thus extending its own ecosystem.

Re: What makes Nim practical?

#16
post #13
post #7

I read the Nim manual a while ago ( http://nim-lang.org/manual.html ), back when it was Nimrod. As a Python user, I loved it. Every single problem I had with Python, Nim seemed to have solved elegantly. Performance, distribution, typing... Everything looked perfect, and none of the Python expressiveness seemed to have been sacrificed. But it was transpiled to C, and the abstraction was leaky. Every once in a while th…

Nested functions like this?: proc a = proc b = proc c = proc d = echo "Hello World" d() c() b() a() Works fine.

If (and I haven't been interested enough in Nim to investigate) it is indeed compiled to C and then compiled down to platform specific code, unless they are implementing functions differently, nested functions are not a standard part of C; they are a compiler extension (which GCC supports).

Not necessarily a problem, but unless implemented as something other than nested functions in C, there may be some portability issues. Worth investigating.

Re: What makes Nim practical?

#17
post #7

I read the Nim manual a while ago ( http://nim-lang.org/manual.html ), back when it was Nimrod. As a Python user, I loved it. Every single problem I had with Python, Nim seemed to have solved elegantly. Performance, distribution, typing... Everything looked perfect, and none of the Python expressiveness seemed to have been sacrificed. But it was transpiled to C, and the abstraction was leaky. Every once in a while th…

It doesn't make sense that a language that compiles to C can't support nested functions, just because C doesn't.

All the transpiler has to do is invent a globally unique name for each function, for instance. Of course they might not have implemented it yet, but there shouldn't be any firm reason why it can't be done.

Re: What makes Nim practical?

#18
post #13

Earlier quoted context omitted.

Nested functions like this?: proc a = proc b = proc c = proc d = echo "Hello World" d() c() b() a() Works fine.

If (and I haven't been interested enough in Nim to investigate) it is indeed compiled to C and then compiled down to platform specific code, unless they are implementing functions differently, nested functions are not a standard part of C; they are a compiler extension (which GCC supports). Not necessarily a problem, but unless implemented as something other than nested functions in C, there may be some portability i…

As unwind suggested, they just get transformed down to global functions with unique names. Here's the actual C code generated: https://gist.github.com/def-/0fe87bf1d35102c62d3b#file-nest-...

Re: What makes Nim practical?

#19
post #5

I just realized something: Nim is like a faster Python or a better Go lang It's not really competing in quite the same space as say, D or Rust. It's like a statically typed scripting language.

Comparisons to D or OCaml would be interesting (it'd be good to see that "new language for 0install" post redone with nim as one of the candidates). I think people are shoehorning Rust into the "compiled, typesafe, but strict and impure general-purpose programming language" niche, just because there aren't as many nice options there as we'd like.

Re: What makes Nim practical?

#20
post #17
post #7

I read the Nim manual a while ago ( http://nim-lang.org/manual.html ), back when it was Nimrod. As a Python user, I loved it. Every single problem I had with Python, Nim seemed to have solved elegantly. Performance, distribution, typing... Everything looked perfect, and none of the Python expressiveness seemed to have been sacrificed. But it was transpiled to C, and the abstraction was leaky. Every once in a while th…

It doesn't make sense that a language that compiles to C can't support nested functions, just because C doesn't. All the transpiler has to do is invent a globally unique name for each function, for instance. Of course they might not have implemented it yet, but there shouldn't be any firm reason why it can't be done.

> All the transpiler has to do is invent a globally unique name for each function, for instance.

I would expect nested functions to close over their context. Still implementable in C of course (or ghc -fvia-c wouldn't work), but not as trivially.

Post reply on HN