9 ms·

Well this is new. I've never seen Nim before. What does it offer that Rust, Haskell, Erlang, etc... do not?

madez 11y ago
I'd say that it feels more like a scripting language in comparison to Rust and is more approachable than Haskell or Erlang while being fast since it's compiled to C.
- mreiland 11y ago
  being compiled to C doesn't imply fast :)
  - def- 11y ago
    It does have other advantages though, like inheriting C's excellent portability.
  - coldtea 11y ago
    Unless done badly, it does. Transpiling to C gives you the opportunity to emit code that is straightforward clean and fast C for most operations, which avoid an abstraction overhead.
    - jerf 11y ago
      No, it doesn't. You could easily compile Python into C (basically, "just" inline the core interpreter loop), but it will still be slow, because the Python semantics still require a lot of dictionary resolutions on every operation. Getting efficient C still requires you to think about getting efficient code. You can not get it "for free" just by waving a C compiler over your language. Otherwise, everyone would just do that and there would be no languages slower than C. Before you reply to disagree, make sure to very, very carefully think through the implications of the last sentence there. It is not as if compiling to C is particularly hard; it is literally "homework assignment for a normal college senior in a compilers course"-difficult. Many languages have gone through a phase where they compile to C. Usually they deliberately leave C at some point, another thing to carefully ponder the implications of before replying in disagreement.
      - coldtea 11y ago
        >No, it doesn't. You could easily compile Python into C (basically, "just" inline the core interpreter loop), but it will still be slow, because the Python semantics still require a lot of dictionary resolutions on every operation. Yeah, and you could do this too at the start of your emitted code from the transpiler: sleep(UINT_MAX) which would also make it slower than an interpreted language. But I specified I wasn't talking about that, or about "just inlining the core interpreter loop", but about transpiling letting you also emit straightforward and clean code without extra abstractions for most operations. A new language like Nim doesn't come with all the baggage of Python's runtime pre-existing, and doesn't need to recreate it.
        mreiland 11y ago
        HipHop doesn't support the entirety of the PHP runtime for exactly the reasons that have been laid out for you. That's reality from a company with a shitton of money and a vested interest in doing it successfully. They can't do it in the general case because reality disagrees with you.
        coldtea 11y ago
        Not sure what are you getting at. What I didn't say: transpiling is magic fairy dust for speed, and you don't have to care about language semantics at all. What I said: "unless done badly" (my words on the original comment), it's fast, as it gives you a chance to emit straightfoward C code for most operations. Now, regarding your example: First, HipHop is not transpiled to C. It's a runtime with a JIT. Second, what does "HipHop not supporting the entirety of the PHP runtime" has to do with anything? I take it you mean that the fact they had to skip some parts of the runtime for increased speed, proves something related to what I wrote. But (besides the JIT thing) PHP is not greenfield like Nim. They have a runtime, and it has to work in a certain way. PHP wasn't designed with transpiling in mind, and HipHop had to follow it closely as a design goal. I never said runtime decisions you have to mimic to be 100% compatible can't slow you down.
        11y ago
- Dewie3 11y ago
  > while being fast since it's compiled to C. Which is fast compared to what? Being compiled to JS? It's not like being compiled to a "fast language" automatically makes that compiled program fast. You also have to consider how complex the runtime is, and other variables which are probably a direct result of the semantics of the language.
def- 11y ago
Two of my old posts may answer that question: - http://hookrace.net/blog/what-is-special-about-nim/ http://hookrace.net/blog/what-is-special-about-nim/ - http://hookrace.net/blog/what-makes-nim-practical/ http://hookrace.net/blog/what-makes-nim-practical/ Summary by benhoyt: https://news.ycombinator.com/item?id=8822918 https://news.ycombinator.com/item?id=8822918 * Run regular code at compile time * Extend the language (AST templates and macros); this can be used to add a form of list comprehensions to the language! * Add your own optimizations to the compiler! * Bind (easily) to your favorite C functions and libraries * Control when and for how long the garbage collector runs * Type safe sets and arrays of enums; this was cool: "Internally the set works as an efficient bitvector." * Unified Call Syntax, so mystr.len() is equivalent to len(mystr) * Good performance -- not placing too much emphasis on this, but it's faster than C++ in his benchmark * Compile to JavaScript
- jedi_stannis 11y ago
  Thanks, that first post is really interesting. Two things stand out to me: * Run regular code at run time - does this just error if you try to use const on something that depends on a runtime value? * Add your own optimizations to the compiler - isn't this very dangerous, especially if optimizations from various sources of code get combined? Even if your optimizations are valid (which there seems to be no guarantee of), computer math is notorious for being different from real math. People unaware of the nuances of integers rolling over or floating point seem like they could easily shoot themselves in the foot here.
  - dom96 11y ago
    > * Run regular code at run time - does this just error if you try to use const on something that depends on a runtime value? Yep. For example `const foo = stdin.readLine()` would result in "Error: cannot evaluate at compile time: stdin". As for your second point. I haven't used this feature personally but I have heard that the compiler will tell you exactly where these optimisations are applied. You can also disable these optimisations very easily during compilation.
