Discussion on porting Flutter from Dart to Rust

My question is, is it not easier to port Flutter from Dart to Rust than to come up with a new GUI solution, the flutter team already did a great job of coming out with a nice UI framework, i want to believe it should be easier to port than writing and solving a new GUI solution from scratch

Looking at the image above, all that should be needed is just the Framework section the Engine and Embedded can be reuse

Since it will just be more like a one to one port, it should be faster and easier, right?

I have been thinking about this for sometime now and my noob approach would be to start one file at a time and when enough file has bee port then make it rustic etc.

input appreciated

I'm not sure that demanding input with extra large capitalised text is going to solicit more help than, well, just asking the question normally. Some might take it as shouting!

A "port" typically describes moving a code base from one OS/platform to another and making hopeful minimal changes to get it to run on the new target. It does not imply a total rewrite in a different language.

I have no idea but my gut feeling, from having done such things before, in different languages, is that we are looking at a total rewrite here and it is likely not at all an easy task. A reimplementation of the design.

I would guess that the strict type checking and borrow checking of Rust may well demand that a lot of the code is written a different way. Not just an almost mechanical line for line translation.

The course of action is clear then. I suggest you choose one file, perhaps a small one, from the Flutter code base and set about rewriting in Rust. Then figure out a way to test that what you have works.

I'd be interested to hear how you get on with that.

2 Likes

I'm trying not to be an arse here but you've never tried to do this sort of "port", have you?

What often happens is the you need to reimplement large swathes of functionality from scratch because different languages prefer different ways of writing code and have different libraries/frameworks you can lean on. In particular, I feel like there will be a lot of friction because C++ and Dart like to have a lot of shared mutation, which is one of the things Rust goes to great lengths to avoid.

It also doesn't help that Dart is still actively evolving and being developed, so feature parity will always be a moving target.

Way back in 2000, Joel Spolsky wrote an article about why rewriting a project in a different language/framework/whatever is almost always a bad idea.

Instead, a much better approach is to create bindings which let Rust call into Flutter's original C++ code, and start building new components on top of it.

Over time, you will find that when someone goes to fix a bug or design flaw in the existing C++ code, they might choose to rewrite it in Rust (assuming that writing Rust actually provides tangible benefits over C++, of course) instead of adding yet another patch to a piece of legacy code.

1 Like

yeah, you are right, corrected that

I agreed. just taking a peep and already seeing some frictions, this would need more work than just one to one porting

I have some slight experience in Flutter and in porting things to Rust.

The basic Flutter component design is a better match than many such libraries, in that it explicitly separates the mutable data, notification of said data changing and the (externally) immutable component. These could be fairly well ported from an external API point of view.

The regular problem of lots of internal circular references would need a clear and carefully designed replacement, but this is a pretty well understood area in Rust: the standard is to use table ids wrapped in ref objects with short lived checked borrows.

Layout and event dispatch and the like would probably be fiddly to get ported as is, but they are fundamentally tree traversal, so there's probably nothing too scary in there.

So really, it's just a whole lot of work to do. But people have been working on similar designs, check out druid in particular, so it's probably most effective (and rewarding!) to try porting the Flutter widgets to one of them.

I actually think porting the engine to rust and keeping the flutter widgets and libraries is a more interesting approach. Worked on flutter-rs a few years back and recently started building a flutter-engine in rust. Some of the advantages would be a smaller engine easier to build, modify and cross-compile. The c++ engine uses obscure Google build tooling and is gigantic. There are already quite a few components to make this work, including tiny-skia, fontdue, access kit, icu4x, fluent, winit, pixels, cargo-bundle & cargo-apk.

1 Like

actually once dart supports compiling to wasm, it might make sense to expose the engine api via wasmtime. integrating with the dart sdk is quite annoying and there are many missing features like dart cannot be cross compiled and doesn't support any kind of linking (dart binaries are added to the precompiled dart sdk), which is kind of limiting. obviously google has the resources to do a lot of "customization", but don't think that's particularly scalable.

2 Likes