On Tuesday, 25 October 2022 at 18:11:28 UTC, Don Allen wrote:

But the browser not really "ordinary" application. And all users will be happy if it will be as fast as possible and consume not too much memory.
Actually users will be happy if every app will have those parameters. Instead of that we have Intellij IDEA and Electron apps which are very far from being blazingly fast.

On Tuesday, 25 October 2022 at 21:38:44 UTC, Sergey wrote:

If you think that the user experience would be any different if Mozilla used Go or D for the work they are doing with Firefox, then you and I just need to agree to disagree.

I can re-cite my own recent experience, stated here more than once: I wrote a suite of personal financial management applications in C 10 years ago. It got ugly and hard to maintain, so I re-wrote much of it in Rust. When I tired of dealing with Rust's challenges, I turned to D. The performance of the C, Rust and D versions of the most processor-intensive application are within a few percent of each other, indistinguishable in actual use.

Electron is at least partly implemented in C++. I've tried the Atom editor, which is based on Electron, and it is annoyingly slow. Do you think not using Rust is their problem? Or maybe they got some algorithms wrong, or used badly implemented bloatware, or .... (a long list of how applications can be made to perform badly regardless of programming language).

On Wednesday, 26 October 2022 at 14:59:02 UTC, Don Allen wrote:

Browsers are generally written in C++? They use a dedicate GC for dealing with javascript objects. The renderer for Chrome called Skia is written in C++ and is gradually moving rendering to the graphics co-processor.

You cannot easily do these things with a run-of-the-mill GC as in Go, and not at all with a freeze-the-world GC.

Browsers do a lot of work in the background. A browser is basically one gigantic runtime for javascript. You don't want to deal with another heavy runtime at the same time. That would make performance tuning very difficult.

That said, I don't know how much Firefox relies on Rust. Wikipedia says that Mozilla dropped Servo (the engine that was being implemented in Rust).

You probably didn't generate much garbage. And frankly, you can easily write a well-performing basic financial application in Python without paying any attention to algorithms or memory. So I don't think this is a good use case for comparison.

Electron is just a stripped down browser with some additonal APIs. Electron applications are written in Javascript.

It is possible to make javascript applications perform well, but you need to design the software carefully and do some performance tuning.

On Wednesday, 26 October 2022 at 15:48:02 UTC, Ola Fosheim Grøstad wrote:

Opinion stated as fact. And how do you know that a freeze-the-world GC, if that were used, would be a browser's performance bottleneck, with all the network-imposed delays users experience when browsing? I speak from decades of performance-analysis experience where I found that programmers are horrible at guessing why their programs perform as they do. Which leads to the rule "Do the measurements, then we'll talk".

And how, pray tell, would the use of Go or D prevent "moving rendering to the graphics co-processor"? Which, of course, takes performance pressure off the code on running the main processor.

Interesting conclusion, based on zero knowledge of what my application does.

On Wednesday, 26 October 2022 at 17:06:33 UTC, Don Allen wrote:

This is a useless argument. Browsers support realtime applications.

On Wednesday, 26 October 2022 at 17:48:19 UTC, Ola Fosheim Grøstad wrote:

There is nothing more real time that weapons targeting and guiding systems, where a couple of ms means the wrong guys die, what is a frame dropped in a browser compared with a big hole where it wasn't supposed to be one.

US and France have several of those systems powered by bare metal Java with real time GC.

On Wednesday, 26 October 2022 at 18:33:24 UTC, Paulo Pinto wrote:

Apples and oranges.

Browser applications generate a lot of garbage, there are many things going on in the background as browsers are high level development environments. There is no way you can use a freeze-the-world GC as the primary collection mechanism and be competitive. And most likely not using Go's GC either.

Not to mention that the memory consumption nearly doubles when you start to rely on the GC.

If writing a heavy "realtime" runtime using a run-of-the-mill GC was competitive, then people would do it to save money.

On Wednesday, 26 October 2022 at 17:48:19 UTC, Ola Fosheim Grøstad wrote:

And are you aware that when and if there is a real-time requirement, you can turn off the GC?

And speaking of useless, I'm done discussing this with you.

On Wednesday, 26 October 2022 at 21:17:01 UTC, Don Allen wrote:

Turning off the GC is not an option that will work out as there is no period of time that isn't "realtime", but you can keep GC managed objects on a separate thread. That approach only makes sense if you can separate out and shield significant work suitable for GC from the other work that has to be done.

For the most part using owning pointers and arenas is a more flexible approach if you cannot use a generic GC for most of your program. Browsers do use a GC for resources that are "owned" by javascript, but the browser code then have full control over the collection strategy. That is not the case for a generic run-of-the-
mill language solution.

The moment you have to micromanage a large number of objects by pinning and unpinning them because they are leaving the GC context you might find that the benefits of using a managed solution is lost. So the overall complexity goes down with choosing something more homogeneous (like owning pointers).