Are there precisely 37 developers in that team??

Close to half of C++ developers in that survey regularly use something other than CMake and I've seen projects at Microsoft and Epic Games use xmake. Why are you being such a pecker?

And yet lots of people use xmake and other alternatives....

Yup, Cargo is a good baseline to compare to. I don't get the CMake arguments since:

• xmake isn't trying to replace CMake
• xmake can create CMake files from an xmake project
• xmake can consume CMake files
• xmake can use CMake packages
• you can use xmake packages in a CMake project
• a lot of people quite obviously don't like CMake

It's working with the ecosystem, not against and is good for C++ especially since people are comparing C++ building with tools like Cargo now.

Old habits die hard, that's the first alias on my list in .zshrc!

So it offers nothing over cmake...

In your opinion, I'd say the overall integration and being an actual build system are offerings for starters.

It also supports other languages like Zig, Pascal and Rust too. Here's an example of C++ calling Rust, note the easy inclusion of Cargo crates...

https://github.com/xmake-io/xmake/tree/dev/tests/projects/rust/cxx_call_rust_library

xmake is just nicer, more concise and 100% less shouty. People in general use cmake because it's the de facto standard, not because they like cmake and its DSL.

xmake can generate cmake files too so it's not going against the grain. There are plugins for popular IDEs as well.

I'll give some bullet points that might be of interest, I agree that they need a funky infographic or similar.

• 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)

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

  • the build system will default to any matching installed system libs unless you say otherwise ({ system = false} on a per-included package basis)
  • it downloads and installed necessary packages when first building a project
  • package manager can use pre-compiled Windows artefacts
  • can use the hosted online repo, or our own online or local repos (multiple if we want)
  • location of alternative repos can be set in xmake.lua file or configured on command line (or config file).

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

It just feels more straightforward and logical to me too. I know that's subjective, but the objective part of that is it's a unified build system, cache system and package manager that sets out to work with other tools.

(edited: tidied bullet lists)

Python is already popular so Mojo making that ecosystem much faster, safer and easier to deploy could be game changing when it's fully formed. There are also armies of existing Python developers out there for businesses to tap into and it's an easy language to pick up.

On their roadmap page, it looks like C++ interop is going to be a first class citizen too, further opening up the ecosystem to existing high performance libraries:

Integration to transparently import Clang C/C++ modules. Mojo’s type system and C++’s are pretty compatible, so we should be able to have something pretty nice here. Mojo can leverage Clang to transparently generate a foreign function interface between C/C++ and Mojo, with the ability to directly import functions:

from "math.h" import cos

print(cos(0))

Like how OOP was the best thing ever for everything, and just now 30 years later is proven to be actually bad.

Alan Kay coined the term 57 years ago and we have to look at the landscape back then to see just how much OOP has actually influenced pretty much all languages, including ones that distance themselves from the term now. Avoiding shared global state. Check. Encapsulating data and providing interfaces instead of always direct access. Check. Sending signals to objects/services for returned info. Check check check.

Windows shared libs could do with having an rpath equivalent for the host app. I tried to get their manifest doohickeys working for relative locations but gave up and still just splat install them in the exe directory.

Aside from that shared libraries are great. Can selectively load/reload functions from them at runtime which is a fundamental building block of a lot of applications that have things like plugin systems or wrappers for different hardware etc. Good for easier LGPL compliance as well.

Even the phrase "Russian sympathizer" is propaganda. Simple messaging sinks in.

I just have an interest in the wars around the world that the West (the UK, USA, Israel, France) are magically omnipresent in and around. With of course completely coincidental geopolitical prizes to win, as 'we' play Team NATO World Police around the world after the first rounds of our Confessions of an Economic Hitman tactics fail. The same old players pop up in every new episode of their perpetual war plan.

This is another episode. All wrapped up in a completely independent narrative with a different cartoon mad man to fight and a nice humanitarian angle so that people get all emotionally attached and don't join the dots.

If this is anyone’s propaganda it’s Ukraine’s, in which case I’m happy to participate.

Why is that? It's a blood bath and we shouldn't support any propaganda that perpetuates wars.

I would take what our jingoistic media and talking heads say with a very large pinch of salt. It's quite disrespectful to Ukrainian soldiers to say they've been facing an "antique show of an invasion", not to mention Russian engineers. Propaganda aside, both sides have fought hard in what has been a very modern war.

Every country uses a combination of older and newer equipment in any war. The war propaganda wizards just try to make things like that look unique to Russia.

Ditching libraries with very long build times unless they are absolutely essential too.

... a browser-based development experience built on Google Cloud...

Fuuuuuck thaaaat.

I'd never heard of that, thanks for the link!

brainfuck is a member of an exclusive club of languages where it's much easier to write a compiler for it than to read a program written in it.

I use Manjaro (kindof btw) with the Gnome desktop and didn't know there were that many. Not all are installed by default here anyway.

Using platform independent package managers instead of relying on system libraries seems like a more straightforward solution to a good part of the problem at least. It's often good to use multiple compilers as well, which would add to the bloat of the container. There are probably some gnarly situations where pros outweigh the cons though.