What you might not have known is that Actually Portable Executable https://justine.lol/ape.html and Bazel's Closure Compiler tooling were written by the same person. https://github.com/bazelbuild/rules_closure

@jart, just wanted to say thanks for both APE and cosmopolitan, those projects have made my life infinitely easier as well as giving me a lot of my time back not having to figure out windows executable minutia. It's a no brainer for me to create either a WASM module or an APE to get the job done.

And also tysm @jart for derasterize https://github.com/csdvrx/derasterize, which was a great basis to work on, and helped me make sixel-tmux https://github.com/csdvrx/sixel-tmux

We achieved textmode supremacy, and jart achieved binary-portability supremacy.

There seems to be a pattern here :)

> I am always surprised how good and not-well-known google’s tooling is.

The problem is that Google is well-known for unceremoniously dumping stuff.

So my first question about any Google tool is: "Does it have enough non-Google people supporting it?" because, if it doesn't, it will die as soon as it becomes a political football.

My second question about any Google tool is: "Are there small projects using it and singing its praises?" Can I use the tool to do what I need to a handful of files after reading a couple of web pages for 15 minutes and have it work. I don't need to scale to 4 gazillion foobars--I do need to get stuff done without an IT staff of 100 people. From a cursory look, Bazel fails that question.

My final question about any tool is more personal: "Does it use C++?" because, if it does, then integrating with anything other than C++ is going to be a gigantic PITA. At this point there are plenty of fine alternatives to C++ that don't suck. If you don't have a clean, pleasant way of talking to things that only understand C library conventions, you fail and I'm moving on.

> My final question about any tool is more personal: "Does it use C++?" because, if it does, then integrating with anything other than C++ is going to be a gigantic PITA. At this point there are plenty of fine alternatives to C++ that don't suck. If you don't have a clean, pleasant way of talking to things that only understand C library conventions, you fail and I'm moving on.

I think you've got that the wrong way around; if you can talk to things using the C library, you automatically get reusability from Java, C#, Python, various Lisps, Ruby, Rust (Go?), and almost every halfway popular language in existence.

What alternative do you know off that is more widely supported by all programming languages?

C API != C++ API

Vulkan development, for instance, drives me up a tree. Vulkan has probably the best C API I've probably ever seen.

Vulkan support libraries like the Vulkan Memory Allocator all tend to be C++ because that's what GameDev tends to use. And they're an absolute nightmare to integrate with anything not C++.

I mean, even the C++ guys eventually gave up. Look at the proliferation of "Header-only" C++ libraries because integrating with the C++ compiler and linker is simply too painful.

I think you are agreeing. C APIs are broadly useful. C++ APIs, not so much.

You are quite correct and I am confused why my comment was upvoted :-/

I'm in full agreement with the GP, I just misunderstood the text (that's all on me, he was very clear).

From the point of view of Java, .NET and JavaScript, integrating anything other than C++ is exactly the reason why I stick with C++ for native libraries used on those ecosystems.

It adds yet another indirection layer on what those runtimes expect, the IDEs aren't prepared for mixed language debugging with anything else, and their build systems also need some additional nurturing.