Soon there will be only 3 factors that we will care about: API (easy to use and integrate), behavior (does it do what I want it to do?) and testability (do I have sufficient guaranty that the code doesn't have errors).
The fact that the code was generated by a human or a machine is less and less important.
Cool to see that this project started 5 days ago!
Unfortunately, I can not make it work on my system (Ubuntu, chrome, WebGPU enabled as described in the documentation).
On the other hand, It works on my Android phone...
Funny enough, I am doing something very similar: a C++ portable (Windows, Linux MacOS) charting library, that also compile to WASM and runs in the browser...
I am still at day 2, so see you in 3 days, I guess!
I have been doing robotics for 20 years, and the "trend" to adopt a distributed architecture was already popular 15 years ago. ROS just adopted and continued that trend.
I think you are missing some important points:
- a large amount of data can be transferred asynchronously. Pub/Sub is a great pattern to achieve that; the cases when you need a synchronous interface are the minority.
- a robotic software has MANY components, you need an approach that incentivize decoupling and lousily-coupled interfaces.
- this lousily-coupled architecture has been a catalyst for innovation and cooperation, because it makes it easier for people to share their code as "building blocks" of a larger system.
Is there a considerable overhead? Sure! But it is much more complicated to write thread-safe code in a huge, monolithic application.
I worked on a robotics project with a large team using ROS1. The loose coupling is pernicious: It's easy for everyone to work on their own ROS node in isolation and avoid testing the integrated system. There's no compiler to help you find all the clients of a node, etc.
Loose coupling is good if you mainly use open-source packages and modify one component for your research paper. I'm not sure it's a net positive when building most components yourself.
A big multithreaded program can still use queues instead of locks to share data between threads.
So many of these comments sound like engineering process flaws.
Everyone's working on their own ROS nodes in isolation....with no thought to eventual integration testing? It doesn't seem like that is a fundamental shortcoming specific to ROS.
If you have experienced the power, capability, and speed of kst and then set out to build something better plotjuggler must be amazing!
I am not sure of the development status of kst these days I think it does everything’s it’s authors need it to do. Airbus may have moved on to an internal tool. The list is very quiet. So hopefully it doesn’t disappear but I will surely check out plotjuggler.
There may be a market for you to sell it to scada and HMI companies like Rockwell AVEVA Schneider etc since many of them have pretty old school built in plotting functionality
By no mean it is as nice looking as your demo, but it is interesting to ME... C++, compiled to WASM, using WebGL. Works on Firefox too. M4 decimation.
https://one-million-points-wasm.netlify.app/