|
|
|
|
|
|
by CJefferson
4479 days ago
|
|
|
Saying that Rust and Go are better than C++ seems like an extreme stretch, when Rust isn't even finished yet and is changing significantly on a week-by-week basis and the go compiler is still written in C and every benchmark I have seen puts Go at 2x to 5x slower than C++. I have high hopes for Rust in the future, but Go just does not seem like a replacement for C++ in the places where it excels (although many people do use C++ in places where they could probably have used say python, and Go is a reasonable alternative to Python). |
|
|
Instead, I think, you'd write a bunch of fast browser component libraries in C (which is what already happens now), and then glue them together in Go to produce a nice, static, easily-deployed binary for each platform.
You know how in, say, games, you see people writing (needs-to-be-performant) mechanism in C, and then scripting (can-be-slower) policy in Lua? Go excels in this same niche[1] and the results from Go, unlike from Lua, can be treated (and debugged!) as native linked-in code.
I'd still rather the whole browser was written in Rust, though; those libraries that are right now written in C for performance could do with fewer crashes.
---
[1] ...if-and-when it's the policy-writer who compiles and links the binary. If FooCorp ships a game engine as a complete executable binary, and you're expected to just write policy hooks in Lua against the FooCorp's "framework", then there is an equivalent workflow for Go--you'd produce a dynamic library that the executable dlopen()s--but the result doesn't have the same sort of elegance. (You don't get to code-sign the resulting complete executable yourself, for example.)