Golang review

Go is a new systems programming language driven by Google.

Disclaimer: All performance claims are from a combination of personal experimentation in several projects, and from the Ubuntu x64 quad-core benchmarks, which I believe to be the best indication of future performance contrasts.

The Good

• Syntax is familiar and similar to C.
• Outperforms Python by an order and a half of magnitude.
• Compiles to binary.
• Standard library is Unix/POSIX inspired and broken up into modules.
• The standard is very short, and readable.
• Use of C-like primitives allows for cheap C interfaces.
• Replaces header/source paradigm for enormous compilation speed ups.
• Provides defer, an alternative to the exception/destructors of C++, and nested-if/goto chains of C.
• Does not have assertions. Coupled with easier resource management than C (and less boilerplate than C++), this is manageable and robust.

The Bad

• Uses the := operator.
• Syntax not similar to Python. For a new language I'm not sure there is any reason to continue using C-syntax such as braces. Providing gofmt, and requiring leading braces were excellent decisions, and a large step towards whitespace formatting anyway.
• Preference for custom compiler bars adoption and integration with existing technologies.
• Limited support for Windows. Despite the pain of developing for Windows, this blocks mass adoption.
• Standard library is still evolving.
• Won't replace C in its current state. Some of the syntax and interface advances would be most welcome however.

The Ugly

• Performance is nowhere near C, or C++. The standard library is severely under-optimized.
• The LLVM toolchain was not chosen to build upon.
• Several years of tool chain development and optimization are required before Go will be a contender.
• Documentation of the toolchain is lacking.

Language Comparison

• Go is much faster and has superior concurrency to Python. Retains many of strengths of Python's typing system but without dynamic typing. Python has easier syntax, and a much better standard library implementation.
• Go has better type safety than C. It also supports interfaces, closures, containers and many modern features that C lacks. Go is garbage collected, and has safe pointers. C is much faster, and has much better platform support.
• Go is much simpler than C++, and supports many modern features that are clunky and difficult to use in C++. There is far less boilerplate. C++ is faster and has better platform support.
• Go is faster than Java, and has less boilerplate. Its compilation speed, runtime size, and similarity to C will allow it to compete with Java's claim to portability.

SC2 Free to play this Weekend, 19-21 Nov/2010

Levels of strictness

Google Heap Leak Checker Levels of strictness:

1. minimal
2. normal
3. strict
4. draconian

Sneaky use of sequence points in c++

i've found a very interesting corner case where fiddly knowledge of
sequence points and STL are used.
apparently it's not possible to use remove_if on associate arrays but
this didn't stop me trying for a good 30 mins before i discovered this
workaround:

for(; iter != endIter; )
{
           if(Some Condition)
           {
                       // is it safe ?
                   aMap.erase(iter++);
           }
           else
           {
                   ++iter;
           }
}

There's no evidence in the answer, but it's apparent after digging
through the numerous overloads and associated nastiness that its
apparently excusable simplicity comes down to sneaky use of sequence
points.

http://www.cplusplus.com/reference/algorithm/remove_if/
http://stackoverflow.com/questions/800955/remove-if-equivalent-for-stdmap/800984#800984

Silly programming errors

Here's a list of silly programming mistakes I've made recently with the appropriate line highlighted. You can clearly see from the context given that it was not intended, but you must look carefully.

This one was caught by valgrind, about 6 frames deeper as being uninitialized:

struct CpfsTime ct[2];
timespec_cpfstime(&tv[0], &ct[0]);
timespec_cpfstime(&tv[0], &ct[0]);

This one typically gives a compiler warning. However this one I found after my filesystem started gaining free space when I copied to it.

if (g_cpfs->freeblks = -1) {
    g_cpfs->freeblks = bitmap_avail_raw();
}

This one was the hardest to find. I did not even know it was the cause of the problem. In Windows there is a special form of "stat" used in their equivalent to "readdir". The erroneous file sizes would only cause errors in applications that depended on the readdir() form, such as the builtin Windows explorer and image viewer.

split_to_DWORDs(cpfsStat.size, to.nFileIndexLow, to.nFileSizeHigh);
to.nNumberOfLinks = cpfsStat.nlink;
split_to_DWORDs(cpfsStat.ino, to.nFileIndexLow, to.nFileIndexHigh);

Are these the kind of "problems" with using C, and allegedly to a lesser degree (but still present) C++? The general opinion is that these are typing errors, but languages like Python would never pick them up, and in statically typed languages the use of primitive types would still prevent any checks by the compiler.