39 ms·

> What syntax and abstractions you like are down to how you think Obviously this is not only my problem because there are only sparely applications written in

by progman 10y ago

> What syntax and abstractions you like are down to how you think Obviously this is not only my problem because there are only sparely applications written in Haskell. It is possible to write real world applications in Haskell, as proven by Leksah and the window manager xmonad. However, would you write an MS Office clone in Haskell? I wouldn't. I am still honestly interested in Haskell but I cannot understand why the cabal hell has not been fixed yet. Sandboxes and VMs are no option for me. Rust, Nim, and many other languages don't have this problem which points out that the cabal hell is due to Haskell's nature. Rust is another story. It is way more practical than Haskell, and I would use it for safety and systems programming. Nim however has become my favorite after a long journey of languages because I am really productive with it. Only Lisp has a similar productivity, and sometimes I still use it. Nim has the advantage of being very close to C which makes porting to other platforms extremely easy -- and hence also all my Nim code.

qwertyuiop924 10y ago
True enough about Haskell. As for Rust, as awkward as it can be at times, it feels more pleasant than Nim to me much of the time.
- progman 10y ago
  Rust is an awesome language. It has the power to replace C++ and Java as industry standard. However, there are three points which annoy me. First, the Rust compiler is huge (LLVM based). Second, it requires a native Rust compiler for bootstrap. Third, it doesn't compile to C which makes porting to other platforms difficult. Nim doesn't have these problems. It is small, self-hosting, and easily portable.
  - qwertyuiop924 10y ago
    That's true, but Rust and its compiler components are fairly well ported, LLVM's going to be near the top of the porting list for any new architecture, and processors are almost a monoculture at this point.
  - pcwalton 10y ago
    > Third, it doesn't compile to C which makes porting to other platforms difficult. Not compiling to C is a feature. It insulates us from the undefined behavior of C (signed overflow never results in UB in Rust, for example) and allows us to actually get proper debug info.
    - Araq 10y ago
      Compiling to C vs using LLVM is a complex design tradeoff. For example, the Posix standard specifies a C interface. Quote: "The stat structure shall contain at least the following members..." This means you can wrap 'struct stat' in Nim once and be done with it (since the mapping to C is by generating C code) whereas for eg Rust you need to wrap it once for every different OS (and potentially even for every OS version+CPU combination), since the offsets and sizes can differ. So yes, porting to other platforms really is easier when you have a C code generator.
      - steveklabnik 10y ago
        Wouldn't you just use libc directly from Rust if you wanted that? (I agree that it's a tradeoff generally, I'm just not sure this example is particularly motivating.)
        SamReidHughes 10y ago
        > Wouldn't you just use libc directly from Rust if you wanted that? No, because the interface is int stat(const char *path, struct stat *buf);
        steveklabnik 10y ago
        https://docs.rs/libc/0.2.16/libc/fn.stat.html https://docs.rs/libc/0.2.16/libc/fn.stat.html ? (Which is how stuff like https://docs.rs/libc/0.2.16/libc/fn.stat.html https://docs.rs/libc/0.2.16/libc/fn.stat.html is built)
        10y ago

by progman 10y ago

qwertyuiop924 10y ago

True enough about Haskell. As for Rust, as awkward as it can be at times, it feels more pleasant than Nim to me much of the time.

progman 10y ago
Rust is an awesome language. It has the power to replace C++ and Java as industry standard. However, there are three points which annoy me. First, the Rust compiler is huge (LLVM based). Second, it requires a native Rust compiler for bootstrap. Third, it doesn't compile to C which makes porting to other platforms difficult. Nim doesn't have these problems. It is small, self-hosting, and easily portable.
- qwertyuiop924 10y ago
  That's true, but Rust and its compiler components are fairly well ported, LLVM's going to be near the top of the porting list for any new architecture, and processors are almost a monoculture at this point.
- pcwalton 10y ago
  > Third, it doesn't compile to C which makes porting to other platforms difficult. Not compiling to C is a feature. It insulates us from the undefined behavior of C (signed overflow never results in UB in Rust, for example) and allows us to actually get proper debug info.
  - Araq 10y ago
    Compiling to C vs using LLVM is a complex design tradeoff. For example, the Posix standard specifies a C interface. Quote: "The stat structure shall contain at least the following members..." This means you can wrap 'struct stat' in Nim once and be done with it (since the mapping to C is by generating C code) whereas for eg Rust you need to wrap it once for every different OS (and potentially even for every OS version+CPU combination), since the offsets and sizes can differ. So yes, porting to other platforms really is easier when you have a C code generator.
    - steveklabnik 10y ago
      Wouldn't you just use libc directly from Rust if you wanted that? (I agree that it's a tradeoff generally, I'm just not sure this example is particularly motivating.)
      - SamReidHughes 10y ago
        > Wouldn't you just use libc directly from Rust if you wanted that? No, because the interface is int stat(const char *path, struct stat *buf);
        steveklabnik 10y ago
        https://docs.rs/libc/0.2.16/libc/fn.stat.html https://docs.rs/libc/0.2.16/libc/fn.stat.html ? (Which is how stuff like https://docs.rs/libc/0.2.16/libc/fn.stat.html https://docs.rs/libc/0.2.16/libc/fn.stat.html is built)
        10y ago