7 ms·

Basically he likes the way Nim compiles to C fairly cleanly. Helps him because he knows and understands C, and reading between the lines he wants to target sys

Basically he likes the way Nim compiles to C fairly cleanly. Helps him because he knows and understands C, and reading between the lines he wants to target systems that already have C compilers, but not Rust ones. He seems to like Rust it just likes Nim better, feels currently its better suited. Actually fairly calm about it. Different people prefer different languages for a variety of reasons. Not sure compiling to C as an extra step is going to do to reliablity or performance in Nim but we'll see. Interesting times.

aidenn0 12y ago
> Not sure compiling to C as an extra step is going to do to reliablity or performance in Nim but we'll see. Interesting times. Having worked with languages that target C, machine code and C, I will make a few predictions: Compiling to C shouldn't hurt reliability anymore than compiling to LLVM. Performance will likely be somewhat less, particularly as "readable C" is the target, not arbitrary C. > Basically he likes Nim compiled to C better than just Rust. Helps him because he knows and understands C, and reading between the lines he wants to target systems that already have C compilers, but not Rust ones. Maybe someone else can confirm, but I think right now Rust can't cross-compile; I would hope that this changes after 1.0, as LLVM makes it fairly easy to do. I'm also wary of the mentioned productivity gains; I simply do not feel as confident in the correctness of Nim code I write as I do Rust code I write. This actually isn't solely due to the enforced move semantics of Rust, but due to a lot of the comments about Nim in the article linked in the issue; Nim and Rust surprise me about the same amount, but with Rust the surprise would yield (sometimes inscrutable) errors from the compiler; Nim was more likely to yield surprising runtime behavior. The two languages I use most often are C and Common Lisp. C has some surprising runtime corners, but the language (at least pre C11, which I haven't used much yet, so can't comment on) is small enough that I can keep it all in my own head. Common Lisp also has some surprising behaviors, and it's a big language, but this is mitigated by 2 things: 1) Common Lisp allows very concise code; this very often lets me keep all of the portion of the software I'm working on in my head (versus C, where I keep all the language in my head) 2) Superior tooling; SLIME lets you very quickly drill down and look at what's happening. Combined with #1 it is very fast to find where the model of the code in my head diverges from reality, so most bugs are short lived.
- def- 12y ago
  > Compiling to C shouldn't hurt reliability anymore than compiling to LLVM. Performance will likely be somewhat less, particularly as "readable C" is the target, not arbitrary C. I would say "performant C" is the target, it being rather readable is nice too, though. I have a list of some benchmarks down here: https://github.com/def-/nim-benchmarksgame#nim-implementations-for-the-computer-language-benchmarks-game https://github.com/def-/nim-benchmarksgame#nim-implementatio...
- mraison 12y ago
  > Maybe someone else can confirm, but I think right now Rust can't cross-compile; I would hope that this changes after 1.0, as LLVM makes it fairly easy to do. Rust can cross-compile, at least for a limited set of targets (see https://github.com/npryce/rusty-pi/blob/master/doc/compile-the-compiler.asciidoc https://github.com/npryce/rusty-pi/blob/master/doc/compile-t... for an example) The main pain point for the moment is that you need to build the cross-compiler yourself (which takes a while), and since the language changes every week, you have to recompile the cross-compiler every time.
  - steveklabnik 12y ago
    You can also use the 'flexible target spec' to cross-compile for anything LLVM can. It's still not super easy: you need a standard library that's been cross-compiled, IIRC. There's some small things like that, but it's mostly a polish issue.
- omaranto 12y ago
  LLVM's optimization passes are pretty awesome, but so are GCC's. My guess is that both methods can get you good performance, and that what performance you do get depends on how good the LLVM bitcode or C you generate is. I've tried using Rust and Nim for very small programs (Project Euler problems and some text munging), and currently it seems to me that (1) Nim's executables are always a little faster than Rust's (but not much), and (2) Nim compiles way faster than Rust.
  - steveklabnik 12y ago
pcwalton 12y ago
> Not sure compiling to C as an extra step is going to do to reliablity or performance in Nim but we'll see. Interesting times. At least as far as Rust is concerned, I firmly believe that compiling to LLVM IR was the right choice. When you compile to C, you're limited by what the language gives you, so you're out of luck if you want to annotate the IR with optimization info like GC metadata, precise aliasing info, or tail call annotations. Most importantly, though, in order to integrate well with debuggers like GDB and LLDB, you need exact control over the contents of the DWARF DIEs so that you can present your data structures to the user properly. LLVM IR gives you this capability, but the best you can do in C is #line.
- renox 12y ago
  Also it allowed Rust devs to define an interesting semantic for integer overflow (trap on debug, on release either trap or contain an undefined value) I don't think that they would have been able to use the 'undefined value' vs 'undefined whole program' if they had chosen to generate C.
