> It's not like there are tons of practical language options for memory-safe high-performance code, and there were essentially none when many such projects started.
Chromium started in 2008, at which point there were plenty of mature cross-platform high-performance memory-safe languages that would have been suitable (e.g. OCaml or Haskell).
I am genuinely curious about this, do you really think Haskell has performance characteristics that are suitable for implementing Chromium? Haskell is wonderful for many uses, but it is difficult for me to imagine it as the basis for a modern web browser.
I will concede that a branch of GHC being utilized specifically for such a task could have been modified enough in the intervening years to enable a viable browser by 2020. But I really don’t know if it could be done with standard GHC.
> I am genuinely curious about this, do you really think Haskell has performance characteristics that are suitable for implementing Chromium? Haskell is wonderful for many uses, but it is difficult for me to imagine it as the basis for a modern web browser.
Short answer: yes. Long answer: profiling and diagnosing performance issues is still kind of a black art, but for large codebases I've seen Haskell rewrites outperform C++ significantly. You need talented Haskell developers, but surely Google should be able to find those. Most of the tasks that I can think of in a web browser seem like things that Haskell is ideally suited to - parsing, data transformation, rule-based logic - what is it that makes you think it would be unsuitable?
The memory consumption, especially the semi-non-determinism relating to lazy evaluation, was the first thing that popped into my mind. But, as I said in a comment below this, I think that Haskell as the common case language, with some FFI accessible code would probably fit the bill. I can not think of any large Haskell projects in the application space where browsers sit, but it doesn’t mean it couldn’t be done.
Chromium took parts from WebKit, but e.g. the whole JavaScript engine was completely new. Even if they needed to depend on some libraries written in C++, that doesn't justify writing the whole application in that language. And once they forked WebCore as Blink they could have gradually pushed the borderline down.
I wish I had read this comment before I replied to your parent, if I had thought about a primary Haskell or OCaml implementation with FFI and then gradually shifting I might have just kept my mouth/keyboard shut.
Chromium started in 2008, at which point there were plenty of mature cross-platform high-performance memory-safe languages that would have been suitable (e.g. OCaml or Haskell).