lysdexic

lots of people use xmake

Define "lots".

Also, your weekend pet project is not the same as a corporation's cash cow.

They’re holding it wrong.

That's a naive take. These are no random autogenerated files. These are translation files. Even in the smoothest-running build systems and CICD pipelines, these can and often go wrong, because there is still an important human factor in generating translations. A regression hitting localization data means your whole system can become unusable for a whole portion of your userbase without having a good way to detect, track, and even monitor your apps.

Checking these files into the build system is the only reliable way to track changes in translation and accessibility data, and pinpoint regressions.

Source: I've worked for a company who had an internal translation service which by design required no human interaction and should only be integrated as a post-build step, and that system failed often and catastrophically. The only surefire way of tracking the mess it made was to commit those files and trwck changes per commit as part of pull requests.

xmake is just nicer, more concise and 100% less shouty.

Not really. It's yet another build system whose main aspiration is to eventually match cmake's capabilities but missing all the reasons that made cmake the de facto standard, such as the declarative straight to the point way of specifying targets.

I can also tell you without any shred of doubt, that there are many Amazon teams that absolutely hate Java

Irrelevant. What matters is what the company uses, not what some guy's personal taste.

Amazon standardizes on Java. There is no way around this fact.

It is branching away from Java, even if it still uses it primarily.

I'm sorry to tell you, but I assure you it is not. Some small subset of teams uses non-java tech stacks but that's because they have very particular requirements, such as being android apps or running on Linux devices. The bulk of the company heavily standardized on Java and has no plans to ever move away from it.

Unusually, off the top of my head, I happen to know more .NET developers working there than Java developers, and interestingly they develop one of the services on AWS.

First of all AWS is not Amazon.

Secondly, I can tell you for a fact that C# is one of the rarest tech stacks at Amazon. Even Amazon's internal build system does not support it.

I'm afraid you're talking about stuff you know close to nothing about.

it’s a build system itself, it doesn’t need make or whatever and compilation speeds are similar to ninja – which means it can do things like distributed building – and implement local caching, like ccache but supporting msvc as well as gcc/clang (actually msvc might be disabled at the moment) – … likewise remote caching, like Mozilla’s sscache for teams (again supporting msvc/gcc/clang)

So it offers nothing over cmake, and at best it matches features already offers for ages, such as transparent support for compiler cachês and distributed compilers.

it has its own package manager but also works with pretty much all other popular package managers –

That lies somewhere between matching cmake's features, and placing users in a losing proposition with its own package manager.

can configure project with a TUI menu xmake f --menu

Not only is this irrelevant but it is also something cmake provides.

Also, cmake is the de facto standard and supported natively by IDEs such as Visual Studio.

Knowing this, why would anyone bother with xmake?

I tried to see what was xmake's value proposition, but even xmake's site fails to present anything. Writing something in Lua is far from a compelling reason to switch a build system.

Why would anyone use xmake over cmake?

Well, in Rust, it’s a sum-type

The discussion is on to use monads in C++, and not on why is C++ different than Rust.

I repeat: you do not need sum types to implement a Result monad in C++.

I can tell you without any shred of doubt that Amazon still standardizes on Java-based frameworks, including Spring, and has absolutely no plans to switch. Each Amazon team is able to pick its own tech stack, but the ones that do not use Java or a JDK-based stack are extremely rare, and more than not are working on specialized applications such as mobile development.

The only reason Java is remotely tolerable today is because of influences from those ‘fad’ languages.

This might be your personal opinion but it is not a very informed one, or in touch with reality. Java frameworks such as Spring still dominate the backend ecosystem and some FANGs still standardize their backend development around it.

This is certainly a way to dismiss all other programming paradigms, I suppose.

My comment has nothing to do with paradigms.

In fact, your strawman is proven to be false by the fact that there is no mainstream tech stack for the web which is not object oriented and provides a request pipeline that uses inversion of control for developers to pass their event handlers. They all reimplement the exact same solution and follow the exact same pattern to handle requests.

WET is not what you think it is, or at least not originally. It’s not some alternative to DRY. It didn’t stand for Write Everything Twice. It stands for Write Every Time. It’s supposed to be a negative way to describe code that isn’t DRY. It’s also abbreviated as “Waste Everyone’s Time”.

I think you're confusing things. Write Everything Twice (WET) has no resemblance with the concept you mentioned, which makes no sense to be a standalone concept or even rule of thumb.

WET is a clear guideline to avoid usual code quality problems caused by premature specialization and tight coupling which result from DRY fundamentalisms. WET puts on hold the propencity to waste time with code churn. It's importance is clear to anyone who maintains software.

The misunderstanding since DRY’s coining is probably because, like natural language, we change meanings we with our environment.

Not really. Your comment sounds like a weak attempt at revisionism. Some reference books like Bob Martin's Clean Code explicitly cover DRY and the importance of refactoring away any duplicate code.

WET springs from this fundamentalist mindset. There is no two ways about it.