I've read the Joel article several times before and have never found it convincing. The alternative to operator overloading for 'j *5;' is 'multiply(j,5);'. Now, if you write a binary operator* that doesn't multiply you are an idiot, but no more of an idiot than if you'd written a function called 'multiply' that doesn't multiply.

The arguments against operator overloading are as silly as the arguments against goto. Every language feature can be used for good or bad. Someone using messed up operator overloads is bound to have bullshit code elsewhere too. Usually people trying to be clever, which is a programmer bug, not a language bug.

I am using Go for a voxel based game, where the server is defined in Go and the client in C++. For me, I am able to produce three times as many algorithms a day with Go compared to C++. It is just so much simpler. When it compiles, it almost always works. Maybe I am too inexperienced with C++.

With C++11, C++ is moving closer to Go, but at the cost of getting more complicated.

The game server is designed for managing 10000 simultaneous players on one computer, and it looks like the target can be met. Simulation on my desktop computer shows 10% load (CPU, memory and communication bandwidth) for 1000 players. Of course, it can always be questioned whether a simulation is realistic, and it is difficult to predict player behavior. The size of the server and the client is currently at around 15000 lines each.

Meh. When generics are supported I will become interested in Go again. Generics are absolutely vital. Heck, Go's map is already a generic type, so obviously there is some necessity there. But we aren't allowed to create any. Right.

My client uses generics all of the place, and wouldn't be feasible without it. For the server, I didn't miss the availability of generics. At least not that I can remember.

What also annoys me to no end though is that they routinely trade run time for compile time. Great the compiler is fast, but the programs are slow (and fraggin huge). But in any real world application, the number of program executions should be far higher than the number of compiles. If execution speed is unimportant, I might just as well stick with Python.[/quote]

If that worries you, go for the gcc implementation of Go. The size of the executables are big because they are linked statically. That could be a problem if you want to make a long list of small programs. If you make a game server, or a web server, it doesn't matter. Anyway, the game server recompiles in 2.7s (core I7). The client recompiles in 9s on Linux, and twice that on Windows (using MinGW).

Not to say everything is bad about go. The concept of interfaces is very nice. Also love the defer statement. And a bunch of other stuff too. But no generics = no thanks.
[/quote]

What saves me most time of all, is the garbage collection. Yes, it degrades the performance (marginally), but when you no longer need to worry over allocation and deallocation you will become more efficient. Of course, it can't be ignored completely (for a long living application you need to have a basic understanding on what can prevent memory from being freed). GC is also a problem if you have requirements on hard real time, but so far it isn't noticeable in my load tests of the game server.

So why didn't I use Go for the client? There are still too many libraries that I need from the C world. Or at least it was that way when I started two years ago.

[attachment=10279:DynamicShadows_2012-07-28.jpeg]

The arguments against operator overloading are as silly as the arguments against goto. Every language feature can be used for good or bad. Someone using messed up operator overloads is bound to have bullshit code elsewhere too. Usually people trying to be clever, which is a programmer bug, not a language bug.

You are absolutely right, of course. But one of the differences between C++ and Go is that it is easier to make these mistakes in C++. Look in the "Beginner" section, and you will find horrible questions from new programmers that show they haven't understood the basic idea. This happens in Go also, but I think to a much lesser extent. One common problem in Go forums are C++ programmers that want to apply the same pattern they learned in C++ to Go. It looks like you understand Go faster if you haven't first learned C++ first!

The first time I used a statement as follows I felt nauseous. But it quickly passed.
[source lang="csharp"]func f() *int {
a := 10
return &a
}
[/source]

To be fair larspensjo, you can replace "Go" with pretty much any other language and your posts will still hold. The difference says more about C++ than it does Go.

Concerning the C versus C++ comparison early in this thread:
Correct me if I'm wrong, but isn't one of the reasons why C++ is superior to C because of time saved doing the programming? And that this is part of what makes OOP better?