Google To Allow Rust Code In The Chromium Browser

[NobodyXu]

Of course if Rust got a tiny C compiler formalized into the language (perhaps in unsafe tags), that would become seriously competitive! I am surprised a commercial entity hasn't already done this.

Rust does supoort extern C function call, repr(C) data structure that is compatible with C and bindgen actually links with libclang to parse C API ans genrate Rust API.

Not exactly as embeddinf C compiler into the language, but with bindgen linking with libclang, it probably can archive the same thing since it can be run during compilation to generate bindings, or it can be invoked as a regular executable and generate code that can be included in git.

[Quackdoc]

It's not a myth even if Rust fanboys keep saying that. Truth is, you can write unsafe code in Rust as well. You have to, when interfacing with C code.

aye, when you interface with other languages, it can and sometimes does create unsafe code, but that creates a drastically smaller region of unsafe code, meaning it is far easier to focus on and do correctly, and in some cases even isolate as well.

also it's not like rust is "safe" it just is far easier to make safe code in comparison to other languages, still a massive win, but not the win that rust fanatics like to claim.

[kpedersen]

Rust does supoort extern C function call, repr(C) data structure that is compatible with C and bindgen actually links with libclang to parse C API ans genrate Rust API.

Admittedly it is more sophisticated than SWIG. However it still poses issues when dealing with C MACROS and more importantly, object lifetimes.

An oversimplified example is having a std::shared_ptr<dirent> but then having the lower C (or C++) system calling closedir on the underlying DIR*. Data gets ripped out from under the other languages memory system. No matter how safe it is alone. Rust's Rc<T> can't really handle this any better.

A better architecture could help but I feel the author here; describes the issue quite well: http://way-cooler.org/blog/2019/04/2...oler-in-c.html

[NobodyXu]

Admittedly it is more sophisticated than SWIG. However it still poses issues when dealing with C MACROS and more importantly, object lifetimes.

An oversimplified example is having a std::shared_ptr<dirent> but then having the lower C (or C++) system calling closedir on the underlying DIR*. Data gets ripped out from under the other languages memory system. No matter how safe it is alone. Rust's Rc<T> can't really handle this any better.

A better architecture could help but I feel the author here; describes the issue quite well: http://way-cooler.org/blog/2019/04/2...oler-in-c.html

Well, it definitely cqnnot directly port C macros into rust since macros in rust is sanitized while in C it's just test substitution.

The problem regarding to C freeing the resource but does not document it is indeed a problem, IMO the way to fix is to simply add doc.

If you are really concerned about this, then perhaps compiling the C code into wasm could be a good idea since it would make sure any corruption in the code cannot cross the wasm interpret, but it will deceease the performance so probably not suitable for scienarios like browser and wlroots.

Thanks for the link, I would read it for sure.

[microcode]

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(

Firefox is worse lol; plus if you're concerned about security or stability, Chromium has a lot more engineering resources on those problems. Granted, Firefox has had some big wins over the last few years by a) adopting more architecture from Chromium and b) introducing some small Rust components. Google's capacity for scaling up Rust development is much greater, as well, they already have a bunch of very competent Rust developers internally.

[Anux]

Not only do you have to frig around with bindings but you also have very little guarantee of safety.

False, you get the full guaranties for everything written in safe rust. On binding you just need to know that you are communicating with unsafe (rust or C++) code. If you encounter a use after free, null pointer, etc error than you know that you don't need to check your safe rust code.

C++ <-> Rust lifetimes are even harder to manage than ANSI C <-> Rust lifetimes in bindings.

Rust lifetimes are not in the compiled code, they just restrict you from writing/compiling certain code patterns.

So ultimately I just hope they choose *one* and it becomes mostly homogeneous soon.

that would be a complete rewrite and a project that big would need years and most likely fail. It's much easier to replace small parts which could eventually lead to a full rewrite after years but with the benefit of using and testing your code in a working browser.

[Weasel]

RIP Chrome. It was nice knowing you.

[Volta]

Where is the spyware in stock Google Chrome anyway? [...]
You are free to use crippled or minimalist browsers if your needs are met. But, don't refer to what other people see as productivity features as spyware.

Google Chrome is a f****ng spyware. Only closed [source] minded people don't know this:

https://www.sciencealert.com/a-tech-expert-says-we-should-stop-using-google-chrome

My tests of Chrome vs. Firefox unearthed a personal data caper of absurd proportions. In a week of Web surfing on my desktop, I discovered 11,189 requests for tracker "cookies" that Chrome would have ushered right onto my computer but were automatically blocked by Firefox. These little files are the hooks that data firms, including Google itself, use to follow what websites you visit so they can build profiles of your interests, income and personality.

Chrome is even sneakier on your phone. If you use Android, Chrome sends Google your location every time you conduct a search. (If you turn off location sharing it still sends your coordinates out, just with less accuracy.)

[kpedersen]

False, you get the full guaranties for everything written in safe rust. On binding you just need to know that you are communicating with unsafe (rust or C++) code. If you encounter a use after free, null pointer, etc error than you know that you don't need to check your safe rust code.

Not quite. It is more complex than that. Your safe Rust sections could still be carrying an expired pointer around in its underlying layers. As my previous example showed, any high level memeory management system can quite happily hold dangling pointers ripped out by other systems. Even traditional garbage collected values.

Rust lifetimes are not in the compiled code, they just restrict you from writing/compiling certain code patterns.

Its not Rusts lifetimes I am worried about. It is the lifetimes of the native data of the system that Rust needs to manage.

It's much easier to replace small parts which could eventually lead to a full rewrite after years but with the benefit of using and testing your code in a working browser.

I'm not sure. No longer can a single test suite be used. Different languages effectively introduce a black box that no single i.e static analyser can trace. Now you need multiple and they can't often talk to one another.

You are quite right that it isolates many of the memory errors to the unsafe{} sections but it does weaken coverage of some types of testing. If it was 100% Rust, I would say this is worth it. But little sprinklings of Rust is going to be difficult in the short term at least.

[sabian2008]

"Rust (without word unsafe) guarantees memory safety", they say. But later...

• https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust
• (Upvoted 8 times at least): https://www.phoronix.com/forums/foru...68#post1273668

God! This is moronic, either point to a specific CVE or STFU. I took a quick look at the first 15 reports, all are logic mistakes, not use after free, memory race conditions, etc. The only thing I saw memory related is integer overflow. I don't think there is a memory model where you can prevent integer overflow without a runtime penalty.