6 ms·

> yet another slightly different take on Rust or Go From Wikipedia article of each language: Rust: First appeared July 7, 2010; 9 years ago Go: First

> yet another slightly different take on Rust or Go From Wikipedia article of each language: Rust: First appeared July 7, 2010; 9 years ago Go: First appeared November 10, 2009; 9 years ago Nim: First appeared 2008; 11 years ago

lmm 7y ago
The real question is what it offers over OCaml (1996). Nim people talk about GC being "optional" but have never been able to tell a clear story about what this does and doesn't mean (D has the same problem). Aside from that, even if the language puts everything together in a more polished package than its predecessors (and I've no idea whether Nim does or not), what's the unique selling point that would make it stand out?
- fluffything 7y ago
  Nim compiles to C, so you can use any existing C toolchain to generate a native executable for whatever platform you care about. That's a big advantage over Rust, D, OCaml, and similar languages without this feature.
  - lmm 7y ago
    I see that as a downside, personally. It makes it a lot harder to understand what guarantees there are about with a given piece of code (rather than being able to look at the assembly and the language's own compiler, you would have to also understand C's rather odd semantics and the complex behaviour of many C compilers).
    - arc776 7y ago
      This is a bit like saying you wouldn't use LLVM languages because of the semantics of IR, or that you have to understand the guarantees IR provides, isn't it? Ultimately if you're really interested in performance, regardless of the stages of compilation, the juice is the machine code output at the end. In terms of guarantees, those should be satisfied higher up in the language itself, with C generation being output according to Nim's CGen spec. The compiler is fully open source though and easy to dig into. Having said that, the CGen output is fairly readable if you're familiar with C and I must say I've investigated it when I wasn't sure how something was generated.
      - lmm 7y ago
        > This is a bit like saying you wouldn't use LLVM languages because of the semantics of IR, or that you have to understand the guarantees IR provides, isn't it? Those languages tend to be a lot simpler than C, both in terms of what constructs they offer and in terms of how simply they translate into (platform-specific) assembly language. I'm not against the idea of intermediate languages in general, but IME C is the worst of both worlds: more complicated than most high-level languages and most assembly languages. > In terms of guarantees, those should be satisfied higher up in the language itself, with C generation being output according to Nim's CGen spec. The compiler is fully open source though and easy to dig into. The problem is being confident that those guarantees are preserved all the way down. It's very hard to be confident of the properties that any given piece of C code has, because it's extremely rare for C code to be 100% standards compliant and different compilers do radically different things with the same code. And it's hard to reason about the effects of changes because C compilers are so complicated: maybe you understand the Nim compiler and can see how two similar Nim functions will generate similar C code, but that doesn't help you much when two similar C functions can be compiled to radically different assembly (which happens a lot).
        pjmlp 7y ago
        Nim is however not alone, with Haskell using C--, Eiffel using C (nowadays C++ as well) and Unity's IL2CPP/Burst.
        lmm 7y ago
        C-- is very different from C. Indeed several languages compile to C; I regard that as a downside for all those languages. I'm not sure what your point is?
        pjmlp 7y ago
        That it is a very common approach.
    - fluffything 7y ago
      I don't follow. Nim uses C as an intermediate representation, just like many languages use LLVM-IR, Gimple, javascript, etc. If you care about the assembly a piece of code generates, you can just look at that. The generated C code that Nim emits looks like what it is: boring automatically-generated C code. If you wanted to debug the compiler, you could take a look at that, but most users don't have to.
      - lmm 7y ago
        C is a very complicated language with very complex compilers. The translation from C to assembly (under modern compilers) is hard to understand, even for "boring automatically-generated C code". Languages like LLVM-IR or Gimple are designed to be simple and translate more directly into assembly. I'd have the same complaint about javascript to a certain extent, but even though it's a full programming language it's a much simpler language than C and easier to introspect at runtime.
