I work with lots of people who say “let’s not use ROS”. I think that’s the beginning of a conversation, and the next 7 statements should be “and instead, for {visualization / library of standard types / logging and playback / visualization / …} we should use ____”.
The robot operating systems is many things. First off, it is a “monarch” in this sense: You can't have two monarchs. ROS asserts centralized control over key aspects of a robotics project—such as file structure, build system, and runtime conventions—leaving little room for coexisting alternatives. This "monarch" model simplifies integration within its own ecosystem but comes at the cost of flexibility, interoperability, and toolchain diversity.
To get a taste of the many things, consider any programming language and recognize that it is a stand-in for many things, too.
A programming language, better understood as a programming system, comprises various components:
ROS is not a programming language. ROS is often called “middleware”.
Traditionally, “middleware” refers to the software that facilitates communication between different components, such as between a webpage and a database or among microservices. It may also involve the orchestration of these services, including process management, failure detection, and switchover mechanisms.
In the narrowest definition, middleware includes technologies like