Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The success and failure of Ninja (2020)

neugierig.org

Post reply on HN
Print view View original

41–50 of 85 posts

Re: The success and failure of Ninja (2020)

#41

Post by mgaunard »

chubot wrote: post #29
mgaunard wrote: post #11

I switched to samurai for the few things I have that still used ninja; it's an improvement in every possible way. But regardless, I think those kinds of build systems are just wrong. What I want from a build system is to hash the content of all the transitive inputs and look up if it exists or not in a registry.

What’s better about Samurai? I thought it was a compatible subset of ninja Also, “not the thing I wanted” doesn’t mean “wrong”, simply because there are other people in the world with different preferences

One thing in particular that's always been a problem with Ninja is the output. It does too much buffering, removes colors without being able to force them back, and in general leads to an experience where for me it's not usable since I want to pipe its output to a pager. When I used ninja I needed to maintain builds with all sorts of patches to fix it. With samurai it just did the right thing out of the box.

Re: The success and failure of Ninja (2020)

#42

Post by ultrafez »

firesteelrain wrote: post #40
Spivak wrote: post #34

Earlier quoted context omitted.

Is there some fun tea here? Ninja themselves describe them as blenders, has the community mythologized them into something else?

More like an ice shaver that adds air is what the community likes to call it Because blenders don’t turn things into an ice cream texture

We're conflating the Ninja Creami with Ninja's smoothie makers and blenders - they are separate product lines

Re: The success and failure of Ninja (2020)

#43

Post by forrestthewoods »

Ninja is pretty popular with gamedevs.

I was amused by this line:

> But Windows is still a huge platform in terms of developers, and those developers are starved for tools.

As a primarily Windows dev I feel that it is poor Linux devs who are starved for tools! Living life without a good debugger (Visual Studio) or profiler (Superluminal) is so tragic. ;(

It does feel like in recent years the gap between the two platforms is increasingly minimal. I definitely like all the Rust utilities that generally work crossplatform for example.

Re: The success and failure of Ninja (2020)

#44

Post by dikei »

mgaunard wrote: post #11

I switched to samurai for the few things I have that still used ninja; it's an improvement in every possible way. But regardless, I think those kinds of build systems are just wrong. What I want from a build system is to hash the content of all the transitive inputs and look up if it exists or not in a registry.

Yes, basically any build system that supports distributed caching use digest instead of timestamp when checking modification: Bazel, Pants, Buck, etc.

They're all hugely complex though.

For local build only, I think SCons and Waf both use hash for changes detection.

Re: The success and failure of Ninja (2020)

#45

Post by bonzini »

mgaunard wrote: post #11

I switched to samurai for the few things I have that still used ninja; it's an improvement in every possible way. But regardless, I think those kinds of build systems are just wrong. What I want from a build system is to hash the content of all the transitive inputs and look up if it exists or not in a registry.

Is Samurai still alive? I have sent a pull request to improve signal handling but it has been sitting ignored for over half a year.

Re: The success and failure of Ninja (2020)

#46

Post by 3836293648 »

forrestthewoods wrote: post #43

Ninja is pretty popular with gamedevs. I was amused by this line: > But Windows is still a huge platform in terms of developers, and those developers are starved for tools. As a primarily Windows dev I feel that it is poor Linux devs who are starved for tools! Living life without a good debugger (Visual Studio) or profiler (Superluminal) is so tragic. ;( It does feel like in recent years the gap between the two platf…

In what world do you live in where the visual studio debugger in considered good? Or have they finally got around to fixing it? Last I tried it was unbearably slow, like seconds to step a single line

Re: The success and failure of Ninja (2020)

#47

Post by rnewme »

3836293648 wrote: post #46
forrestthewoods wrote: post #43

Ninja is pretty popular with gamedevs. I was amused by this line: > But Windows is still a huge platform in terms of developers, and those developers are starved for tools. As a primarily Windows dev I feel that it is poor Linux devs who are starved for tools! Living life without a good debugger (Visual Studio) or profiler (Superluminal) is so tragic. ;( It does feel like in recent years the gap between the two platf…

In what world do you live in where the visual studio debugger in considered good? Or have they finally got around to fixing it? Last I tried it was unbearably slow, like seconds to step a single line

I do admit I haven't used it for almost a decade but wasn't vs debugger (at least for cpp) considered top notch and unrivaled? What's better nowadays?

Re: The success and failure of Ninja (2020)

#48

Post by zemvpferreira »

pydry wrote: post #38
no_wizard wrote: post #15

Earlier quoted context omitted.

I’ve been drumming this for so long now, even before I heard of (let alone read) this book. I feel that the development of psychology and sociology has been lost on the workplace and it isn’t well applied. Executives want everyone to be widgets except themselves, even when study after study shows that for companies to perform optimally their workers must feel well compensated, well valued, balanced freedom in the wor…

>Executives want everyone to be widgets except themselves Of course. This maximizes their relative power within the company. Some executives are focused on the health of a company as a whole but not many. To most of them the pie can be assumed to be a fixed size and their job is to take as much of it as possible.

For businesses or business areas where excellent isn’t necessary and good will do, this attitude can even be considered to be in the best interest of the company. The more fungible employees are made, the less bargaining power they have.

Re: The success and failure of Ninja (2020)

#49

Post by firesteelrain »

ultrafez wrote: post #42
firesteelrain wrote: post #40

Earlier quoted context omitted.

More like an ice shaver that adds air is what the community likes to call it Because blenders don’t turn things into an ice cream texture

We're conflating the Ninja Creami with Ninja's smoothie makers and blenders - they are separate product lines

Ok

Re: The success and failure of Ninja (2020)

#50

Post by mgaunard »

dikei wrote: post #44
mgaunard wrote: post #11

I switched to samurai for the few things I have that still used ninja; it's an improvement in every possible way. But regardless, I think those kinds of build systems are just wrong. What I want from a build system is to hash the content of all the transitive inputs and look up if it exists or not in a registry.

Yes, basically any build system that supports distributed caching use digest instead of timestamp when checking modification: Bazel, Pants, Buck, etc. They're all hugely complex though. For local build only, I think SCons and Waf both use hash for changes detection.

Any build system is overly generic and it's up to the user to define how things should be built. So what happens is that at the end of the day every project ends up with a poorly made build system layered on top of a third-party generic tool but without abstracting away its complexity or abstractions.

My opinion is that a build system should figure out on its own how to build files, that is its job. The last thing I want to do is to define targets or dependencies. All of this is already implicit from the code itself and is useless busywork. I should just point it to a file or directory and that is it.

I prefer to just build my own build systems, bespoke to each project or environment, that just does what it should, no more and no less, leveraging the conventions in place and neatly integrating with team workflows (debugging, sanitizers, continuous integration, release, packaging, deployment, etc.)

I find that when you do that, there isn't much value in using any of the tools, they just add noise or make things slow. Running a graph of compiler and linker commands in parallel is fairly trivial and can be done in 20 lines of Python. The hard part is figuring out where the dependencies live, which versions to pick, and how the code implies those dependencies; for which the tools do nothing.

Post reply on HN