Hacker News Reader

Comment by gaurav1804 | Hacker News Reader

Hi! Basically it is supposed to do what Make does... but in a faster and more user-friendly way. Note that Make doesn't have the best syntax. But Beast has sort of a 'python' syntax. It supports strings and integers. Variable modification assignment. It even supports scoping (within and outside beast build rules).

Plus, it is an order of a magnitude faster than Make. All in all, I don't agree with the fact that it's syntax is similar to Make. Well for one thing it has legible special variable names like 'out' and 'dep'.

So yes, while it is a low level build system, it is an improvement over Make in terms of syntax and speed.

View on HN

How is it faster? And faster at what?

By 'faster' I mean better build times than Make for a project of particular size. Benchmarking is going on right now, and the difference in performance is clearly visible.

Okay, but what specifically is faster?

Make is rarely a big bottleneck, except in very pathologically written projects, and when doing incremental builds. I think the main problem with big make setups is recursive make, which prevents it from having a global view on the project, and forces the main make to execute many sub-makes recursively, all of which has overhead.

The build process is faster. There are a number of algorithms running (on several threads) while building. That is where optimisation kicks in.

I suspect they are benchmarking recursive make vs recursive beast; the very first example in the readme suggests recursion

Good point. I have to say I'm wary of that, recursive make is not a good idea, and the problem can't be fixed by building a better make, because the issue is that it breaks up the dependency graph and creates build problems.

Eg, if you have src/lib, and src/bin, and the src/bin project depends on the src/lib library, then in self-contained, recursively invoked makefiles (or anything else), you won't get a correct behavior when a header in the library changes.

Other make replacements have solved this by making the dependency graph independent of the file structure. Hopefully beast does this too

What do you mean? make has no particular requirements regarding the file structure. You can write a single giant Makefile covering a directory tree with thousands of source files in various directories.

I meant independent of the (make-replacement)file structure. As long as the dependency graph isn't restricted to a single build file, then most of the inherent issues with recursive make are avoided.

Reply on news.ycombinator.com