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

61–70 of 85 posts

Re: The success and failure of Ninja (2020)

#61

Post by dikei »

mgaunard wrote: post #50
dikei wrote: post #44

Earlier quoted context omitted.

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…

The problem with handcrafted build system is only the author can effectively maintain it. When he moves on, someone has to spend the time ripping it out and replace with something more standard.

I've been on both end of this situation and would rather not do it again, so I'll use whatever is the de-facto standard, but you do you.

Re: The success and failure of Ninja (2020)

#62

Post by marcosdumay »

quincepie wrote: post #28
high_priest wrote: post #26

> I also believe that programmers feel latency and it affects their mood even if they don't notice it. (Google has recently done some research in this area that kinda confirmed my belief, here's hoping they'll publish it publicly!) Anyone knows if it happened? Has the google research on latency been published?

Not sure if it's the exact research that the author is referring to, but it could be this one: https://www.computer.org/csdl/magazine/so/2023/04/10176199/1...

I don't think anybody talking about "latency" without a qualifier is thinking about build latency.

But it's a nice article. The idea that giving-up on waiting for a delay has a simple exponential distribution is something that I never thought. (And now I'm fixed on understanding why... Something must have biased me against it.)

Re: The success and failure of Ninja (2020)

#63

Post by marcosdumay »

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…

Every time somebody puts "Visual Studio" on the same sentence as "good" I get that strange feeling the Universe is a simulation and other people are interacting here, but do come from a different one.

I can't make for any other explanation. I can't think on any interaction with it that I would describe as "good". I can think of a few "minimally ok", but debugging isn't one of them. (But at least on the 2022 the debugger isn't full of bugs anymore. Maybe that's what this is about.)

Re: The success and failure of Ninja (2020)

#64

Post by mgaunard »

dikei wrote: post #61
mgaunard wrote: post #50

Earlier quoted context omitted.

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…

The problem with handcrafted build system is only the author can effectively maintain it. When he moves on, someone has to spend the time ripping it out and replace with something more standard. I've been on both end of this situation and would rather not do it again, so I'll use whatever is the de-facto standard, but you do you.

Any project effectively has a handcrafted build system, whether it's built on top of CMake, Bazel, Scons or built from scratch doesn't really affect that.

And if it's doing everything from scratch, it's more likely to be simple and self-contained, making it easier to maintain.

Re: The success and failure of Ninja (2020)

#65

Post by dahart »

marcosdumay wrote: post #63
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…

Every time somebody puts "Visual Studio" on the same sentence as "good" I get that strange feeling the Universe is a simulation and other people are interacting here, but do come from a different one. I can't make for any other explanation. I can't think on any interaction with it that I would describe as "good". I can think of a few "minimally ok", but debugging isn't one of them. (But at least on the 2022 the debug…

I don’t like working in Visual Studio much, and I am a big fan of gdb too (and of Chrome’s debugger when working in JavaScript), but for C++ debugging, the Visual Studio debugger is excellent, and has been near the top of the class for a long time, compared to other debuggers. That is the explanation.

I don’t doubt there are warts, but for you what’s missing or sub-par from VS that is better elsewhere? What debuggers do you consider better? Gdb is also excellent, but in a different way. Gdb is programmable and that maybe makes it more powerful. (I don’t know if VS debugging is scriptable, I think it wasn’t last time I tried.) But gdb’s learning curve, lack of UI (even with tui), and lack of discoverability is a major impediment to it’s use. You mentioned interaction, and interaction is what holds back gdb.

Re: The success and failure of Ninja (2020)

#66

Post by forrestthewoods »

marcosdumay wrote: post #63
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…

Every time somebody puts "Visual Studio" on the same sentence as "good" I get that strange feeling the Universe is a simulation and other people are interacting here, but do come from a different one. I can't make for any other explanation. I can't think on any interaction with it that I would describe as "good". I can think of a few "minimally ok", but debugging isn't one of them. (But at least on the 2022 the debug…

Visual Studio debugger for C++ is still best in class. It’s far from perfect. But Linux doesn’t even have anything that attempts to compete. Command line GDB and LLDB are not comparable.

Re: The success and failure of Ninja (2020)

#67

Post by forrestthewoods »

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

The world where I’ve used it professionally debug C++ for almost 20 years?

It’s certainly not perfect. But “seconds to step a single line” is not normal. Certainly not what I experience. Even when debugging very large code bases like Unreal Engine.

Re: The success and failure of Ninja (2020)

#68

Post by bakudanen »

I had my stint with build systems. Nx, Bazel to name a few. In the past I was always the go to guy to configure these stuffs.

OP said that ninja is small enough to be implemented in your favorite programming language. I wonder if there is step by step tutorial to create your own build system?

Re: The success and failure of Ninja (2020)

#69

Post by bakudanen »

edflsafoiewq wrote: post #33

Most interesting point to me > You must often compromise between correctness and convenience or performance and you should be intentional when you choose a point along that continuum. I find some programmers are inflexible when considering this dynamic, where it's somehow obvious that one of those concerns dominates, but in my experience the interplay is pretty subtle; for example, a tool that trades off correctness…

This is goldmine. This is why Pyhon, Go, and TypeScript/JavaScript is way more popular than Haskell/OCaml.

Re: The success and failure of Ninja (2020)

#70

Post by zelphirkalt »

defer wrote: post #54

This is hilarious to me: Android, which uses it for some large component of the system that I've never quite understood Ninja is really a huge part of AOSP, the build system initially used makefiles. Things got complex really fast with a custom declarative build system (soong) and a failed/aborted migration to bazel. Google developed kati ( https://github.com/google/kati ) which converts Makefiles to ninja build file…

As someone, who has not used Ninja, what advantage is there, compared to Makefiles? And is it worth introducing yet another tool, to translate one to the other? Especially, when the Ninja files are that huge, possibly human-unreadable.
Post reply on HN