Yeah. And it's wildly misunderstood too, so you get random people writing and running `make clean test` stuff that inherently disagrees with itself, which can do all kinds of nonsense if your system isn't normal/clean/running on Thursday.

I do still use it for simple automation, because it's nice to have a language-agnostic way to do simple things. But once it grows beyond about a page of text it tends to become a real nightmare, and is nigh impossible for most people to help maintain... which is not at all helped by its absolute lack of clear best-practices or warnings when misconfigured, and poor meshing with many common systems (like source-modifying tools, e.g. gofmt).

It doesn't help that every guide starts out with

    # so easy!
    thing:
      ./build thing

When in reality you pretty much always need at least how this page ends, to be even slightly stable and maintainable:

    # The final build step.
    $(BUILD_DIR)/$(TARGET_EXEC): $(OBJS)
      $(CXX) $(OBJS) -o $@ $(LDFLAGS)
    
    # Build step for C source
    $(BUILD_DIR)/%.c.o: %.c
      mkdir -p $(dir $@)
      $(CC) $(CPPFLAGS) $(CFLAGS) -c $< -o $@
    
    # Build step for C++ source
    $(BUILD_DIR)/%.cpp.o: %.cpp
      mkdir -p $(dir $@)
      $(CXX) $(CPPFLAGS) $(CXXFLAGS) -c $< -o $@

It's a horrifying bait-and-switch that a lot of people never fully learn their way through to the end.