This document compares and contrasts various features of C++ and Go, including: - Error handling approaches like exceptions in C++ vs explicit error checking in Go. - Class/struct definitions and how they compare between the languages. - Common data structures like vectors, maps, and how they are implemented in each language. - Benchmark results that show Go outperforming C++ in some cases but C++ performing better in others, depending on optimizations and data structure choices. - Interfacing Go with C via Cgo and the performance overhead of marshalling between the languages. - Concurrency primitives available in each language like mutexes, channels, atomics.

1. C++ vs Go

2. Go Language Evangelism

4. Language complains

5. • There is no way to centralize error handling, and you
doing it the “old good way” (check after each step):
No exceptions
defer ts.Close()
conf := newConf(ts.URL)
_, err := conf.Exchange(context.Background(), "exchange-
code")
if err == nil {
t.Fatalf("got no error, expected one")
}
_, ok := err.(*RetrieveError)
if !ok {
t.Fatalf("got %T error, expected *RetrieveError; error
was: %v", err, err)

6. •So observations are that average Go
function length might be up to 3x
longer if to correctly handle all
errors (than comparable C*/C++
code)
No exceptions
* C at least has a preprocessor

7. •"If it walks like a duck and it quacks like a
duck, then it must be a duck”
•In duck typing, an object's suitability is
determined by the presence of
certain methods and properties, rather than
the type of the object itself.
Duck Typing vs True
https://en.wikipedia.org/wiki/Duck_typing

8. type Reader struct {
r io.ReaderAt
File []*File
Comment string
decompressors map[uint16]Decompressor
}
...
func (z *Reader) init(r io.ReaderAt, size int64) error {
end, err := readDirectoryEnd(r, size)
if err != nil {
return err
}
...
}
...
func (z *Reader) RegisterDecompressor(method uint16, dcomp
Decompressor) {
if z.decompressors == nil {
z.decompressors = make(map[uint16]Decompressor)
}
z.decompressors[method] = dcomp
}
UglyClasses

9. type Reader struct {
r io.ReaderAt
File []*File
Comment string
decompressors map[uint16]Decompressor
}
...
func (z *Reader) init(r io.ReaderAt, size int64) error {
end, err := readDirectoryEnd(r, size)
if err != nil {
return err
}
...
}
...
func (z *Reader) RegisterDecompressor(method uint16, dcomp
Decompressor) {
if z.decompressors == nil {
z.decompressors = make(map[uint16]Decompressor)
}
z.decompressors[method] = dcomp
}
UglyClasses

10. MODULE Lists;
TYPE
List* = POINTER TO ListNode;
ListNode = RECORD
value : Integer;
next : List;
END;
PROCEDURE (l : List) Add* (v : Integer);
BEGIN
IF l = NIL THEN
NEW(l); (* create record instance *)
l.value := v
ELSE
l.next.Add(v) (* recursive call to .add(n) *)
END
END Add;
Oberon-2
UglyClasses

11. LL(1) grammar with C-like keywords
var prohibitionaryDialArgTests =
[]struct {
network string
address string
}{
{"tcp4", "127.0.0.1"},
{"tcp6", "::ffff:127.0.0.1"},
}
func DoProhibitionaryDialArg(t
*testing.T) (error) {
Go
const
prohibitionaryDialArgTests : array [1..2]
of record
network : string;
address : string;
end = (
(network: ‘tcp4’, address:
‘127.0.0.1’),
(network: ‘tcp6’, address: ‘::ffff:
127.0.0.1’)
);
function DoProhibitionaryDialArg(var t:
Testing.T) : TError;
Pascal
Pascal/Oberon syntax which mimics C

12. •Order of keywords in declaration
•No name overloads
• No generics
• No pointer arithmetic
• Fast compiler
• Weak optimizer
• Source modules-based build
• blahblahthousandsmoreweakanalogues
More Pascal/Oberon like…

13. Containers anyone?

14. C++ Go
std::vector<int> vector;
vector[i]
vector := []int{}
vector[i]
std::stack<int> stack; stack := []int{}
stack.push(value); stack = append(stack, value)
value = stack.top();
stack.pop()
stack, value = stack[:len(stack)-1],
stack[len(stack)-1]
std::deque<int> q{};
q.push_back(value);
q.pop_front();
import "github.com/gammazero/deque”
func (q *Deque) PushBack(elem
interface{})
func (q *Deque) PopBack()
interface{}
func (q *Deque) PopFront()
interface{}
func (q *Deque) Front() interface{}

15. C++ Go
#include <list> import "container/list”
func (l *List) PushBack(v
interface{}) *Element
func (l *List) PushFront(v
interface{}) *Element
std::list<int> l{1, 2, 3};
l.push_front(0);
l.push_back(4);
for(auto elem : l) {
std::cout << elem << 'n';
}
l := list.New()
e4 := l.PushBack(4)
e1 := l.PushFront(1)
for e := l.Front(); e != nil;
e = e.Next() {
fmt.Println(e.Value)
}
std::unordered_map<std::string, int>
map;
unorderedMap := make(map[string]int)
_, ok := unorderedMap["route"]
delete(unorderedMap, "route")
std::unordered_set<std::string> set; var m = make(map[string]struct{})
m["!"] = struct{}{}
_, ok := m["!"] // true

16. https://godbolt.org/z/xGAd12

17. https://groups.google.com/d/msg/golang-nuts/j_3n5wAZaXw/YkOdbCppAQAJ

18. https://groups.google.com/d/msg/golang-nuts/j_3n5wAZaXw/YkOdbCppAQAJ

19. Allocators?

20. ● sync.Pool
● System allocator
● custom Slab old mechanism
● inability to put your allocator down -> not
custom: string, map, ...
Allоcator GO

21. ● std:
○ allocator
○ polymorphic_allocator
● All custom
Allocator C++

22. Benchmarks!

23. C++ Go
#include <iostream>
#include <vector>
int main() {
int64_t sum = 0;
for (int e = 0; e < 200; e++) {
sum = 0;
std::vector<int64_t> x;
for (int i = 0; i < 1000000; i++) {
x.push_back(i);
}
std::vector<int64_t> y;
for (int i = 0; i < 1000000 - 1; i++) {
y.push_back(x[i] + x[i + 1]);
}
for (int i = 0; i < 1000000; i += 100) {
sum += y[i];
}
}
std::cout << sum << std::endl;
}
package main
import "fmt"
func main() {
var sum int64 = 0
for e := 0; e < 200; e++ {
sum = 0
var x []int64
for i := 0; i < 1000000; i++ {
x = append(x, int64(i))
}
var y []int64
for i := 0; i < 1000000-1; i++ {
y = append(y, x[i]+x[i+1])
}
for i := 0; i < 1000000; i += 100 {
sum += y[i]
}
}
fmt.Println(sum)
}

24. Go C++
go build bench-go.go clang++ -m64 -o bench-cpp -O3 bench-
cpp.cpp
✔ ~/go_vs_cpp
02:29 $ time ./bench-go
9999010000
real 0m1,785s
user 0m2,417s
sys 0m0,246s
✔ ~/go_vs_cpp
02:29 $ time ./bench-go
9999010000
real 0m1,809s
user 0m2,441s
sys 0m0,253s
✔ ~/go_vs_cpp
02:29 $ time ./bench-cpp
9999010000
real 0m0,868s
user 0m0,729s
sys 0m0,128s
✔ ~/go_vs_cpp
02:29 $ time ./bench-cpp
9999010000
real 0m0,875s
user 0m0,735s
sys 0m0,130s

25. Go C++
go build -gcflags=-B bench-go.go clang++ -m64 -o bench-cpp -O3 bench-
cpp.cpp
✔ ~/go_vs_cpp/I_vlxy_I
01:37 $ time ./bench-go
1999802000000
real 0m0,350s
user 0m0,504s
sys 0m0,055s
✔ ~/go_vs_cpp/I_vlxy_I
01:37 $ time ./bench-go
1999802000000
real 0m0,352s
user 0m0,510s
sys 0m0,058s
✔ ~/go_vs_cpp/I_vlxy_I
01:37 $ time ./bench-cpp
1999802000000
real 0m0,511s
user 0m0,447s
sys 0m0,014s
✔ ~/go_vs_cpp/I_vlxy_I
01:39 $ time ./bench-cpp
1999802000000
real 0m0,488s
user 0m0,425s
sys 0m0,012s

26. C++* Go*
#include <iostream>
#include <vector>
int main() {
int64_t sum = 0;
std::vector<int64_t> x;
x.reserve(1000000);
std::vector<int64_t> y;
y.reserve(1000000);
for (int e = 0; e < 200; e++) {
x.clear();
y.clear();
for (int i = 0; i < 1000000; i++) {
x.push_back(i);
}
for (int i = 0; i < 1000000 - 1; i++) {
y.push_back(x[i] + x[i + 1]);
}
for (int i = 0; i < 1000000; i += 100) {
sum += y[i];
}
}
std::cout << sum << std::endl;
return 0;
}
package main
import "fmt"
func main() {
var sum int64 = 0
var x []int64
x = make([]int64,0,1000000)
var y []int64
y = make([]int64,0,1000000)
for e :=0; e<200; e++ {
x = x[:0]
y = y[:0]
for i :=0; i < 1000000; i++ {
x = append(x, int64(i))
}
for i :=0; i< 1000000-1; i++ {
y = append(y, x[i]+x[i+1])
}
for i:=0; i<1000000; i+=100 {
sum += y[i]
}
}
fmt.Println(sum)
}

27. C++* Go*
#include <iostream>
#include <vector>
int main() {
int64_t sum = 0;
std::vector<int64_t> x;
x.reserve(1000000);
std::vector<int64_t> y;
y.reserve(1000000);
for (int e = 0; e < 200; e++) {
x.clear();
y.clear();
for (int i = 0; i < 1000000; i++) {
x.push_back(i);
}
for (int i = 0; i < 1000000 - 1; i++) {
y.push_back(x[i] + x[i + 1]);
}
for (int i = 0; i < 1000000; i += 100) {
sum += y[i];
}
}
std::cout << sum << std::endl;
return 0;
}
package main
import "fmt"
func main() {
var sum int64 = 0
var x []int64
x = make([]int64,0,1000000)
var y []int64
y = make([]int64,0,1000000)
for e :=0; e<200; e++ {
x = x[:0]
y = y[:0]
for i :=0; i < 1000000; i++ {
x = append(x, int64(i))
}
for i :=0; i< 1000000-1; i++ {
y = append(y, x[i]+x[i+1])
}
for i:=0; i<1000000; i+=100 {
sum += y[i]
}
}
fmt.Println(sum)
}

28. C++** Go*
#include <iostream>
#include <array>
std::array<int64_t, 1000000> x;
std::array<int64_t, 1000000> y;
int main()
{
int64_t sum = 0;
for (int e = 0; e < 200; e++)
{
for (int i = 0; i < 1000000; i++)
{
x[i] = i;
}
for (int i = 0; i < 1000000 - 1; i++)
{
y[i] = x[i] + x[i + 1];
}
for (int i = 0; i < 1000000; i += 100)
{
sum += y[i];
}
}
std::cout << sum << std::endl;
return 0;
}
package main
import "fmt"
func main() {
var sum int64 = 0
var x []int64
x = make([]int64,0,1000000)
var y []int64
y = make([]int64,0,1000000)
for e :=0; e<200; e++ {
x = x[:0]
y = y[:0]
for i :=0; i < 1000000; i++ {
x = append(x, int64(i))
}
for i :=0; i< 1000000-1; i++ {
y = append(y, x[i]+x[i+1])
}
for i:=0; i<1000000; i+=100 {
sum += y[i]
}
}
fmt.Println(sum)
}

29. Go C++
go build -gcflags=-B bench-go.go clang++ -m64 -o bench-cpp-array -
O3 bench-cpp-array.cpp
✔ ~/go_vs_cpp/I_vlxy_I
01:37 $ time ./bench-go
1999802000000
real 0m0,350s
user 0m0,504s
sys 0m0,055s
✔ ~/go_vs_cpp/I_vlxy_I
01:37 $ time ./bench-go
1999802000000
real 0m0,352s
user 0m0,510s
sys 0m0,058s
✔ ~/go_vs_cpp/I_vlxy_I
01:39 $ time ./bench-cpp-arrays
1999802000000
real 0m0,275s
user 0m0,256s
sys 0m0,009s
✔ ~/go_vs_cpp/I_vlxy_I
01:53 $ time ./bench-cpp-arrays
1999802000000
real 0m0,281s
user 0m0,255s
sys 0m0,012s

30. Cgo interface

31. •Very convenient way to generate Cgo
binding
•But they both use orthogonal run-time
environments
•And marshalling Go arguments to C stack is
slow as a hell
Cgo interface

32. https://www.cockroachlabs.com/blog/the-cost-and-complexity-of-cgo/
CockroachDB/cgobench

33. •Copying memory between Go and C comes
with a price
•But you could avoid it with dirty tricks
Cgo interface

34. •Copying memory between Go and C comes
with a price
•But you could avoid it with dirty tricks
Cgo interface

35. •Copying memory between Go and C comes
with a price
•But you could avoid it with dirty tricks
Cgo interface

37. •GPU
•The same as on previous slides…
Cgo interface

38. “Go is safe” they said

39. “Go is safe”
Ross Cox
“Go is defined to be a safe language. Indices into
array or string references must be in bounds; there
is no way to reinterpret the bits of one type as
another, no way to conjure a pointer out of thin air;
and there is no way to release memory, so no
chance of “dangling pointer” errors and the
associated memory corruption and instability.”
Russ Cox,"Off to the Races"

40. https://goplay.space/#ubOeLHZIgQD

41. Concurrency in GO

42. Concurrency in GO
•Primitives:
• Mutex/RWMutex
• Channel
• Atomic
•Sync.Map -> performance
•size(Goroutins) -> ?
•goroutins + threadpool
•smart wait: io, …
•memory barrier

43. Concurrency in C++
● Primitives:
○ thread
○ *Mutex
○ Atomic
○ ....
● Boost::context
● Boost::*
● C++ 20 coroutines
● memory barrier

44. Concurrency in Go
•They said Go channels will be easy
•They said it will be less error-prone
•But…

45. Concurrency bugs
https://blog.acolyer.org/2019/05/17/understanding-real-world-concurrency-bugs-in-go/

46. •And marshalling Go arguments to C stack is
slow as a hell
•goroutines not transferred between processes
•Api: Posix, windows, …
•Low-cost ipc :
• fork
• ....
Multiprocessing & NUMA in Go

47. •Api: Posix, windows, …
•Low-cost ipc :
• fork, ....
• Boost.Interprocess
• Boost.process
• Boost.*
Multiprocessing & NUMA in С++

48. Code Quality

49. • Only short and simple functions are inlined – less than 40
expressions. No function calls, loops, closures…
• Multiple cases when escape analysis gives up, e.g. any kind of
indirection (*p = …)
• Function calls, package boundaries, slice literals, subslicing and
indexing – all inhibits escape analysis
• Range assignment converted to memchr
Go optimizer limitations
https://github.com/golang/go/wiki/CompilerOptimizations

50. What about GCCGO?

51. • Which uses fully-featured GCC backend…
• And could proceed proper optimizations even
LTO…
• Looks like it’s out of sync with main Go
compiler
And nobody* uses it…
What about gccgo?

52. What about package-manager?

53. •Govendor was a pain. Looks irrelevant at the
moment
•But even then it was much better than lack
of wide-spread C++ PM.
•Vcpkg or Conan will help eventually here
•All eyes on WG21/SG15 (tooling)
Past experience with PM

54. Go package managers usage
https://www.jetbrains.com/lp/devecosystem-2019/go/

55. Package Managers in C++?
https://www.jetbrains.com/lp/devecosystem-2019/cpp/

56. Build systems in C++?

57. The History and Trends

58. ISOC++

59. Go
1.0
2009 2010 2011 2012 2013 2014 2015 2015 2017 2018
1.1 1.2 1.10
May 2013 Version 1.1 unicode code points in strings literals. 32 and 64 bit int, uint. 64-bit heap of tens of gigabytes.
December 2013 Version 1.2 10K threads. 4K > 8K stacks
June 2014 Version 1.3 no language changes
December 2014 Version 1.4 Much of runtime is in Go.
August 2015 Version 1.5 Self-hosted (in Go and assembler, without C). GC < 10millisecs.
February 2016 Version 1.6 no language changes
August 2016 Version 1.7 sse for x64. SSA-based x64 code generation.
February 2017 Version 1.8 More sse/avx instructions. GC 10..100 microsecs. Overhead deferred improved.. Overhead from Go to C improved
August 2017 Version 1.9 Type aliases in Go. Compilation of functions in parallel
February 2018 Version 1.10 359 x64 instructions supported.
August 2018 Version 1.11 no language changes.WASM. Preliminary support for modules.AVX512 in assembler.
February 2019 Version 1.12 no language changes.TLS 1.3. Improved modules.

60. Go
1.0
2009 2010 2011 2012 2013 2014 2015 2015 2017 2018
1.1 1.2 1.10
May 2013 Version 1.1 unicode code points in strings literals. 32 and 64 bit int, uint. 64-bit heap of tens of gigabytes.
December 2013 Version 1.2 10K threads. 4K > 8K stacks
August 2016 Version 1.7 sse for x64. SSA-based x64 code generation.
August 2017 Version 1.9 Type aliases in Go. Compilation of functions in parallel

61. GoSurvey2018
https://blog.golang.org/survey2018-results

62. How about management?

63. •Barrier to entry: 0-4 hours
•Time to expert: ≈3 month
Go team scalability

64. •Barrier to entry: 0-4 hours
•Time to expert: ≈3 month
•Excellent documentation
•Godoc for 3-party packages
Go team scalability

65. •Barrier to entry: 0-4 hours
•Time to expert: ≈3 month
•Excellent documentation
•Godoc for 3-party packages
•Unified codestyle
Go team scalability

66. •No unmaintainable makefiles
Cross-platform development in Go

67. // +build freebsd openbsd netbsd dragonfly
package fsnotify
import "golang.org/x/sys/unix”
const openMode = unix.O_NONBLOCK | unix.O_RDONLY
BSD kqueue
Cross-platform
// +build windows
package fsnotify
Windows watchers

68. •Own profiler (with web interface!)
•go test -bench
•Cross-platform asm
•Optimizing culture
Go simpler performance tuning

69. Salaries @ MoiKrug

70. https://habr.com/ru/company/moikrug/blog/461855/

71. https://habr.com/ru/company/moikrug/blog/461855/

72. https://habr.com/ru/company/moikrug/blog/461855/

73. https://habr.com/ru/company/moikrug/blog/464655/
Salary changes dynamics 2017-2019

74. https://habr.com/ru/company/moikrug/blog/464655/
Salary changes dynamics 2017-2019

75. https://habr.com/ru/company/moikrug/blog/464655/
Salary changes dynamics 2017-2019

76. https://habr.com/ru/company/moikrug/blog/464655/
Usage frequency changes dynamics 2017-2019

77. https://habr.com/ru/company/moikrug/blog/464655/
Usage frequency changes dynamics 2017-2019

78. Your vote?