- arc776 7y ago
  Basically you only use GC if you declare something using a GC type. type # A `ref` type is GC and will use the heap. MyGCType = ref object fieldA: int # Otherwise ALL types are stack based. MyStackType = object fieldA: int Also GC is deferred, so if you use a GC type in a local scope that doesn't escape, you don't pay for reference counting. The only other type that use GC is `seq` (equivilent to C++ vectors) IIRC. The standard library uses seqs in various places so if you fully turn the GC off using the compiler switch --gc:none you'll get warnings for things you use that will leak. There's no GC 'runtime' stuff that you need though. However in my experience all you need to do is just not use refs, and make your own ptr based seq (there's probably a library for this but its trivial to implement). Nim's GC is thread-local (so no stop-the-world issues), only triggered on allocate, and has realtime support via enforcing collection periods. Plus you can use other GCs if you wish (eg Boehm). More info about the GC here: https://nim-lang.org/docs/gc.html https://nim-lang.org/docs/gc.html
  - lmm 7y ago
    > Basically you only use GC if you declare something using a GC type. So similar to C# (2000)? A useful feature to be sure, but not a major innovation. > The standard library uses seqs in various places so if you fully turn the GC off using the compiler switch --gc:none you'll get warnings for things you use that will leak. There's no GC 'runtime' stuff that you need though. Running with the GC off (and accepting the leaks) was already a standard managed-language technique though. > Nim's GC is thread-local (so no stop-the-world issues) Well no wonder it has nice properties if it avoids all of the hard problems! What happens when you pass references between threads? > only triggered on allocate, and has realtime support via enforcing collection periods. Your link describes the realtime support as best-effort, and implies that it doesn't work for cycle collection. So honestly this doesn't seem to offer much over e.g. the tuneable GC of the JVM (which admittedly made a massive mistake in choosing defaults that prioritised batch throughput rather than latency). I do appreciate the information, and hope this isn't coming off as overly confrontational. But honestly it sounds like Nim is overselling things that are mostly within the capabilities of existing managed languages (maybe even behind them if the "GC" is only thread-local and/or not cycle-collecting).
- c-cube 7y ago
  For me it's more: what does it offer over Crystal (apart from being freshly 1.0). Crystal seems a lot nicer and a bit more, hum, uniform. Nim seems to have a lot of features to be aware of, and doesn't have type-safe nil.
  - lmm 7y ago
    Well Crystal is newer than Nim and gives me even more of a "what is the unique advantage of this language" feeling. As to the specific point, Crystal may be nil safe but union types have many of the same problems as unchecked null (particularly when used with generics). Nim has compiler-enforced not-nil types plus true sum types (and therefore an option type), which make it possible to program in a completely safe way - though I'm not sure how well the standard library supports that approach; I would certainly prefer a language that didn't have null at all, as OCaml does.
- vfclists 7y ago
  > The real question is what it offers over OCaml To you, that is
peteforde 7y ago
While I'm happy to be informed after being clearly misinformed, I promise you that I'm a full-time developer working with reasonably bleeding edge stuff and I've never heard of it before last night. I'm lucky to have folks here to set me straight. :)
setr 7y ago
It’s not actually important what came first, but rather whats currently being used/popular. Nim might have had the headstart, but its lost the race, so now it has to challenge its existence against the current popular set of languages people are looking at for transition

lmm 7y ago

The real question is what it offers over OCaml (1996). Nim people talk about GC being "optional" but have never been able to tell a clear story about what this does and doesn't mean (D has the same problem). Aside from that, even if the language puts everything together in a more polished package than its predecessors (and I've no idea whether Nim does or not), what's the unique selling point that would make it stand out?

fluffything 7y ago
Nim compiles to C, so you can use any existing C toolchain to generate a native executable for whatever platform you care about. That's a big advantage over Rust, D, OCaml, and similar languages without this feature.
- lmm 7y ago
  I see that as a downside, personally. It makes it a lot harder to understand what guarantees there are about with a given piece of code (rather than being able to look at the assembly and the language's own compiler, you would have to also understand C's rather odd semantics and the complex behaviour of many C compilers).
  - arc776 7y ago
    This is a bit like saying you wouldn't use LLVM languages because of the semantics of IR, or that you have to understand the guarantees IR provides, isn't it? Ultimately if you're really interested in performance, regardless of the stages of compilation, the juice is the machine code output at the end. In terms of guarantees, those should be satisfied higher up in the language itself, with C generation being output according to Nim's CGen spec. The compiler is fully open source though and easy to dig into. Having said that, the CGen output is fairly readable if you're familiar with C and I must say I've investigated it when I wasn't sure how something was generated.
    - lmm 7y ago
      > This is a bit like saying you wouldn't use LLVM languages because of the semantics of IR, or that you have to understand the guarantees IR provides, isn't it? Those languages tend to be a lot simpler than C, both in terms of what constructs they offer and in terms of how simply they translate into (platform-specific) assembly language. I'm not against the idea of intermediate languages in general, but IME C is the worst of both worlds: more complicated than most high-level languages and most assembly languages. > In terms of guarantees, those should be satisfied higher up in the language itself, with C generation being output according to Nim's CGen spec. The compiler is fully open source though and easy to dig into. The problem is being confident that those guarantees are preserved all the way down. It's very hard to be confident of the properties that any given piece of C code has, because it's extremely rare for C code to be 100% standards compliant and different compilers do radically different things with the same code. And it's hard to reason about the effects of changes because C compilers are so complicated: maybe you understand the Nim compiler and can see how two similar Nim functions will generate similar C code, but that doesn't help you much when two similar C functions can be compiled to radically different assembly (which happens a lot).
      - pjmlp 7y ago
        Nim is however not alone, with Haskell using C--, Eiffel using C (nowadays C++ as well) and Unity's IL2CPP/Burst.
        lmm 7y ago
        C-- is very different from C. Indeed several languages compile to C; I regard that as a downside for all those languages. I'm not sure what your point is?
        pjmlp 7y ago
        That it is a very common approach.
  - fluffything 7y ago
    I don't follow. Nim uses C as an intermediate representation, just like many languages use LLVM-IR, Gimple, javascript, etc. If you care about the assembly a piece of code generates, you can just look at that. The generated C code that Nim emits looks like what it is: boring automatically-generated C code. If you wanted to debug the compiler, you could take a look at that, but most users don't have to.
    - lmm 7y ago
      C is a very complicated language with very complex compilers. The translation from C to assembly (under modern compilers) is hard to understand, even for "boring automatically-generated C code". Languages like LLVM-IR or Gimple are designed to be simple and translate more directly into assembly. I'd have the same complaint about javascript to a certain extent, but even though it's a full programming language it's a much simpler language than C and easier to introspect at runtime.
