131–140 of 289 posts
Earlier quoted context omitted.
Both handle that just fine. Go does this via cgo, and has for over a decade. You do still need to write the interfacing code, but that's true for all languages.
Then by that argument Rust also supports dynamic linking. Actually it’s even better because that approach sacrifices less performance (if done well) than cgo inherently implies.
Earlier quoted context omitted.
And yet Rust ecosystem practically killed runtime library sharing, didn't it? With this mentality that every program is not a building block of larger system to be used by maintainers but a final product, and is statically linked with concrete dependency versions specified at development time. And then even multiple worker processes of same app can't share common code in memory like this lib, or ui toolkit, multimedi…
Dynamic libraries are a dumpster fire with how they are implemented right now, and I'd really prefer everything to be statically linked. But ideally, I'd like to see exploration of a hybrid solution, where library code is tagged inside a binary, so if the OS detects that multiple applications are using the same version of a library, it's not duplicated in RAM. Such a design would also allow for libraries to be update…
One challenge will be that the likelihood of two random binaries having generated the same code pages for a given source library (even if pinned to the exact source) can be limited by linker and compiler options (eg dead code stripping, optimization setting differences, LTO, PGO etc).
The benefit of sharing libraries is generally limited unless you’re using a library that nearly every binary may end up linking which has decreased in probability as the software ecosystem has gotten more varied and complex.
Earlier quoted context omitted.
if I recall correctly Rust does not support any form of dynamic linking or library loading. Most of the community I’ve interacted with are big on either embedding a scripting engine or WASM. Lots of momentum on WASM based plugins for stuff. It’s a weakness for both Rust and Go if I recall correctly
It does support dynamic libs, but virtually all important Rust software seems to be written without any consideration for it.
They’re only really useful if you’re distributing multiple binary executables that share most of the underlying code, and you want to save some disk space in the final install. The standard Rust toolchain builds use them for this purpose last time I checked.
Earlier quoted context omitted.
And yet Rust ecosystem practically killed runtime library sharing, didn't it? With this mentality that every program is not a building block of larger system to be used by maintainers but a final product, and is statically linked with concrete dependency versions specified at development time. And then even multiple worker processes of same app can't share common code in memory like this lib, or ui toolkit, multimedi…
Dynamic libraries are a dumpster fire with how they are implemented right now, and I'd really prefer everything to be statically linked. But ideally, I'd like to see exploration of a hybrid solution, where library code is tagged inside a binary, so if the OS detects that multiple applications are using the same version of a library, it's not duplicated in RAM. Such a design would also allow for libraries to be update…
Outside of embedded, this kind of reuse is a very marginal memory savings for the overall system to begin with. The key benefit of dynamic libraries for a system with gigabytes of RAM is that you can update a common dependency (e.g. OpenSSL) without redownloading every binary on your system.
I’ll never trust them again after that.
Earlier quoted context omitted.
Supply-chain attacks aren't really a property of the dependency management system Not having a dependency management system isn't a solution to supply chain attacks, auditing your dependencies is
> auditing your dependencies is How do you do that practically? Do you read the source of every single package before doing a `brew update` or `npm update`? What if these sources include binary packages? The popular Javascript React framework has 15K direct and 2K indirect dependencies - https://deps.dev/npm/react/19.2.3 Can anyone even review it in a month? And they publish a new update weekly.
> The popular Javascript React framework has 15K direct and 2K indirect dependencies - https://deps.dev/npm/react/19.2.3
You’re looking a dependents. The core React package has no dependencies.
I like Brave but the only thing that keeps me from using it on mobile is the lack of extension. That's why Firefox is my daily driver on Android
My fucking god I’m not sure enshittification has ever been so widely dispersed. It’s impossible to have any type of unified set up across different OS/devices currently.
Is Brave still a front for a cryptocurrency pump-and-dump scheme?
Never was.
The best part was this whole scam sitting as an unresolved issue on GitHub for months after they finally acknowledged it (after first denying it lol).
Closest browser I’ve seen to an actual virus in maybe ever.
And it’s a good lesson for developers that once you lose trust there are many of us who will never make the same mistake again purely out principle.
Earlier quoted context omitted.
Both handle that just fine. Go does this via cgo, and has for over a decade. You do still need to write the interfacing code, but that's true for all languages.
Then by that argument Rust also supports dynamic linking. Actually it’s even better because that approach sacrifices less performance (if done well) than cgo inherently implies.