Hacker News Reader

Comment by pcwalton | Hacker News Reader

I would like to see an ECS style UI design in Rust that represents widgets as IDs, to allow arbitrary object graphs without interior mutability. I don't see a reason why this would be incompatible with GTK, but we won't know until we try. It might work out really well.

It also might be that Rust is not the right language to write high level UI logic in at this time, and a GC'd language would be more appropriate. That's fine too. One of the strengths of Rust is its interoperability with other languages. C and C++ are certainly not the right languages to implement high level UI logic in, for example.

View on HN

I agree with you. From my point of view, the advantage of C/C++ for UI is not about high level logic, but complicated custom widget with lots of low level functions and good performance. C/C++ is not good for a weather app, but almost the only choice for the canvas of Photoshop or the waveform of Audition, and it seems like no one else considers seriously challenging this. I am confident that given enough time, Rust will be adopted for social app or game GUI. But I don’t know if this would prevent Rust from writing practical large productivity software.

I am very much not saying that C++ is the answer for large-scale productivity software. In fact, I'm saying the opposite.

Let me be clear: Given the choice between Rust or C++ for writing Photoshop, I will pick Rust every time.

I am not saying that C++ is the answer for large-scale productivity software, but C++ is the answer for the complicated widgets used there. I would prefer Rust for the main framework of photoshop too, but I am not sure whether there is an elegant way writing the canvas widget.

Yet, although Microsoft security now advises for C#, Rust and constrained C++, they went ahead and are using C++ for React Native and WinUI 3.0, removing the dependecy on .NET Native.

Apparently because that is the only way to sell MFC/ATL holdouts to WinUI, and allow WinUI to be called from classical Win32 without too much overhead, and also because .NET Native ideas will be migrated to .NET 5.

Delphi and C++ Builder did well enough with high level UI logic.

C++'s problem is that the path of righteousness is too narrow, but with heavy cultural idioms and norms, you can keep a lot of the people safely hemmed in, while retaining all the escape hatches.

> with heavy cultural idioms and norms, you can keep a lot of the people safely hemmed in, while retaining all the escape hatches.

Empirically, no, you cannot. Nobody has succeeded at writing memory-safe C++ at scale using normal software development practices.

You're overstretching my claim, but I'm not going to press the issue. I want C and C++ replaced just as much as you.

Reply on news.ycombinator.com