- deleted 11y ago
  [deleted]
jug 11y ago
I find the easiest way to think of Nim is "A Python-style language that compiles to C". Of course, the truth isn't as simple as that. But I like it, especially how pragmatic the language is. It doesn't try to "prove" a philosophy like Rust, but I think it gains other advantages in return.
guelo 11y ago
It's closer to Go than Rust since it is garbage collected. It's statically typed, has OO features and first-class functions. It compiles to C making it pretty portable.
- andolanra 11y ago
  You can have manual control over memory if you want, though. This worked the last time I looked at the language, at least: foo = cast[ptr Foo](alloc(sizeof(Foo))) # do stuff with foo dealloc(foo) EDIT: Here's the documentation on the site itself. Most things are 'traced' by the GC, but by using alloc and dealloc you can work with 'untraced' (i.e. manually allocated) memory: http://nim-lang.org/0.11.0/manual.html#types-reference-and-pointer-types http://nim-lang.org/0.11.0/manual.html#types-reference-and-p...
  - pcwalton 11y ago
    Go has unsafe.Pointer too.
- rdtsc 11y ago
  Has generics, meta-programming and GC can be disabled (or tuned to run up to some max # of milliseconds). So it is Go++ if you wish. But I am not sure about its concurrency. Go does have channels which are nice abstractions for doing concurrency right.
  - dom96 11y ago
    Nim has channels too (although I think they need replacing). There is also spawn which is similar to Goroutines in some ways: http://nim-lang.org/0.11.0/manual.html#parallel-spawn-spawn-statement http://nim-lang.org/0.11.0/manual.html#parallel-spawn-spawn-...

madez 11y ago

I'd say that it feels more like a scripting language in comparison to Rust and is more approachable than Haskell or Erlang while being fast since it's compiled to C.

mreiland 11y ago
being compiled to C doesn't imply fast :)
- def- 11y ago
  It does have other advantages though, like inheriting C's excellent portability.
- coldtea 11y ago
  Unless done badly, it does. Transpiling to C gives you the opportunity to emit code that is straightforward clean and fast C for most operations, which avoid an abstraction overhead.
  - jerf 11y ago
    No, it doesn't. You could easily compile Python into C (basically, "just" inline the core interpreter loop), but it will still be slow, because the Python semantics still require a lot of dictionary resolutions on every operation. Getting efficient C still requires you to think about getting efficient code. You can not get it "for free" just by waving a C compiler over your language. Otherwise, everyone would just do that and there would be no languages slower than C. Before you reply to disagree, make sure to very, very carefully think through the implications of the last sentence there. It is not as if compiling to C is particularly hard; it is literally "homework assignment for a normal college senior in a compilers course"-difficult. Many languages have gone through a phase where they compile to C. Usually they deliberately leave C at some point, another thing to carefully ponder the implications of before replying in disagreement.
    - coldtea 11y ago
      >No, it doesn't. You could easily compile Python into C (basically, "just" inline the core interpreter loop), but it will still be slow, because the Python semantics still require a lot of dictionary resolutions on every operation. Yeah, and you could do this too at the start of your emitted code from the transpiler: sleep(UINT_MAX) which would also make it slower than an interpreted language. But I specified I wasn't talking about that, or about "just inlining the core interpreter loop", but about transpiling letting you also emit straightforward and clean code without extra abstractions for most operations. A new language like Nim doesn't come with all the baggage of Python's runtime pre-existing, and doesn't need to recreate it.
      - mreiland 11y ago
        HipHop doesn't support the entirety of the PHP runtime for exactly the reasons that have been laid out for you. That's reality from a company with a shitton of money and a vested interest in doing it successfully. They can't do it in the general case because reality disagrees with you.
        coldtea 11y ago
        Not sure what are you getting at. What I didn't say: transpiling is magic fairy dust for speed, and you don't have to care about language semantics at all. What I said: "unless done badly" (my words on the original comment), it's fast, as it gives you a chance to emit straightfoward C code for most operations. Now, regarding your example: First, HipHop is not transpiled to C. It's a runtime with a JIT. Second, what does "HipHop not supporting the entirety of the PHP runtime" has to do with anything? I take it you mean that the fact they had to skip some parts of the runtime for increased speed, proves something related to what I wrote. But (besides the JIT thing) PHP is not greenfield like Nim. They have a runtime, and it has to work in a certain way. PHP wasn't designed with transpiling in mind, and HipHop had to follow it closely as a design goal. I never said runtime decisions you have to mimic to be 100% compatible can't slow you down.
        11y ago
Dewie3 11y ago
> while being fast since it's compiled to C. Which is fast compared to what? Being compiled to JS? It's not like being compiled to a "fast language" automatically makes that compiled program fast. You also have to consider how complex the runtime is, and other variables which are probably a direct result of the semantics of the language.

def- 11y ago

Two of my old posts may answer that question: - http://hookrace.net/blog/what-is-special-about-nim/ http://hookrace.net/blog/what-is-special-about-nim/ - http://hookrace.net/blog/what-makes-nim-practical/ http://hookrace.net/blog/what-makes-nim-practical/ Summary by benhoyt: https://news.ycombinator.com/item?id=8822918 https://news.ycombinator.com/item?id=8822918 * Run regular code at compile time * Extend the language (AST templates and macros); this can be used to add a form of list comprehensions to the language! * Add your own optimizations to the compiler! * Bind (easily) to your favorite C functions and libraries * Control when and for how long the garbage collector runs * Type safe sets and arrays of enums; this was cool: "Internally the set works as an efficient bitvector." * Unified Call Syntax, so mystr.len() is equivalent to len(mystr) * Good performance -- not placing too much emphasis on this, but it's faster than C++ in his benchmark * Compile to JavaScript

jedi_stannis 11y ago
Thanks, that first post is really interesting. Two things stand out to me: * Run regular code at run time - does this just error if you try to use const on something that depends on a runtime value? * Add your own optimizations to the compiler - isn't this very dangerous, especially if optimizations from various sources of code get combined? Even if your optimizations are valid (which there seems to be no guarantee of), computer math is notorious for being different from real math. People unaware of the nuances of integers rolling over or floating point seem like they could easily shoot themselves in the foot here.
- dom96 11y ago
  > * Run regular code at run time - does this just error if you try to use const on something that depends on a runtime value? Yep. For example `const foo = stdin.readLine()` would result in "Error: cannot evaluate at compile time: stdin". As for your second point. I haven't used this feature personally but I have heard that the compiler will tell you exactly where these optimisations are applied. You can also disable these optimisations very easily during compilation.
deleted 11y ago
[deleted]

jug 11y ago

I find the easiest way to think of Nim is "A Python-style language that compiles to C". Of course, the truth isn't as simple as that. But I like it, especially how pragmatic the language is. It doesn't try to "prove" a philosophy like Rust, but I think it gains other advantages in return.

guelo 11y ago

It's closer to Go than Rust since it is garbage collected. It's statically typed, has OO features and first-class functions. It compiles to C making it pretty portable.

andolanra 11y ago
You can have manual control over memory if you want, though. This worked the last time I looked at the language, at least: foo = cast[ptr Foo](alloc(sizeof(Foo))) # do stuff with foo dealloc(foo) EDIT: Here's the documentation on the site itself. Most things are 'traced' by the GC, but by using alloc and dealloc you can work with 'untraced' (i.e. manually allocated) memory: http://nim-lang.org/0.11.0/manual.html#types-reference-and-pointer-types http://nim-lang.org/0.11.0/manual.html#types-reference-and-p...
- pcwalton 11y ago
  Go has unsafe.Pointer too.
rdtsc 11y ago
Has generics, meta-programming and GC can be disabled (or tuned to run up to some max # of milliseconds). So it is Go++ if you wish. But I am not sure about its concurrency. Go does have channels which are nice abstractions for doing concurrency right.
- dom96 11y ago
  Nim has channels too (although I think they need replacing). There is also spawn which is similar to Goroutines in some ways: http://nim-lang.org/0.11.0/manual.html#parallel-spawn-spawn-statement http://nim-lang.org/0.11.0/manual.html#parallel-spawn-spawn-...