6 ms·

> But why does everyone want c++? Few "want" C++, but for robotics a non garbage-collected language is necessary so latency is predictable. There are few matur

> But why does everyone want c++? Few "want" C++, but for robotics a non garbage-collected language is necessary so latency is predictable. There are few mature languages besides C/C++ in that category. Rust is an improvement, but I'm hopeful something like Julia (Julia Robotics, https://juliarobotics.org/ https://juliarobotics.org/) or Scala Native (https://scala-native.readthedocs.io/en/v0.3.9-docs/ https://scala-native.readthedocs.io/en/v0.3.9-docs/) becomes mainstream, the productivity gains would be substantial.

rozab 6y ago
For some reason Python seems to be very popular in academic robotics right now. Not a great choice
- Recurecur 6y ago
  Being a "better, stronger, faster" Python is fairly near Julia's sweet spot... :-)
- type0 6y ago
  > Not a great choice It is a great choice to prototype the ideas
WorldMaker 6y ago
Garbage-collected languages can have (and some have had) latency-predictable GCs. It's not entirely an either/or, it's something of a false dichotomy. "Non-garbage collecting" languages blur the line anyway because even basic things like reference-counting are still a garbage collection technique. The trade-offs are in how many control knobs and where those knobs are/how you turn them, and a lot of developers still seem to feel much more "comfortable" manually writing all the knobs by hand than trusting a more algorithmic GC's shiny chrome knobs on the outside of (what they presume to be) a black box. But perceived "comfort" isn't entirely reality. (The comfort of smart GC languages is immense in a different way.)
- Recurecur 6y ago
  Something of a false dichotomy - perhaps. The fact is that allocating at all during realtime operation is frowned upon. Given that the best approach is pre-allocation and then turning off the GC, why carry the overhead of the GC at all? For 99% of realtime work, the Rust or Scala Native approach is just fine. No GC required. Julia users can just use the pre-allocation approach. The important thing is avoiding language patterns that encourage needless allocation.
  - WorldMaker 6y ago
    > Given that the best approach is pre-allocation GC languages still support stack allocation, you don't have to pre-allocate anything you can stack allocate. (That's where .NET Core has been especially burning rubber in recent releases. Span<T> is a stack allocated, GC-safe "pointer", for instance, that is doing all sorts of heavy lifting in .NET Core performance-critical work these days. It's still early too, as not everything has moved to Span<T> that can move to Span<T> and family.) But also, not everything needs to be pre-allocated for the "best approach". There's some work to get used to the feel of any specific GC, but most modern "VM" GCs (.NET and today's Java, not yesterday's) are multi-generational and there's a lot you can do in strategies such as "focus on the nursery and the LOH" (using only [potentially many] small short-lived objects and a few, mostly stable "very large" objects, avoiding the intermediate generations). > why carry the overhead of the GC at all? Safety. (Why wear seatbelts?) Rust's borrow checker is great but it still requires a lot of manual adjustment and it's still possible to miss something (it's not easy, certainly, but it is possible); a GC gives you safety by default, with no manual intervention required to guarantee safety, and requires manual effort to write unsafe code. > The important thing is avoiding language patterns that encourage needless allocation. That's where we agree and why I'm very adamant that though some of the tools ("knobs") look scarily different in performance optimization for GC versus non-GC languages, the vast majority of the tools are the same: know the O(memory) of your algorithms, and make smart trade-offs regarding that O(memory), avoid allocating what you don't need, know your trade-offs between pre-allocation and allocation only when necessary, etc.
    - 6y ago
pjmlp 6y ago
PTC and Aicas sell real time Java implementations for robotics, among other similar deployment scenarios, lack of customers is something that they don't suffer from.

rozab 6y ago

For some reason Python seems to be very popular in academic robotics right now. Not a great choice

Recurecur 6y ago
Being a "better, stronger, faster" Python is fairly near Julia's sweet spot... :-)
type0 6y ago
> Not a great choice It is a great choice to prototype the ideas

WorldMaker 6y ago

Garbage-collected languages can have (and some have had) latency-predictable GCs. It's not entirely an either/or, it's something of a false dichotomy. "Non-garbage collecting" languages blur the line anyway because even basic things like reference-counting are still a garbage collection technique. The trade-offs are in how many control knobs and where those knobs are/how you turn them, and a lot of developers still seem to feel much more "comfortable" manually writing all the knobs by hand than trusting a more algorithmic GC's shiny chrome knobs on the outside of (what they presume to be) a black box. But perceived "comfort" isn't entirely reality. (The comfort of smart GC languages is immense in a different way.)

Recurecur 6y ago
Something of a false dichotomy - perhaps. The fact is that allocating at all during realtime operation is frowned upon. Given that the best approach is pre-allocation and then turning off the GC, why carry the overhead of the GC at all? For 99% of realtime work, the Rust or Scala Native approach is just fine. No GC required. Julia users can just use the pre-allocation approach. The important thing is avoiding language patterns that encourage needless allocation.
- WorldMaker 6y ago
  > Given that the best approach is pre-allocation GC languages still support stack allocation, you don't have to pre-allocate anything you can stack allocate. (That's where .NET Core has been especially burning rubber in recent releases. Span<T> is a stack allocated, GC-safe "pointer", for instance, that is doing all sorts of heavy lifting in .NET Core performance-critical work these days. It's still early too, as not everything has moved to Span<T> that can move to Span<T> and family.) But also, not everything needs to be pre-allocated for the "best approach". There's some work to get used to the feel of any specific GC, but most modern "VM" GCs (.NET and today's Java, not yesterday's) are multi-generational and there's a lot you can do in strategies such as "focus on the nursery and the LOH" (using only [potentially many] small short-lived objects and a few, mostly stable "very large" objects, avoiding the intermediate generations). > why carry the overhead of the GC at all? Safety. (Why wear seatbelts?) Rust's borrow checker is great but it still requires a lot of manual adjustment and it's still possible to miss something (it's not easy, certainly, but it is possible); a GC gives you safety by default, with no manual intervention required to guarantee safety, and requires manual effort to write unsafe code. > The important thing is avoiding language patterns that encourage needless allocation. That's where we agree and why I'm very adamant that though some of the tools ("knobs") look scarily different in performance optimization for GC versus non-GC languages, the vast majority of the tools are the same: know the O(memory) of your algorithms, and make smart trade-offs regarding that O(memory), avoid allocating what you don't need, know your trade-offs between pre-allocation and allocation only when necessary, etc.
  - 6y ago

pjmlp 6y ago

PTC and Aicas sell real time Java implementations for robotics, among other similar deployment scenarios, lack of customers is something that they don't suffer from.