17 ms·
The success and failure of Ninja (2020)
- grobibi 2y agoI thought this was going to be about people buying less air fryers.
- airstrike 2y agoI thought of the smoothie blenders first too, but I can't see how they would ever have failed given how great they are. My life has changed since buying the first such blender about 4 months ago
- firesteelrain 2y agoOh don’t call the Ninja a blender - there is a giant thread on one of the main FB groups. OP is getting ripped
- Spivak 2y agoIs there some fun tea here? Ninja themselves describe them as blenders, has the community mythologized them into something else?
- firesteelrain 2y agoMore 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
- ultrafez 2y agoWe're conflating the Ninja Creami with Ninja's smoothie makers and blenders - they are separate product lines
- firesteelrain 2y agoOk
- Krastan 2y agoI thought this was going to be about the Fortnite streamer
- morning-coffee 2y agoI thought it was going to be about the lead singer of Die Antwoord.
- dang 2y agoDiscussed at the time: The Success and Failure of Ninja - https://news.ycombinator.com/item?id=23157783 https://news.ycombinator.com/item?id=23157783 - May 2020 (38 comments) (Reposts are fine after a year or so! links to past threads are just to satisfy extra-curious readers)
- santoshalper 2y agoMan, I was so afraid this was going to be about Fortnite. Turns out it was a fantastic read. I feel really sad but unsurprised about his description of what it's like to be an Open Source maintainer.
- willvarfar 2y ago> we talk about programming like it is about writing code, but the code ends up being less important than the architecture, and the architecture ends up being less important than social issues. A thousand times this! This puts into words something that's been lurking in the back of my mind for a very long time.
- Swizec 2y agoIn my experience roughly 80% of technical issues are because 2 people (or teams) didn’t want to just sit down together and talk it out.
- Agingcoder 2y agoYes, because ‘they’ ( the other team ) are not doing it right so not talking is best
- nuclearnice3 2y agoStrongly agree. Peopleware 1987 [1] > The first chapter of the book claims, "The major problems of our work are not so much technological as sociological in nature". The book approaches sociological or 'political' problems such as group chemistry and team jelling, "flow time" and quiet in the work environment, and the high cost of turnover [1] https://en.wikipedia.org/wiki/Peopleware:_Productive_Projects_and_Teams https://en.wikipedia.org/wiki/Peopleware:_Productive_Project...
- no_wizard 2y agoI’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 workplace, chances for advancement etc. In many respects you could apply psychology and sociology to how products should / could behave etc. as well, which I’m sure due to the monetary component some companies have taken seriously at least in some periods of their lifecycle, like Apple under Steve Jobs in his comeback
- einpoklum 2y ago### Statistics ### ninja has ~26 kloc, ~3,100 commits, and only a quarter of them by the original author (although by loc changed their weight is higher). Interesting! https://github.com/ninja-build/ninja/graphs/contributors https://github.com/ninja-build/ninja/graphs/contributors ### Bunch of other comments ### > users of ninja ... all Meson projects, which appears to increasingly be the build system used in the free software world; So, AFAICT, that hasn't turned out to be the case. > the code ends up being less important than the architecture, and the architecture ends up being less important than social issues. Well... sometimes. Other times, the fact that there's good code that does something goes a very long way, and people live with the architectural faults. And as for the social issues - they rarely stand in opposition to the code itself. > Some pieces of Ninja took struggle to get to and then are obvious in retrospect. I think this is true of much of math Yup. And the some of the rest of math becomes obvious when some re-derives it using alternative and more convenient/powerful techniques. > I think the reason so few succeed at this is that it's just too tempting to mix the layers. As an author of a library that also focuses on being a "layer" of sorts (https://github.com/eyalroz/cuda-api-wrappers/ https://github.com/eyalroz/cuda-api-wrappers/), I struggle with this temptation a lot! Especially when, like the author says, the boundaries of the layers are not as clear as one might imagine. > I strongly believe that iteration time has a huge impact on programmer satisfaction I'm pretty certain that the vast majority developers perform 10x more incremental builds than full builds. So, not just satisfaction - it's just most of what we do. It's also those builds which we wait-out rather than possible go look for some distraction: https://xkcd.com/303/ https://xkcd.com/303/ OTOH, the article doesn't mention interaction with build artifact caching schemes, which lessen the difference between building from scratch and building incrementally. > Peter Collingbourne found Ninja and did the work to plug it into the much more popular CMake ... If anyone is responsible for making Ninja succeed out there in the real world, Peter is due the credit. It is so gratifying when a person you didn't know makes your software project that much more impactful! Makes you really feel optimistic again about humanity and socialism and stuff.
- a_t48 2y agoIm going to have to give your CUDA wrapper a look later. :)
- mgaunard 2y agoI 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.
- dima55 2y agoThat's called "ccache"
- mgaunard 2y agoccache is just a hack to make traditional build systems less stupid. Good build systems have native support for these things.
- TOGoS 2y agoI think that was the idea behind NetKernel. I've built something similar, a Deno library called "TDAR"[1], and it works well, but it takes some work to wrap up all the command-line tools that expect to work in some mutable filesystem so that you can pretend you're calling pure functions. [1] I haven't got around to pulling it out of the parent project[2], but I talked about it in this youtube video: https://youtu.be/sty29o8sUKI https://youtu.be/sty29o8sUKI [2] If you're interested in this kind of thing you could poke me to open up the source for that thing. togos zero zero at gee mail dot comb
- Sesse__ 2y agoYou might be interested in n2, from the author of ninja.
- chubot 2y agoWhat’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
- 2y ago
- deleted 2y ago[deleted]
- pjmlp 2y agoGiven that ninja is required for C++20 modules when using CMake, it is going to stay around for quite a bit.
- zX41ZdbW 2y ago> Relatedly, please forgive me for the embarrassing name. The name is great! PS. It's possible to make it even faster if we implement this: https://github.com/ninja-build/ninja/issues/2157 https://github.com/ninja-build/ninja/issues/2157 But you explained in the article that the tool intentionally lacks state, even tiny hints from previous runs.
- high_priest 2y ago> 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?
- quincepie 2y agoNot 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/1OAJyfknInm https://www.computer.org/csdl/magazine/so/2023/04/10176199/1...
- marcosdumay 2y agoI 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.)
- rendaw 2y agoIt's an article about a fast build system, why wouldn't it be about build latency?
- jacobgorm 2y agoThe 400ms Doherty Treshold applies to builds too.
- edflsafoiewq 2y agoMost 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 for convenience might overall produce a more correct ecosystem than a more correct but less convenient alternative, if programmers end up avoiding the latter.
- bakudanen 2y agoThis is goldmine. This is why Pyhon, Go, and TypeScript/JavaScript is way more popular than Haskell/OCaml.
- forrestthewoods 2y agoNinja 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.
- 3836293648 2y agoIn 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
- rnewme 2y agoI 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?
- 71bw 2y agoSounds like a hardware issue, works fine on my machine. No speed issues at all.
- forrestthewoods 2y agoThe 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.
- pjmlp 2y agoThere is a community that thinks UNIX is the be all, end all of developer tools, and then they miss the trees from the forest. I know UNIX pretty well, since being introduced to Xenix in 1993, used plenty of variants, and yet my main use of WSL is to run Linux docker containers and nothing else.
- burrish 2y agoDamn and here I was expecting real Ninjas
- defer 2y agoThis 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 https://github.com/google/kati) which converts Makefiles to ninja build files (or should I say file), which really is huge: λ wc -l out/build-qssi.ninja 3035442 out/build-qssi.ninja Going from makefiles/soong to ninja is painful, it takes several minutes even in a modern machine but it simply flies once ninja picks it up.
- zelphirkalt 2y agoAs 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.
- flqn 2y agoThe Ninja files being that huge is likely more to do with the Android build environment or the tool that generates them. The main advantages of Ninja as a build executor are that the language is simple and it processes the build graph very quickly.
- defer 2y agoThey are huge because android has hundreds of smallish makefiles but the generated ninja file is a single flat file. The advantage in android is that the different build systems will generate ninja, so they can interoperate.
- bakudanen 2y agoI 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?
- emmanueloga_ 2y agoShort answer: write a ninja configuration generator instead. > ... Where other build systems are high-level languages, Ninja aims to be an assembler. > ... Ninja is intended to be used with a separate program generating its input files. > ... Ninja is pretty easy to implement for the fun 20% of it and the remaining 80% is "just" some fiddly details. There are many ninja generators out there already [1] but writing a simple, custom one shouldn't be too hard [2] and could make sense for some projects. BTW, ninja is great but I wish the configuration file had used a more standard format, easier to parse and generate from any language. JSON would have been a better option I think, given the abundance of tooling around it. -- 1: https://github.com/ninja-build/ninja/wiki/List-of-generators-producing-ninja-build-files https://github.com/ninja-build/ninja/wiki/List-of-generators... 2: https://ninja-build.org/manual.html#ref_ninja_file https://ninja-build.org/manual.html#ref_ninja_file