Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

brave.com

Post reply on HN
Print view View original

121–130 of 289 posts

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#121

Post by oooyay »

no_wizard wrote: post #99
shatsky wrote: post #96

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…

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

Go definitely supports dynamic libraries

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#122

Post by sbt567 »

upcoming-sesame wrote: post #36

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

Recently I've found Cromite and sure glad I did! Finally I've found my Kiwi browser replacement. It is also feels faster than both Firefox and Brave on Android (though YMMV).

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#123

Post by tredre3 »

VladVladikoff wrote: post #91

Is Brave actually a good browser now? Did they rewrite it or something? Last time I looked it was a janky JavaScript mess.

> a janky JavaScript mess.

You might be thinking of Vivaldi. Brave is certainly buggy, but it's not written in Javascript.

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#124

Post by no_wizard »

oooyay wrote: post #121
no_wizard wrote: post #99

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

Go definitely supports dynamic libraries

I don’t mean Dylibs like you find on macOS, I mean loading a binary lib from an arbitrary directory and being able to use it, without compiling it into the program.

It’s been some time since I looked into this so I wanted to be clear on what I meant. I’d be elated to be wrong though

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#125

Post by tredre3 »

ReptileMan wrote: post #55

Well brave still uses 300MB per tab on linux and almost 700MB per tab on Windows. So they do have a long way in front of them.

That's an absolute lie. The entire browser uses around 400MB when a single tab for news.ycombinator.com is open. The tab itself sits at around 35MB. Additional tab increases by the same amount.

https://imgur.com/a/nNA90lk

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#126

Post by [deleted] »

no_wizard wrote: post #99
shatsky wrote: post #96

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…

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

[deleted]

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#127

Post by Groxx »

no_wizard wrote: post #124
oooyay wrote: post #121

Earlier quoted context omitted.

Go definitely supports dynamic libraries

I don’t mean Dylibs like you find on macOS, I mean loading a binary lib from an arbitrary directory and being able to use it, without compiling it into the program. It’s been some time since I looked into this so I wanted to be clear on what I meant. I’d be elated to be wrong though

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.

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#128

Post by Groxx »

shatsky wrote: post #96
nicoburns wrote: post #14

Brave's adblocking engine is a neat example of open source and the ease of sharing lbraries in Rust. It uses Servo crates (also used by Firefox) to parse CSS and evaluate selectors, and is then itself published as a crate on crates.io where it can be pulled in by others who may want to use it.

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…

Not really? You just need to define the stable ABI: you do that via `[repr(C)]` and other FFI stuff that has been around since essentially the beginning. Then it handles it just fine, for both the code using a runtime library and for writing those runtime libraries.

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.

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#129

Post by aorth »

OhioMan2943 wrote: post #67
drnick1 wrote: post #24

I am surprised there does not exist a community fork of Brave yet that strips out all of the commercial stuff (rewards, AI, own updates), making it suitable for inclusion in the repos of mainstream free/libre Linux distros.

You can hide bat with one click as soon as you install brave

For technical users who are in the know, yes. I would not recommend Brave to less-technical friends and family knowing that they would surely be duped by some dark patterns in Brave's UI/UX.

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.

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#130

Post by vlovich123 »

Groxx wrote: post #127
no_wizard wrote: post #124

Earlier quoted context omitted.

I don’t mean Dylibs like you find on macOS, I mean loading a binary lib from an arbitrary directory and being able to use it, without compiling it into the program. It’s been some time since I looked into this so I wanted to be clear on what I meant. I’d be elated to be wrong though

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.
Post reply on HN