Hacker News Reader

Comment by xiphias2 | Hacker News Reader

Shouldn't all code be gradually updated to use Rust libraries when they exist? Is it a stupid idea?

I know it's a lot of work, but the Android/Chrome teams are big, and this is important enough work that could improve the security of the systems.

View on HN

It's more like Rust is still young and there are far from enough people with same level of skill as there are C/C++ programmers. As an example just think of the amount of work that's gone into libavcodec/libavformat, it will take years to replicate and reach the same level of functionality.

Eventually it will happen though (at least I hope so).

Here we're talking about PNG format, for which a codec already exists.

I was asking about the integration work, exporting high quality Rust libraries with a C API and calling from Skia for example.

This has actually been happening for Firefox [1]. Several parser/codec libraries have already been ported for exactly this reason.

1. https://wiki.mozilla.org/Oxidation

It's cool, I knew this is happening, but didn't know the code name for it. The big thing will be when WebRender is shipping to Firefox.

The plan for C++ / Rust interop sounds amazing.

Anyways the main question is whether other companies should reuse the work already done by the great Mozilla team.

What's exciting about the interop plan? I'm currently working on a project that requires including some C headers in Rust. Trouble is the bindgen library doesn't recognize inline functions and I need to create wrappers for those.

Well... Rust has some safety features, but 1. so do others (Go is a Google project...), 2. it helps with some things and less with others. So yeah, if you have the resources, using Rust/Go/whatever and taking a security-first view is sensible. It's not a silver bullet, but it's probably helpful.

Well the problem with go I believe as soon as you have to make high performance code you disable the garbage collector, which removes a lot of the safety features.

Actually Rust _is_ a silver bullet, that's why it's so exciting.

System level programming memory safety was a dream for a long time.

Go is not capable of this at all, so it's out of question for replacing low level libraries.

Why isn't Go capable of system level programming memory safety?

It has a runtime with a GC. It's capable of safety, but not the low level performance/predictability of the Rust approach, and is also harder to embed than a Rust approach.

This is not a disqualifer for most use cases, but is for some.

It does not actually provide memory safety in concurrent scenarios, only for purely sequential code. Given the predicted use-case scenarios for Go, that's pretty much a truck-sized hole in the language's purported guarantees, especially in comparison with Rust.

Technically that's a very fine idea. I write codecs in Rust, and it's working great for this use case.

But a complete rewrite is a hard sell where just fuzzing and patching existing code seems like a quicker fix and not rocking the boat too much.

It's an interesting question whether fuzzing or replacing is the better way to go. Newer Rust libraries can have other (unknown) problems, that's why I was interested in which is the statistically better solution for improving the code base.

But from what you wrote, it sounds more like what's simpler to implement for the team gets done.

I think Skia is dynamically linked with a C++ API.

Reply on news.ycombinator.com