Or is there something that cargo does to manage it differently (due diligence?).
Cargo does have lock files by default. But we really need better tooling for auditing (and enforcing tha auditing has happened) to properly solve this.
Not having a dependency management system isn't a solution to supply chain attacks, 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.
Some people use 'pnpm', which only runs installScripts for a whitelisted subset of packages, so an appreciable fraction of the npm ecosystem (those that don't use npm or yarn, but pnpm) do not run scripts by default.
Cargo compiles and runs `build.rs` for all dependencies, and there's no real alternative which doesn't.
PS. Actually I'll risk to share my (I'm new to Rust) thoughts about it: https://shatsky.github.io/notes/2025-12-22_runtime-code-shar...
I'd give a gig of my memory to never have to deal with that again.
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
Rust supports two kinds of dynamic linking:
- `dylib` crate types create dynamic libraries that use the Rust ABI. They are only usesul within a single project though, since they are only guaranteed to work with the crate that depended on them at the compilation time.
- `cdylib` crate types with exported `extern "C"` functions; this creates a typical shared library in the C way, but you also need to implement the whole interface in a C-like unsafe subset of Rust.
Neither is ideal, but if you really want to write a shared library you can do it, it's just not a great experience. This is part of the reason why it's often preferred to use scripting languages or WASM (the other reason being that scripting languages and WASM are sandboxed and hence more secure by default).
I also want to note that a common misconception seems to be that Rust should allow any crate to be compiled to a shared library. This is not possible for a series of technical reasons, and whatever solution will be found will have to somehow distinguish "source only" crates from those that will be compilable as shared libraries, similarly to how C++ has header-only libraries.
You can also link to C libs from both. I guess you could technically make a rust lib with C interface and load it from rust but that's obviously suboptimal
You can't COW two different libraries, even if the libraries in question share the source code text.
People writing Rust generally prefer to stay within Rust though, because FFI gives up a lot of safety (normally) and is an optimization boundary (for most purposes). And those are two major reasons people choose Rust in the first place. So yeah, most code is just statically compiled in. It's easier to build (like in all languages) and is generally preferred unless there's a reason to make it dynamic.
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.
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.
This way we'd have no portability issue, same benefit as with static linking except it works with glibc out of the box instead of requiring to use musl, and we could benefit from filesystem-level deduplication (with btrfs) to save disk space and memory.
Yes, it did. We have literally millions of times as much memory as in 1970 but far less than millions of times as many good library developers, so this is probably the right tradeoff.
And increasingly, many C++ libraries are header only, meaning they are always statically linked.
Haskell (or GHC at least) is also in a similar situation to Rust as I understand it: no stable ABI. (But I'm not an expert in Haskell, so I could be wrong.)
C is really the outlier here.
It still boggles my mind that Adobe Acrobat Reader is now larger than Encarta 95… Hell, it’s probably bigger than all of Windows 95!
The main problem with dynamic libraries is when they're shared at the system level. That we can do away with. But they're still very useful at the app level.
Brendan talks about this a bit more here: https://x.com/BrendanEich/status/2006412918783619455
"""
Brave Origin is:
1/ new, optional, separate build (stripped down, no telemetry/rewards/wallet/vpn/ai);
2/ free on Linux, one time buy elsewhere.
"""
So the stripped down version (at least the non-Linux one) will not be open source?
Rules that require the distribution of source code don't require the distribution of binaries.
As other people have mentioned you can resell open source software. I have a big box Linux distro on my shelf here.
And you should really be using https://flathub.org/en/apps/com.brave.Browser
Even Firefox, which is the best we have currently, surprises us a few times a year with questionable decisions. Still, it's what I recommend to people.
This only claims that the memory usage of the adblock engine was reduced, not the total memory consumption of the browser.
I might have to try switching from FF...
But nowadays, vertical tabs are native since Firefox v136 [3][4], so at least for the basics you won't need an add-on.
[1]: https://addons.mozilla.org/firefox/addon/sidebery/
[2]: https://addons.mozilla.org/firefox/addon/tree-style-tab/
The more rust gets written, the better AI will be able to write it for people... I like to be optimistic.
I do agree it's kind of a misleading headline, the real update is their use of Flatbuffers.
Me too.
> The more rust gets written,
Rust seems neither necessary nor sufficient for getting developers to care about memory efficiency again though.
If you also care about memory safety it further limits options.
AI may have forced the hand on this. Users will no longer be able to subsidize software performance with hardware upgrades due to the great DRAM debacle of 2026..
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.
Shared memory obviously exists, though and they do mention in the post (missed it first time around) that they try to share Adblock resources.
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.
https://news.ycombinator.com/item?id=18734999
https://www.sophos.com/en-us/blog/brave-ceo-apologises-for-a...
https://www.bleepingcomputer.com/news/security/facebook-twit...
and issues with tor (presumably fixed by now)
https://www.coindesk.com/tech/2021/02/22/brave-browser-was-e...
> In 2022, Brave faced further criticism for bundling its paid virtual private network (VPN) product, Brave Firewall + VPN, into installations of its Windows browser, even for users who had not subscribed to the service
I'll happily take performance improvements cause most products lack any efficiency care nowadays.
Are you referring to current RAM prices or bloat of numerous Electron apps?
This kind of lazy thinking is why today’s software is so bloated and slow.
The lesson here is pointer-chasing data structures and trees are a lot more expensive than everyone and most programming languages like to pretend they are.
This is what Firefox blocks by default: https://support.mozilla.org/en-US/kb/enhanced-tracking-prote...
https://winaero.com/how-to-enable-split-view-in-firefox-146/
2. Look at Brave - see 1.
> in this release:
> Other enhancements, stability improvements, and security updates
No mention of efficiency, or adblocking whatsoever!
You might be thinking of Vivaldi. Brave is certainly buggy, but it's not written in Javascript.
>This repository holds the build tools needed to build the Brave desktop browser for macOS, Windows, and Linux.
The web browser is here : https://github.com/brave/brave-core (8% of typescript)
On 64-bit systems, pointers themselves can really start to take up a lot of memory (especially if you multiply them across 100k+ adblock filters). Switching to array indices instead of pointers saves a lot of memory that's otherwise wasted when you don't need to address the entire possible memory space.
Flat buffers is know to bloat client code. Was any trick used to mitigate that?
I’ll never trust them again after that.
The VPN they installed was disabled and they could not activate it without user interaction. And the only reason they did this is so when you click "activate VPN" in the browser, it works immediately.
On top of that, other businesses employ(ed) similar tricks. For years and years and years, Dropbox on macOS did a very specific hack to give itself more permissions to ease syncing. Hell, Firefox injected ads for Mr. Robot via a surreptitiously installed invisible extension.
Still a boneheaded move by Brave, just like adding their own affiliate link to crypto links (if none were added) to generate extra revenue for the company at no extra cost to the user. But that is even further in the past.
At any rate, they also fund or develop a bunch of anti-ad tech and research and make it open source / publish it. The defaults of Brave protect your privacy much better than Firefox's defaults. And so far, their BAT concept is the only one that is a legitimate alternative to an ad-funded internet.
Brave is everything Mozilla wishes it had become.
And yeah, my bone to pick is warning others not to fall for Brave’s slick PR. Companies that act that way can pay the price.
What you may be thinking of was at one point, when you went to a URL (for some URLs), the browser would rewrite the URL to contain their affiliate link. There was blowback for doing that. They quickly removed that/haven't done it since as far as I know
In fairness, that is incredibly shady and they deserve this mistrust even years later because of it.
Brave never did that.
Brave blocks third-party ads & trackers by default.
(disclaimer: I lead privacy and adblocking at Brave)
(disclaimer: people remember how sketchy Brave is)
What they should have done instead is just take hundreds of millions of dollars from Google, like a non-sketchy browser.
Disclaimer in case it's not obvious: I am a Brave employee