arc776 7y ago
Basically you only use GC if you declare something using a GC type. type # A `ref` type is GC and will use the heap. MyGCType = ref object fieldA: int # Otherwise ALL types are stack based. MyStackType = object fieldA: int Also GC is deferred, so if you use a GC type in a local scope that doesn't escape, you don't pay for reference counting. The only other type that use GC is `seq` (equivilent to C++ vectors) IIRC. The standard library uses seqs in various places so if you fully turn the GC off using the compiler switch --gc:none you'll get warnings for things you use that will leak. There's no GC 'runtime' stuff that you need though. However in my experience all you need to do is just not use refs, and make your own ptr based seq (there's probably a library for this but its trivial to implement). Nim's GC is thread-local (so no stop-the-world issues), only triggered on allocate, and has realtime support via enforcing collection periods. Plus you can use other GCs if you wish (eg Boehm). More info about the GC here: https://nim-lang.org/docs/gc.html https://nim-lang.org/docs/gc.html
- lmm 7y ago
  > Basically you only use GC if you declare something using a GC type. So similar to C# (2000)? A useful feature to be sure, but not a major innovation. > The standard library uses seqs in various places so if you fully turn the GC off using the compiler switch --gc:none you'll get warnings for things you use that will leak. There's no GC 'runtime' stuff that you need though. Running with the GC off (and accepting the leaks) was already a standard managed-language technique though. > Nim's GC is thread-local (so no stop-the-world issues) Well no wonder it has nice properties if it avoids all of the hard problems! What happens when you pass references between threads? > only triggered on allocate, and has realtime support via enforcing collection periods. Your link describes the realtime support as best-effort, and implies that it doesn't work for cycle collection. So honestly this doesn't seem to offer much over e.g. the tuneable GC of the JVM (which admittedly made a massive mistake in choosing defaults that prioritised batch throughput rather than latency). I do appreciate the information, and hope this isn't coming off as overly confrontational. But honestly it sounds like Nim is overselling things that are mostly within the capabilities of existing managed languages (maybe even behind them if the "GC" is only thread-local and/or not cycle-collecting).
c-cube 7y ago
For me it's more: what does it offer over Crystal (apart from being freshly 1.0). Crystal seems a lot nicer and a bit more, hum, uniform. Nim seems to have a lot of features to be aware of, and doesn't have type-safe nil.
- lmm 7y ago
  Well Crystal is newer than Nim and gives me even more of a "what is the unique advantage of this language" feeling. As to the specific point, Crystal may be nil safe but union types have many of the same problems as unchecked null (particularly when used with generics). Nim has compiler-enforced not-nil types plus true sum types (and therefore an option type), which make it possible to program in a completely safe way - though I'm not sure how well the standard library supports that approach; I would certainly prefer a language that didn't have null at all, as OCaml does.
vfclists 7y ago
> The real question is what it offers over OCaml To you, that is

peteforde 7y ago

While I'm happy to be informed after being clearly misinformed, I promise you that I'm a full-time developer working with reasonably bleeding edge stuff and I've never heard of it before last night. I'm lucky to have folks here to set me straight. :)

setr 7y ago

It’s not actually important what came first, but rather whats currently being used/popular. Nim might have had the headstart, but its lost the race, so now it has to challenge its existence against the current popular set of languages people are looking at for transition