Make will check if your dependencies need to be rebuilt, and will only rebuild them if they have changed / been updated.

This is hugely valuable because you can save build times by not needlessly re-compiling the whole world. Linking times are always going to remain the same regardless, but you can definitely make the process more efficient. An example from C/C++ is not generating new object (*.o) files for source files that haven't changed (and who's dependencies haven't changed).

Make also has a pretty standardized syntax and has a bunch of open source implementations. This may not seem to matter since Python has many implementations (as an example), but remember that make is just a program, not a full platform. Python may execute differently depending on the version of Python, the version of any library you're using in the process, or even on the architecture (okay, maybe not in Python so much, but in some scripting languages it could matter). Make only depends on the version of make that you install.

Lastly, make comes with parallelism in your build mostly for free. Calling `make -j4 all` will run up to 4 rules at a time in parallel. In some cases this won't work because your dependencies are tangled in a mess and parallelism can't be guaranteed, but it's a lot easier to get parallel builds for most projects with make compared to something like Python, which either has to use something like the multiprocessing library, or pray that the GIL doesn't bite. In my opinion, this is not something you should be baking yourself into your build system. Make has done it and it has been done right for years.

Traditionally, intelligent dependency resolution with task selection based strictly on touched dependencies. When you add globbing and other expansion/interpolation features that's not trivial behavior.

But if dependency resolution is handled implicitly by Go's toolchain, then it becomes a closer race.

There are make competitors written in Python (and other good scripting languages). SCons is built in Python and its equivalent to makefiles are written in Python. Cons, from which SCons was forked/derived/something, is in Perl and Perl is its scripting language.

Plain old Python (or whatever) is missing any notion of dependencies (so you'll re-implement a topological sort in every large project), file identity (so, you're either checking timestamps or hashing them or something to know when files have changed), and probably some other stuff. You're kinda doomed to reimplement half of make poorly every time you start a new project, and you'll find out which half as your project grows.

Some of the things that "modern" build tools from a decade or two ago implement has since been implemented at the language level...so, while SCons can do things with remote dependencies, you wouldn't need/want that in a Go/Rust/JS/whatever project because they all already have their own dependency resolving package managers.

That's not to say make is ideal. But, a scripting language alone is probably less ideal.

References:

http://scons.org/

https://www.gnu.org/software/cons/

Python is a general-purpose language. Make is specifically focused on building artifacts. Python can do anything Make can do, but it's going to require more work on your part, which won't be as battle-tested as the stuff already in Make.

For example, run into a problem building an artifact with Make, and the internet is full of answers for you. Run into a problem with your own bespoke buildscript, and your troubleshooting gets harder.

I was always scared of make and it does have a learning curve, but then I spent the time to learn some basics and it's fine now - better than writing my own custom buildscripts.