[wyager]

They're relatively straightforward procedural object-oriented languages. They're not amazing. They won't make you say "Wow, that's awesome!" when you use them.

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++.

[CJefferson]

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).

[derefr]

Go isn't a replacement for C++. You wouldn't write an entire browser in Go.

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.)

[pjmlp]

> You wouldn't write an entire browser in Go.

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.

[dobbsbob]

Here's a Go rewrite that excels in safety over it's C++ original especially when working with the raw bitcoin protocol for multi sig transactions https://github.com/conformal/btcd

[kibwen]

I dunno, for those of us who had no idea that it was possible to be provably memory-safe with zero runtime overhead, Rust is pretty amazing. :P

[pjmlp]

Really?!?

Modula-2 was created in 1978! Just to cite one memory safe systems programming language.

[jerf]

Common practice programming languages like Go are getting into the 1980s or so, research-wise. The Haskell community is into the 90s, along with some genuinely new stuff. Both have a long way to go before they're accepted common practice.

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.

[pcwalton]

> Common practice programming languages like Go are getting into the 1980s or so, research-wise. The Haskell community is into the 90s, along with some genuinely new stuff. Both have a long way to go before they're accepted common practice.

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.

[jerf]

Well, I hardly set out to show the entire range of new stuff in two paragraphs... :) But I'd also observe that Rust has a ways to go before being common practice, too. More power to you, for the love of all that's holy please put a bullet in C and C++, but even in the best case scenario you're still at least three or four years away from even being solid B-list (Perl, Python, etc... Go isn't there yet either, FWIW).

[pjmlp]

Except for those of us that were already coding in the 80s.

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.

[PeterisP]

Getting from a research compiler to "something that can actually be deployed in the harsh environment of the real world" seems to be an order of magnitude simpler and quicker than gaining a critical amount of developers and a competitive ecosystem of libraries, tools, tutorials, mindshare and ubiquitous (commoditized?) hireable employees for that language.

[pcwalton]

> Modula-2 was created in 1978! Just to cite one memory safe systems programming language.

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".)

[pjmlp]

Who mentioned GC?

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.