4 ms·

But... generally, I would say all these languages can replace each other (well, ok, perhaps not C) given the right circumstances. Nim has one nice thing going f

by gokr 11y ago

But... generally, I would say all these languages can replace each other (well, ok, perhaps not C) given the right circumstances. Nim has one nice thing going for it - and that is very good C/C++ integration. Rust has it's safety focus and novel memory model. Go has simplicity and tooling, and popularity. Java has enterprise-focus. All have good performance.

bluejekyll 11y ago
Rust has extremely good FFI to C as well, if you were using that as a differentiation. No memory layout issues, etc like Go's issues. (Nothing against Nim, I haven't worked with it yet)
- biokoda 11y ago
  Rust FFI is not nearly as simple as Nim's interface to C where you pretty much just call C functions.
  - vvanders 11y ago
    That's exactly Rust's FFI.
    - deleted 11y ago
      [deleted]
    - akiselev 11y ago
      In its most basic form, yes, but because of Rust's safety guarantees it's not quite that simple. C functions can only be called from unsafe blocks and there is a lot to be desired when you have to pass strings back and forth (I don't know how well Nim handles this). It's also a bit harder to debug an FFI wrapper in Rust when you tell the compiler your code is safe but then make a mistake in how you use the unsafe C api. I strongly prefer Rust's safety but it's not quite the same as a blind FFI like Nim.
      - pcwalton 11y ago
        > It's also a bit harder to debug an FFI wrapper in Rust when you tell the compiler your code is safe but then make a mistake in how you use the unsafe C api. Can you elaborate on to how not having to type unsafe makes debugging of this easier?
- pcwalton 11y ago
  Go doesn't have memory layout issues as far as the FFI is concerned. Its memory layout is basically as defined as C's is.
  - bluejekyll 11y ago
    I thought Go had to treat compact structs from C specially. But I stand corrected.
- gokr 11y ago
  Note though that C++ is something very different. And c2nim can produce C++ wrappers, see for example Urhonimo, a Nim wrapper of Urhod3D. Of course this is a benefit from going via C/C++ offsetting the disadvantage. Btw, I am not negative towards Rust, although I prefer Nim for my use cases (but eventually I will try Rust) - I just wish people could view and critique languages from their respective design goals.

by gokr 11y ago

bluejekyll 11y ago

Rust has extremely good FFI to C as well, if you were using that as a differentiation. No memory layout issues, etc like Go's issues. (Nothing against Nim, I haven't worked with it yet)

biokoda 11y ago
Rust FFI is not nearly as simple as Nim's interface to C where you pretty much just call C functions.
- vvanders 11y ago
  That's exactly Rust's FFI.
  - deleted 11y ago
    [deleted]
  - akiselev 11y ago
    In its most basic form, yes, but because of Rust's safety guarantees it's not quite that simple. C functions can only be called from unsafe blocks and there is a lot to be desired when you have to pass strings back and forth (I don't know how well Nim handles this). It's also a bit harder to debug an FFI wrapper in Rust when you tell the compiler your code is safe but then make a mistake in how you use the unsafe C api. I strongly prefer Rust's safety but it's not quite the same as a blind FFI like Nim.
    - pcwalton 11y ago
      > It's also a bit harder to debug an FFI wrapper in Rust when you tell the compiler your code is safe but then make a mistake in how you use the unsafe C api. Can you elaborate on to how not having to type unsafe makes debugging of this easier?
pcwalton 11y ago
Go doesn't have memory layout issues as far as the FFI is concerned. Its memory layout is basically as defined as C's is.
- bluejekyll 11y ago
  I thought Go had to treat compact structs from C specially. But I stand corrected.
gokr 11y ago
Note though that C++ is something very different. And c2nim can produce C++ wrappers, see for example Urhonimo, a Nim wrapper of Urhod3D. Of course this is a benefit from going via C/C++ offsetting the disadvantage. Btw, I am not negative towards Rust, although I prefer Nim for my use cases (but eventually I will try Rust) - I just wish people could view and critique languages from their respective design goals.