ROS started development almost 10 years ago. A lot of "high quality" solutions that seem like a good idea now may not have been around that long ago, or were still in nascent stage. Many of the changes in ROS2 are actually about incorporating some of these solutions -- the most obvious example being the switch to DDS for messaging.
Regarding catkin, I actually think it's an OK solution with some nice features. It's mostly a set of CMake macros that work with a certain conventional structure for packages. If you look at some other (newer) C++ package managers out there, like Hunter or FIPS, it's essentially the same idea. And catkin also supports Python code [1]. It's far from ideal, but it's a hard problem. Like many things in ROS, it's a "worse-is-better" kind of solution.
[1] Not as well as it could, re:pip integration and such; ROS2 supposedly has a better solution.
> ROS started development almost 10 years ago. A lot of "high quality" solutions that seem like a good idea now may not have been around that long ago, or were still in nascent stage.
In my opinion this is no excuse. 10 years ago was 2008 and we had rock solid solutions to these problems - I don't think it was necessary to build custom solutions (and AFAIK catkin is already the successor of rosmake).
But rereading my top-level comment it does seem a little bit harsh, so I want to apologize and hopefully do not discourage ROS developers and the community. ROS is still useful and at least there is an organized effort to make an open-source robot software abstraction layer.
Remark that the robot community (especially in an industrial setting) is plagued with closed-source proprietary software that is even worse, so despite its flaws it's a step in the right direction.
Can you detail some of the rock solid solutions in 2008 for the problems addressed? For example, building multiple C++ packages from source. Google's Bazel wasn't open sourced until 2015, so solutions were still appearing long after 2008.
Actually I don't really understand the problem, what do you mean with "C++ packages"? AFAIK C++ still has no concept of packages (although this has been proposed), so you probably mean how to build C++ based software that is located in different directories or how to do hierarchical builds in general?
That is supported by most build systems, plain old make can do it, CMake can do it, scons can do it, the list goes on and it is actually not something special in software development. It's not like we were unable to build software consisting of multiple "packages" before catkin or bazel.
I'm not saying that these existing solutions are perfect and the problem in general (dependency hell) is pretty hard to tackle. It's just that I don't see how catkin and the workspace concept help here.
Btw. did you know that catkin_make, successor of rosmake, is already old-school?
It's now "catkin build" - oh no wait, that's again uncool if you go with ROS2, there we have our meta-meta-build system "ament".
#edit: I kid you not, it's now apparently "colcon".
catkin_make and catkin-tools (where "catkin build" comes from) both use catkin. They're just different CLI tools, and for the most part compatible, and have been fairly stable for about four years now. How many build tools have come out for JS over that period?
Workspaces are actually super useful. They're a similar idea to virtualenv and conda environments. If you don't find those useful I don't know what to tell you.
Since ROS2 is essentially a fresh restart I'm not surprised there's some churn. I think most people expect it to be fairly unstable for a while.
I've been working with ROS since nearly the beginning (as well as other middleware solutions) and I definitely see a lot of its flaws, but understand the rationale for a lot of the decisions. It's like C or C++, a 'worse-is-better' solution that's overall pretty decent, specially considering it's open source.
I can appreciate that if you're writing C++ with some Python, this is probably useful. My experience with it was a project that was entirely written in Python, and suddenly having a complex, unfamiliar build system to deal with definitely felt like unnecessary complexity.
As you say, it's a hard problem. You could imagine an easier option for pure Python code, but that just moves the hurdle to the first time you want to compile something in C++.
Super useful, in fact. A lot of the code I write follows a typical pattern of bottleneck code in C++ with python wrappers, or a mixture of pure python nodes (for the things that don't have to be super fast) and pure C++ nodes. This is fairly common throughout ROS. If catkin played better with current Python packaging and virtual environment systems (virtualenv/conda) it would be so much better, though.
Regarding catkin, I actually think it's an OK solution with some nice features. It's mostly a set of CMake macros that work with a certain conventional structure for packages. If you look at some other (newer) C++ package managers out there, like Hunter or FIPS, it's essentially the same idea. And catkin also supports Python code [1]. It's far from ideal, but it's a hard problem. Like many things in ROS, it's a "worse-is-better" kind of solution.
[1] Not as well as it could, re:pip integration and such; ROS2 supposedly has a better solution.