Linkers are such weird pieces of software.

So intricate that they're a huge endeavor, so fundamental every developer needs one, but so obscure there's very few of them. There's more production-quality assemblers and web servers than linkers, but neither will ever work without a linker.

Such a strange corner of computer technology.

Anyone nerdy enough writes their own compiler. Lots of people have written their own compressor or archiver; it's still an area of active research.

But linkers? It's kinda a solved problem, and so uninteresting (?). But it's a very large and fiddly problem, and so hard to toy around casually.

Heck, there's way, way more people writing their own *operating system* than their own linker. Or C compiler. Or basically anything you can think of.

@icefox I don't think this is actually true Link time optimization is relatively recent and something the LLVM people have been working on.

And a lot of the limitations of C++ come from it having to be compatible with the C linker. I think things like Rust and Haskell, say, implicitly have their own linker but also use the standard system linker to link with C libraries for foreign calls.

@Azure @icefox I assume most/all languages that compile to a not-C ABI have their own linker (and use the system's for FFI).

I can at least confirm OCaml and Haskell do, and I'm not sufficiently familiar with other such languages to say.

@kellerfuchs @Azure iirc the thing is that some languages don't have an idea of "linker" as a separate thing. Ocaml is like this too, a think? The compiler combines things itself and there's no "separately compiled but still part of the same program" stage. The combination happens at the AST/IR level, not the object file level.

Not sure if this is correct. I think it's how Rust's link time optimization works though.