❄️🦊 is a user on octodon.social. You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.

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.

❄️🦊 @icefox

@Azure Rust uses the system linker. Using llvm's code generation to do link-time code optimization (equivalent to what the Java/Clojure people call tree shaking?) is still an unstable feature.

I know this because Windows link.exe does this automatically and someone euphoniously titled WindowsBunny likes to brag about it.

· Web · 0 · 0

@icefox Tree shaking just gets rid of everything that isn't used. Lisp systems do it when distributing standalone executables. Stalin uses it as a prequel to partially specializing the heck out of everything.

Link time optimization is (or should be) way more than just a tree shake.

@Azure a combination of tree shake, inlining and then optimization based on the IR resulting of the inlining? I am fuzzy on the details.

@Azure Iirc most C compilers stop at function-level tree shake, which is Often Good Enough for technology to mostly stop there since the late 90s.