He was working for Google but he left recently, no? I doubt Google would have any problem if he works on mold linker full time.

I believe he decided to do things this way.. one man show is always problematic (atleast it is easy to go back to lld if anything happens to the author or the project itself)

He doesn't want to work on mold as part of Google or another large company like that because then Google would take ownership of the whole program; he wants to maintain ownership of it. It's mentioned in a tweet of his

Doesn't Google pay people to work on the Linux kernel, even though Google can't take ownership of the whole Linux kernel?

Google owns employee code outside of work if I understand things correctly.

So Google only has copyright over the portions their employees have contributed.

Well, safari is closed source..

Most of safari isn’t.

Willing to share them?

They ghosted me, but it was in the initial call.

Keyword there is "slightly".

What gcc/clang does?

But do they support gitlab? Pay them?

Or are they just (ab)use open source projects to spend less money? (They had to pay $$$ to github).

They at least support gotlan in being a testimonial. And usually that implies some commercial agreement.

And typically such organisations, like arm, want to have a contract, and be it only to make lawyers happy. (clearer liability etc )

Wonderful!

Can you please provide some easy examples?

Can this be a pip3 package?

It is now up on pypi:

https://pypi.org/project/improveai/

We’ll be updating the docs with examples over the coming weeks. Are there any specific use cases you’re interested in?

C++ needs a major reboot. Remove old school annoying guys which hold all progress. Allow ABI break. Pick top 3 priorities and adress them in 2-3 years.

"Allow ABI break" is equivalent to "kill C++". Some people would like that. I would not.

A less drastic alternative is today allowed: define a new ABI, and see who joins you. This would be akin to what happened when we got the amd64 ABI, or the hybrid 32/64 x86 ABI (more registers, but pointers are still 32 bits): a different compilation target that also runs on the same physical hardware. OSes and linkers would need to recognize binaries compiled to this ABI, and take care not to mix them up.

People who want a new ABI do not like this model because they are not confident anybody would join them. That is itself reason enough not to accept ABI-breakage.

Why not define the old ABI, and require either special tooling options or #pragma directives to access it. This is something that implementers could do on their own, with no need for any support by the Standard.

That's actually the problem compared to a conservstive language standard committe as in C (WG14). WG21 (C++) are the yea sayers, WG14 (C) the no sayers. C++ moves much too fast to please anyone. C is a glacier, and if they adopt something it's a mistake, or just bikeshedding.

ABI's have their own committee, the gABI. This is frozen.

Progress is much better now with trunk (clang 15).

Meta, Intel have replaced “Apple, Google” duo in terms of cpp frontend development.

It remains to be seen how much.