Walter: The Go Programming Language, or: Why all C-like languages except one suck

Do you have an actual, y'know, proof of that "hundreds of times more overhead" assertion? It's the sort of statement that cries out "citation needed!" Especially when it's apparent you haven't heard of incremental tracing collectors...

Garbage collection doesn't impinge on that, as far as I can tell. If your GC routine exploits unused CPU cycles (after all guarantees have been met) then the the guarantees continue to be met. If the GC needs more than that, then either your upper limit on Y goes down or your interval Z goes up. In either case, the guarantees continue to be met.

High-performance computing is another matter. There, you want to minimize overheads where at all humanly possible. GC is still possible, but you want it kept to a minimum or you want it offloaded. (Since the mapping to the location in RAM is done by the MMU, there's nothing to stop anyone designing an MMU with a complete VM implementation plus GC.)

Highly-performing real-time (ie: where the sum total of Ys for user processes is as close to Z as the scheduling overheads permit) is also a case where you'd really want to offload GC if possible. Problem there is that this kind of real-time is generally where power and complexity considerations are critical. Novel hardware is exactly what you don't want in those situations. Taking a few months out for extra software validation is cheaper than replacing an aircraft lost to over-complex avionics. As Airbus has demonstrated.

And if you really need better than 10 microsecond response time, this is a real problem. Of course, so are pagetables. Better get rid of those!

I'm a little skeptical about this "knows what he is doing" part...

(If memory management takes >50% of my thinking time about the problem (well, not even the problem... about the solution, really), just to make sure "I know what I am doing", then I won't touch a language with explicit memory management with a 10-foot pole.)

'auto' was already a keyword (that no one uses anymore), so no code could have been using it as an identifier.

Also, a reflection system that isn't extensible at runtime has serious problems. Yes, my framework needs to know what properties and methods a class has. It also needs a ton of other metadata, like serialization attributes (which properties should or should not be serializable), inter-dependencies for components in a composited object system, etc.

If I have to build those separately anyway then there's not necessarily a huge draw to building half of it into the language or half of it into some external tool. I need _flexibility_ rather than built-in paradigms, which is what makes C++ so superior to every last other language in common usage today for large-scale complex projects like the ones I work on. For whatever parts of C++ that get "fixed" by the numerous replacements that have sprung up there is always some major necessary strength of C++ that is lost.

The failings of C++ are less about it lacking things like a full reflection system and more that it's lacking a few low-level tools to make building a reflection system in a library possible, hence requiring pre-processors like xrtti. Add those few low-level features and build a default general-case reflection system in the STL for those who can deal with general-case performance is what C++ needs. This largely what the C++ committee focuses on, thankfully. Thinks like r-value references aren't features you're expected to use in every day code, but they can make implementing certain framework/platform/library features significantly easier or just allow them to be significantly more efficient.

But shortcutting logical expressions *cannot* be commutative, since the evaluation of the right side is conditional on the value of the left. This is true for many languages other than Python, and is desirable. Programmers simply have to be aware of shortcutting, and not expect logical operators to act like union or intersection operators.

That also says that tabs are only good for leading whitespace up to the current indentation level, and never anywhere else.

I've seen far too much tab-scrambled code (usually code that's crossed multiple team boundaries) to ever thing that hard tabs can be made to work properly. Maybe it's because I work in an engineering shop, where software is usually incidental to the product, not the primary output of the team.

In the specific case of Go, though, it appears that many of these issues are moot. It appears reading through the Go site that 'gofmt' can output tabs or spaces. Furthermore, it appears that Go's architects would have you run your code through 'gofmt' at every available opportunity, to keep the "programmatically mandated format for all Go programs" enforced. After all, they say, "Go is a new language and gofmt's style is as good as any other." Not sure I agree...

Go does have some other features that enforce a certain style even if you don't use gofmt. I am thinking in particular of the automatic semicolon insertion rules. This means you have to put curly braces on the same line as a conditional or loop, and that multi-line array or struct initializers require trailing commas, even on the last element. For example, this is the required style:

a := []int{
0,
1,
}

Leaving off the comma after the 1 is not valid.

I think what Go offers that GNU Indent does not is full backing and support from the people who designed and implemented the language. Their desire is to try and make gofmt work for all programs. I'm on the fence about how well that might work out after the number of programs written in Go gets sufficiently large.