Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Hmm, I really dislike cross-language interop so I would prefer to use Rust or Nimrod for everything. Why do you prefer Nimrod for firmware and Rust for signal processing/planning?


So basically, what I'm doing above is replacing C with nimrod, C++ with Rust, and Java with Go.

Rust has a certain amount of extra complexity needed to provide powerful zero-overhead abstractions. Those abstractions would be very useful for the signal processing and planning and those are areas that are performance critical.

But for code that isn't so performance critical that you're always thinking about where everything is in memory, you might as well just use a garbage collector and it's easier if that's built into the language. Language design involves tradeoffs between features and complexity.

And for the embedded side I don't need that much abstraction, and again I really like Nimrod's way of letting you talk about things specified at compile time.

Cross language interop really isn't a concern since these parts are all talking to each other across sockets or over USB. Team training is a concern but I'm actually the only person here who works in all three areas so it's not a huge one. Of course, the lack of Rust and Go ROS bindings is certainly a concern but we're talking about an ideal stack here. :)


Great answer, thanks. I didn't realize that robots use IPC between the planning/DSP and firmware layers. I'm also surprised that Rust doesn't have a strong ability to talk about compile time computations.


I'm looking forward to ROS2 using DDS, which will give zero copy IPC for nodes on the same computer. [1]

I wouldn't say that Rust is bad at talking about compile time versus runtime, just that Nimrod is better. This throws a compile error in Rust, for instance:

      static FOOBAR: int = if 2i > 1i { 10 } else { 20 };
But this doesn't in Nimrod:

  when 2 > 1:
    const FOOBAR = 10
  else:
    const FOOBAR = 20
And that's all because Nimrod added this 'when' keyword distinct from 'if' for stuff that gets computed at compile time. I wouldn't need something like that in a non-embedded context (I guess it's used for specializing to a given operating system by the creator?) but I'll happily use it.

[1]http://design.ros2.org/


Keep in mind that Nimrod will also try to evaluate normal code at compile-time, so the following will work fine:

    const FOOBAR = if 2 > 1: 10 else: 20


What I'd actually be doing is more like:

  when ROBOT_VER == 32:
    type TSonarAddresses = array[0..3, int]
    const sonarAddresses: TSonarAddresses = [1,2,3,4]
    ...
  elif ROBOT_VER == 33:
    ...
and stuff like that.


I see. Good, that is precisely what 'when' should be used for :)


This is called "constant folding", and every better compiler should do that.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: