4 ms·

I am curious on the language choice of Go. Why not C or C++? Apologies if this was already answered.

dymk 7y ago
Managing memory is a pain and dangerous, doubly so when your objects form a graph (std::shared_ptr forsakes you), and Go's GC is quite performant. It's a database, so it's mostly I/O, and not CPU bound. Databases also do lots of stuff concurrently, which is easy in Go, and a pain to do correctly in C/C++. There's also prior art for databases built in Go as well, such as CockroachDB.
mrjn 7y ago
I'd love to talk about this at length. Having built distributed systems in Google Web Search with C++ for over 6 years, I still enjoy the manual memory management model than a GC based model. Identifying and fixing memory leaks is easier, because that's in your control as a language user. Making a GC work better is beyond. In fact, that'd be the biggest gripe I have with Go. Wish Go had a manual memory control mode, I'd take it in a heartbeat. Alright, now that I've criticized Go, time for why I chose it. Go code is simply more manageable and readable over time. Tools like gofmt are habit forming. Go does memory management, but doesn't put everything on heap. You still get a lot of control over pointers, something that other GC based langs hide from the user. Go tooling is the best I've seen and closely replicates what we had at Google. Go profiles are almost copies of what Google had and the fact is that they're part of the language is incredible. Go allows normal devs to run thousands of goroutines, utilizing all possible cores of the server well. That is just not possible with other languages. And not as simple with C++. Go is a DELIGHT to work with as a programming language. If Go weren't around, I'd be writing Dgraph in C++. Go is perhaps slightly slower on a per-thread basis, but it more than makes up for it with easy to build concurrent systems. In fact, both Dgraph and Badger outperform many other systems written in C++ and Java. So, you only gain performance with Go. What you do lose is ability to tightly control memory deallocation, but that's just GC for you. P.S. If you want to shout Rust: Sorry, I just don't know much about it. And don't plan to switch.
- peternicky 7y ago
  Thank you for this reply, very informative and personally, I love hearing about design decisions and tool choices.

dymk 7y ago

Managing memory is a pain and dangerous, doubly so when your objects form a graph (std::shared_ptr forsakes you), and Go's GC is quite performant. It's a database, so it's mostly I/O, and not CPU bound. Databases also do lots of stuff concurrently, which is easy in Go, and a pain to do correctly in C/C++. There's also prior art for databases built in Go as well, such as CockroachDB.

mrjn 7y ago

I'd love to talk about this at length. Having built distributed systems in Google Web Search with C++ for over 6 years, I still enjoy the manual memory management model than a GC based model. Identifying and fixing memory leaks is easier, because that's in your control as a language user. Making a GC work better is beyond. In fact, that'd be the biggest gripe I have with Go. Wish Go had a manual memory control mode, I'd take it in a heartbeat. Alright, now that I've criticized Go, time for why I chose it. Go code is simply more manageable and readable over time. Tools like gofmt are habit forming. Go does memory management, but doesn't put everything on heap. You still get a lot of control over pointers, something that other GC based langs hide from the user. Go tooling is the best I've seen and closely replicates what we had at Google. Go profiles are almost copies of what Google had and the fact is that they're part of the language is incredible. Go allows normal devs to run thousands of goroutines, utilizing all possible cores of the server well. That is just not possible with other languages. And not as simple with C++. Go is a DELIGHT to work with as a programming language. If Go weren't around, I'd be writing Dgraph in C++. Go is perhaps slightly slower on a per-thread basis, but it more than makes up for it with easy to build concurrent systems. In fact, both Dgraph and Badger outperform many other systems written in C++ and Java. So, you only gain performance with Go. What you do lose is ability to tightly control memory deallocation, but that's just GC for you. P.S. If you want to shout Rust: Sorry, I just don't know much about it. And don't plan to switch.

peternicky 7y ago
Thank you for this reply, very informative and personally, I love hearing about design decisions and tool choices.