Google To Allow Rust Code In The Chromium Browser

[Draget]

Has anyone ever looked at the codebase of chrome(ium)? It is truly horrific! I have been perplexed by the cache-breaking, megabyte-sized huge source files, which are per-processed and concatenated into those hunks of jumb code files with code and code and more code. A lot of vendoring, a lot of stuff... x.x

It is really bad how much code we are running for our 'web experience'.

I am sticking with Firefox! (Which has also a large codebase, not saying that this is very different here. But it is not as bad as chrome(

[c117152]

Only 5% readable HTML code that is proprietary with the rest 95% open source is proprietary garbage.. yeah of course. Why is it that so many in the open source community have these brain dead opinions about Vivaldi? When its founder is also one of the most vocal privacy advocates?

From a privacy standpoint, one line of code is all it takes to backdoor any codebase. So, given Chromium's 35million LoC, even just 0.000003% is too much.

From a practical FOSS standpoint, if I can't fork it and I can help it by using other code bases, I don't want to depend on it in my products.

[andyprough]

Your opinion is noted, but ungoogled chromium is far from spyware.

In fact, it's just a few bits and bytes removed from spyware, so not so far at all.

[sarmad]

Will that actually speed up development? To me it sounds like mixing code bases makes you move slower, not faster, and also potentially cause more bugs, not less.
I can see Rust fans unnecessarily breaking some components out into separate libraries so they can write it in Rust, or rewrite some dependencies in Rust and end up in code duplication and that kind of stuff.

[destiny_chai]

Seems like a win-win. Chromium is probably around 40 million LOCs so it would probably be hard to rewrite, but to some degree it sounds simpler than interop infrastructure.

[Ironmask]

Will that actually speed up development? To me it sounds like mixing code bases makes you move slower, not faster, and also potentially cause more bugs, not less.
I can see Rust fans unnecessarily breaking some components out into separate libraries so they can write it in Rust, or rewrite some dependencies in Rust and end up in code duplication and that kind of stuff.

Mixing codebases is fine as long as neither is garbage-collected. If you're dealing with a GC language, then things get really hairy, since you have to work around the GC randomly deciding if it wants to free your resources or not. Chromium is C++, which has a lot of strong interop with Rust (not good interop, but strong due to the sheer prevalence of C++, so there's a lot of Rust libraries and macros to convert between them). Other than that, it just relies on the codebase and how the project architecture is laid out, since a project can essentially implement it's own wild runtime that also just does whatever it wants without your say-so (Qt is a good example of that, it's practically a runtime on par with the JVM/CLR despite "merely" being a C++ library, which is why runtime-managed languages have a few issues binding to it).

The Chromium team have been planning this out for a long time. They already implemented some new IPC mechanisms to better deal with exactly this situation, when they were ready to accept other languages into the project. It also sounds like they're segregating Rust crates to only being third-party libraries and not the core of the system, so there won't be any cross-project spaghetti going on. I imagine their path forward is to make more and more parts of Chromium in Rust until the core is small enough to be replaced itself, kind of like what Firefox is doing, and what Linux is probably going to go through in the next two decades. If anything, this change will probably help the project become more modular, rather than the opposite result of slowing it down by introducing more cross-concerns. Reminds me of how Microsoft had to completely restructure Windows NT's codebase when going from XP to Vista (MinWin). Ironically, working in entirely one language can make your project more of a convoluted mess, not less. When you have two languages to worry about, you care a lot more about the interconnects between components, and thus better plan out your interfaces and boundaries. I experience this a lot when working between Rust and Python for AI projects.

[jacob]

So is Vivaldi..

Isn't Vivaldi proprietary?

[jacob]

Has anyone ever looked at the codebase of chrome(ium)? It is truly horrific! I have been perplexed by the cache-breaking, megabyte-sized huge source files, which are per-processed and concatenated into those hunks of jumb code files with code and code and more code. A lot of vendoring, a lot of stuff... x.x

It is really bad how much code we are running for our 'web experience'.

I am sticking with Firefox! (Which has also a large codebase, not saying that this is very different here. But it is not as bad as chrome(

Our web experience relies on an incredibly intricate and complex software platform that includes the equivalent of an operating system (complete with memory management, IO cache, thread scheduling, access control, graphics , a GUI API and its own implementation of various network protocols), at least two different, JIT-powered virtual machines, audio and video streaming capabilities, extensive internationalisation features and more, all in one. How much code do you expect it to have?

[ssokolow]

Will that actually speed up development? To me it sounds like mixing code bases makes you move slower, not faster, and also potentially cause more bugs, not less.
I can see Rust fans unnecessarily breaking some components out into separate libraries so they can write it in Rust, or rewrite some dependencies in Rust and end up in code duplication and that kind of stuff.

The core concern of things like the borrow checker is ensuring you only need to reason about code's behaviour locally, not globally, and let the compiler catch attempts to make the abstractions leak.

That has huge potential to speed up development.

[CommunityMember]

Has anyone ever looked at the codebase of chrome(ium)?

Yes!

It is truly horrific!

abso-f'ing-lutely.

And last I informally talked to some members of the greater Chrome team they did not disagree, but their only (weak, by their own admission) justification was that Chrome grew organically and supporting some platforms is "complicated" (both technically, and legally, due to IP).