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?
What makes Nim practical?
11–20 of 132 posts
Re: What makes Nim practical?
#12I 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.
Re: What makes Nim practical?
#13I 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…
proc a =
proc b =
proc c =
proc d = echo "Hello World"
d()
c()
b()
a()
Works fine.Re: What makes Nim practical?
#14I 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?
Re: What makes Nim practical?
#15Re: What makes Nim practical?
#16I 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.
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?
#17I 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…
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?
#18Earlier 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…
Re: What makes Nim practical?
#19I 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.
Re: What makes Nim practical?
#20I 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.
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.