Post B62HDDYS3RHOXusKtk by wolf480pl@mstdn.io
(DIR) More posts by wolf480pl@mstdn.io
(DIR) Post #B61rk5FnLAK9Y79z3g by wolf480pl@mstdn.io
0 likes, 0 repeats
Have modern programming languages given up on linking?
(DIR) Post #B61tgrlFFWigk3Spfs by amonakov@mastodon.gamedev.place
0 likes, 0 repeats
@wolf480pl doesn't look that way to me, why?
(DIR) Post #B61uNR4eLZI0QRq5o0 by wolf480pl@mstdn.io
0 likes, 0 repeats
@amonakov Rust, Go, and I think also Zig, all seem to focus on including libraries in source form.I haven't used them enough to know, but it doesn't seem like they handle more than one compilation unit?
(DIR) Post #B61uips7LOkFPrBK0O by ignaloidas@not.acu.lt
0 likes, 0 repeats
@wolf480pl@mstdn.io @amonakov@mastodon.gamedev.place rust does have compilation units - each crate is compiled separately. It's just not a per-file compilation unit
(DIR) Post #B61uiq8QMlmyEQoLQG by wolf480pl@mstdn.io
0 likes, 0 repeats
@ignaloidas @amonakov hmm ok, but does it have a defined ABI between those, so that you can distribute an object file? Or is this just an implementation detail and the object files don't make sense outside of the build environment in which they were created?
(DIR) Post #B61vZzYw2rpIopYXho by ignaloidas@not.acu.lt
0 likes, 0 repeats
@wolf480pl@mstdn.io @amonakov@mastodon.gamedev.place because of a bunch reasons it's not "just an object file" (because you can e.g. define a macro in one crate and use it in another so you have to pass over the macro information through), it's more language specific. But like, there's still a linker at the end of it all.But like also, a whole bunch of stuff with "regular object files" assumes a bunch of C'ish stuff, which would place limits on other languages, and IMO it's not worth keeping onto it if it limits you.
(DIR) Post #B61vZzlhHQ2DSPWjb6 by wolf480pl@mstdn.io
0 likes, 0 repeats
@ignaloidas @amonakov oh I'm not talking Cish object files.a JVM .class file is an object fileyou can compile your library to a bunch of .class files on one machine, with one Java version, send them to a different machine with a newer Java version, and compile a program that depends on that library. You can even get autocompletion of that library's types and methods if your IDE supports it.Does Rust have its own stable object file format?
(DIR) Post #B626daXw5ywVt30S6C by ignaloidas@not.acu.lt
0 likes, 0 repeats
@wolf480pl@mstdn.io @amonakov@mastodon.gamedev.place I don't know if it's stable, but it does.(I do however have doubts about having a "stable" format, especially with regards to providing program-global assurances)
(DIR) Post #B626dalPHtiaYpJD60 by wolf480pl@mstdn.io
0 likes, 0 repeats
@ignaloidas @amonakov hmm ok apparently there is a proposal for Rust to have a stable ABI https://slightknack.github.io/rust-abi-wiki/
(DIR) Post #B629TrHVJucSkwN9JQ by wolf480pl@mstdn.io
0 likes, 0 repeats
@ignaloidas @amonakov well, more like was - that wiki is from 2020, incomplete, and it seems that proposal got abandoned :/
(DIR) Post #B62EYWvQvjSuqG60Zs by sjb@mstdn.io
0 likes, 0 repeats
@wolf480pl @amonakov I've always included source files in C too. Ones that I've written anyway.
(DIR) Post #B62Fxq2h5eaDKI7juK by nytpu@tilde.zone
0 likes, 0 repeats
@wolf480pl Even if it had an ABI, without writing their own object file format or something Rust couldn't be linked without also providing sources, because macro expansion (excluding procedural macros) and the way they implemented generics means that the compiler needs to be able to see the source for a library to use the macros and monomorphize the generic functions.Although I think dynamic linking would be very desirable and well overdue, but the reasons I know of it's not implemented: generic monomorphization again (at least some monomorphized functions would have to be built into the binary rather than the library, which could then cause mismatches if linked with a differing version), macro expansion (binary using macroexpanded code that differs from what the library expects), the compiler performing struct field reordering (automatic pahole essentially, necessary for generic structs to not have massive overhead) that's not stable across compiler versions, and the stdlib devs wanting the ability to change the internal types of libcore/libstd without it being breaking. Plus a fuckton of other trivially-fixable incompatible stuff because all those blockers means there's no incentive to make anything else ABI-stable
(DIR) Post #B62FxqGAHZMI04QUu8 by wolf480pl@mstdn.io
0 likes, 0 repeats
@nytpu> generic monomorphization> macro expansionThese problems have existed for over 20 years. I can't believe nobody tried to solve them yet.Regarding custom object format: if clang -flto can put LLVM IR into .o files, and so does GCC with its IR, then I don't see why rustc couldn't put MIR in there.1/
(DIR) Post #B62GED0JUGm3Apofc8 by wolf480pl@mstdn.io
0 likes, 0 repeats
@nytpuFor static linking, that should unblock most things AFAIU - you could monomorphize at link time, and when compiling against a static library, the compiler could extract the IR for the macro from the library and execute it via an interpreter to generate the AST.You'd still need a way to detect when you need to recompile the dependent because the library has changed though...Ofc for dynamic linking it gets more complicated.
(DIR) Post #B62GVeXKNKUfUGZnea by wolf480pl@mstdn.io
0 likes, 0 repeats
@nytpuIf Rust had its own dynamic linker it could monomorphise at load time, but that still leaves the issue of macros...I'm guessing having macros work on an IR level instead of AST level (and thus be able to execute at link time / load time) is something a different language could do but Rust can't at this point.
(DIR) Post #B62HDDJCy75PmdkA8e by nytpu@tilde.zone
0 likes, 0 repeats
@wolf480pl Well as mentioned, I think it's well overdue for both precompiled static linking and dynamic linking (i.e. I implicitly think it's possible), those are just the main reasons they say they haven't. (And they've done very little to improve on any of it)I think for traditional static linking in particular, there also just isn't much motivation given that link times already constitute like 80% of the time it takes to compile a large Rust project (due to Reasons it's very hard and slow language to link even with LTO and everything disabled), so doing everything ahead-of-time but linking just isn't that valuable
(DIR) Post #B62HDDYS3RHOXusKtk by wolf480pl@mstdn.io
0 likes, 0 repeats
@nytpuI see... did Rust solve C++'s problem of slow includes by making liking even slower? Or does it deal with loading macros from crates better than C++ does loading templates from headers?
(DIR) Post #B6AZDQeehYG5cAhttA by wolf480pl@mstdn.io
0 likes, 0 repeats
@nytpuso at compile time, code using a struct doesn't know its offsets, and the library that defined the structs will only be available at link time, and will only know the offsets if you tell it the type parameters for the generic?hmm...https://mstdn.io/@wolf480pl/116549352291024783