bhouston 12y ago
I am sure most languages could be compiled to C if you wanted. C++ started that way with the at&T cfront compiler.

aidenn0 12y ago

> Not sure compiling to C as an extra step is going to do to reliablity or performance in Nim but we'll see. Interesting times. Having worked with languages that target C, machine code and C, I will make a few predictions: Compiling to C shouldn't hurt reliability anymore than compiling to LLVM. Performance will likely be somewhat less, particularly as "readable C" is the target, not arbitrary C. > Basically he likes Nim compiled to C better than just Rust. Helps him because he knows and understands C, and reading between the lines he wants to target systems that already have C compilers, but not Rust ones. Maybe someone else can confirm, but I think right now Rust can't cross-compile; I would hope that this changes after 1.0, as LLVM makes it fairly easy to do. I'm also wary of the mentioned productivity gains; I simply do not feel as confident in the correctness of Nim code I write as I do Rust code I write. This actually isn't solely due to the enforced move semantics of Rust, but due to a lot of the comments about Nim in the article linked in the issue; Nim and Rust surprise me about the same amount, but with Rust the surprise would yield (sometimes inscrutable) errors from the compiler; Nim was more likely to yield surprising runtime behavior. The two languages I use most often are C and Common Lisp. C has some surprising runtime corners, but the language (at least pre C11, which I haven't used much yet, so can't comment on) is small enough that I can keep it all in my own head. Common Lisp also has some surprising behaviors, and it's a big language, but this is mitigated by 2 things: 1) Common Lisp allows very concise code; this very often lets me keep all of the portion of the software I'm working on in my head (versus C, where I keep all the language in my head) 2) Superior tooling; SLIME lets you very quickly drill down and look at what's happening. Combined with #1 it is very fast to find where the model of the code in my head diverges from reality, so most bugs are short lived.

def- 12y ago
> Compiling to C shouldn't hurt reliability anymore than compiling to LLVM. Performance will likely be somewhat less, particularly as "readable C" is the target, not arbitrary C. I would say "performant C" is the target, it being rather readable is nice too, though. I have a list of some benchmarks down here: https://github.com/def-/nim-benchmarksgame#nim-implementations-for-the-computer-language-benchmarks-game https://github.com/def-/nim-benchmarksgame#nim-implementatio...
mraison 12y ago
> Maybe someone else can confirm, but I think right now Rust can't cross-compile; I would hope that this changes after 1.0, as LLVM makes it fairly easy to do. Rust can cross-compile, at least for a limited set of targets (see https://github.com/npryce/rusty-pi/blob/master/doc/compile-the-compiler.asciidoc https://github.com/npryce/rusty-pi/blob/master/doc/compile-t... for an example) The main pain point for the moment is that you need to build the cross-compiler yourself (which takes a while), and since the language changes every week, you have to recompile the cross-compiler every time.
- steveklabnik 12y ago
  You can also use the 'flexible target spec' to cross-compile for anything LLVM can. It's still not super easy: you need a standard library that's been cross-compiled, IIRC. There's some small things like that, but it's mostly a polish issue.
omaranto 12y ago
LLVM's optimization passes are pretty awesome, but so are GCC's. My guess is that both methods can get you good performance, and that what performance you do get depends on how good the LLVM bitcode or C you generate is. I've tried using Rust and Nim for very small programs (Project Euler problems and some text munging), and currently it seems to me that (1) Nim's executables are always a little faster than Rust's (but not much), and (2) Nim compiles way faster than Rust.
- steveklabnik 12y ago

pcwalton 12y ago

> Not sure compiling to C as an extra step is going to do to reliablity or performance in Nim but we'll see. Interesting times. At least as far as Rust is concerned, I firmly believe that compiling to LLVM IR was the right choice. When you compile to C, you're limited by what the language gives you, so you're out of luck if you want to annotate the IR with optimization info like GC metadata, precise aliasing info, or tail call annotations. Most importantly, though, in order to integrate well with debuggers like GDB and LLDB, you need exact control over the contents of the DWARF DIEs so that you can present your data structures to the user properly. LLVM IR gives you this capability, but the best you can do in C is #line.

renox 12y ago
Also it allowed Rust devs to define an interesting semantic for integer overflow (trap on debug, on release either trap or contain an undefined value) I don't think that they would have been able to use the 'undefined value' vs 'undefined whole program' if they had chosen to generate C.

bhouston 12y ago

I am sure most languages could be compiled to C if you wanted. C++ started that way with the at&T cfront compiler.