There are other languages that could be used to write very secure browsers, but using them wouldn't necessarily be straightforward.
They do have a few practical advantages over C++. For one, they don't allow dangerous things like pointer manipulation. They both support garbage collection. Go has some nice built-in support for multithreading. Both have some nice iteration features. Useful syntactic sugar. Stuff like that.
Where C++ is basically just C with random features shoddily spot-welded on in different places, Go and Rust were designed from the ground up to be relatively very simple and straightforward. Like I said, they're not amazing; they're just better 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.)
Why not? AOS has one written in Active Oberon, which is quite similar to Go feature wise.
The main differences is that Active Oberon's SYSTEM package is more powerful than Go's unsafe and support for untraced pointers. The later can also be achieved in Go via a mix of syscalls and unsafe.
Modula-2 was created in 1978! Just to cite one memory safe systems programming language.
For as fast and as furious a pace as the world of computer programming likes to think it runs at, there is an unbelievably long line to get something from research to common practice. It's literally decades long.
Though there are some reasons for this; there's a difference between doing a research compiler and doing something that can actually be deployed in the harsh environment of the real world. Still, the world of computer programming does not advance anywhere near as quickly as it fancies itself doing.
Rust actually uses new stuff; the borrow checker builds on old ideas from Cyclone and others from the 90s, but it mixes it with some interesting research ideas of its own (using C++ destructors to get region typing at the level of individual values, not of regions) to come up with something that's actually fairly novel.
Modula-2, Turbo Pascal and Ada weren't research languages, rather well known languages, while C was mainly UNIX only one, slowly spreading alongside UNIX into the enterprise.
I think the problem is that many young developers never experienced those days and think C and C++ are the only game in town for systems programming languages.
If you opt into garbage collection for the whole program. That's not the same overhead as C++. (I know you believe that GC is faster than manual memory management, but let's sidestep that debate by defining "the same overhead" as "the same memory management practices that C++ uses, with the same tradeoffs".)
Modula-2 also uses manual memory management just like C.
So by using it, there is a whole class of C errors that are not exploitable:
- Buffer overflows
- Pointers that go astray, injure some critical data structure, only to die minutes later in another totaly unrelated place.
- Strings without null terminator
- No implicit conversions between types
- Proper enumerations
- Arrays are properly bound checked by default (unless explicitly disabled)
Still problems like memory leaks and double free exploits do prevail. However the set of possible exploits is surely smaller than C and C++ offer to hackers.
Go is just another language that ignored the last 50 years of programming language advances in order to not scare C programmers who are afraid of learning anything new.