Hacker News new | past | comments | ask | show | jobs | submit login

There’s been a lot of interest in faster linkers spurred by the adoption and popularity of rust.

Even modest statically linked rust binaries can take a couple of minutes in the link stage of compilation in release mode (using mold). It’s not a rust-specific issue but an amalgam of (usually) strictly static linking, advanced link-time optimizations enabled by llvm like LTO and bolt, and a general dissatisfaction with compile times in the rust community. Rust’s (clinically) strong relationship with(read: dependency on) LLVM makes it the most popular language where LLVM link-time magic has been most heavily universally adopted; you could face these issues with C++ but it wouldn’t be chalked up to the language rather than your toolchain.

I’ve been eyeing wild for some time as I’m excited by the promise of an optimizing incremental linker, but to be frank, see zero incentive to even fiddle with it until it can actually, you know, link incrementally.






C++ can be rather faster to compile than Rust, because some compilers do have incremental compilation, and incremental linking.

Additionally, the acceptance of binary libraries across the C and C++ ecosystem, means that more often than not, you only need to care about compiling you own application, and not the world, every time you clone a repo, or switch development branch.


compiling crates in parallel is fast on a good machine. OTOH managing C++ dependencies without a standard build & packaging system is a nightmare

Imagine if Linus needed a gaming rig to develop Linux...

And he also did not had cargo at his disposal.

No need to point out it is C instead, as they share common roots, including place of birth.

Or how we used to compile C++ between 1986 and 2000's, mostly in single core machines, developing games, GUIs and distributed computing applications in CORBA and DCOM.


I solved this by using Wasm. Your outer application shell calls into Wasm business logic, only the inner logic needs to get recompiled, the outer app shell doesn't even need to restart.

I don’t think I can use wasm with simd or syscalls, which is the bulk of my work.

I haven't used SIMD in Rust (or Wasm). Syscalls can be passed into the Wasm env.

https://doc.rust-lang.org/core/arch/wasm32/index.html#simd

https://nickb.dev/blog/authoring-a-simd-enhanced-wasm-librar...

Could definitely be more effort than it is worth just to speed up compilation.


How is this different than dynamically linking the business logic library?

Very similar, but Wasm has additional safety properties and affordances. I am trying to get away from dynamic libs as an app extension mechanism. It is especially nice when application extension is open to end users, they won't be able to crash your application shell.

https://wasmtime.dev/ https://github.com/bytecodealliance/wasmtime




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: