Author of the blog post here. Some of the comments here suggest that I was probably new to Go. Not quite. I was reasonably active in the Go community (and on golang-nuts) in the first two years of Go's public life. Also, when discussions of generics were taking place informally in the mailing list, I was one of the first to have actually written at least a half-serious `proposal' for generics (you can read it at http://oneofmanyworlds.blogspot.com/2011/11/draft-2-of-propo...).
As for achieving `generic' code through static generation using an external tool, I had had considerable success with it in some earlier projects. Except that the number of types is much higher in this project, and things could not be as simply - or clearly - generated statically.
I cannot publish the code because of the client's IP involved -- not because I fear criticism; see, I was ready to face _this_ criticism :-). Those of you who read my original post in golang-nuts may have already read that, of course!
BitSets: look at math/big - not that intuitive, but what you need is probably there.
Sets: I wrote https://gist.github.com/arnehormann/6234573 while thinking about an api. It's not a regular repository because I never needed a set type myself, but it should work.
Like another commenter said, the cpu usage statistics in the Java program are most likely due to Java threads you didn't start yourself, e.g. the garbage collector. If your code involved creation and disposal of a lot of Objects, Go is at a serious disadvantage compared to the JVM. But that can be mitigated with a little effort and will probably disappear in due time.
I thought it was a really good article. I found you included some useful details both on relevant low-level technical aspects, as well as the more human-level process of development and client interaction.
After reading it, I thought it was really insightful and useful, and concluded you're clearly a good SW engineer - was surprised by the excess criticism here. Anyway, thank you for writing and publishing this.
I found it a little surprising that Java's generics are a good fit for your task. Don't you have tons of boxed ints eating lots of memory? That's what I'm struggling with a lot when I do graph processing in Java. At that point I tend to resort to C++. Or do you use fastutil?
>As for achieving `generic' code through static generation using an external tool, I had had considerable success with it in some earlier projects
Exactly. I am reminded of Rogue Wave's[1] generics before STL became part of C++. I remember achieving that effect using a paradigm of macros and code generation provided by Rogue Wave libraries. It was during mid 1990s.
What do you think about Julia? I think it would be an almost perfect choice for this project. (And I actually believe that Julia is better in almost every way than Go if you ignore libs and maturity.)
The tone of this article really rubbed me the wrong way. Railing against the language design choices made by Go isn't evidence that those choices are wrong – it's evidence that you're trying to use the wrong tool for the job. I was reading this wondering why the author thought Go would be an appropriate choice in the first place. Julia does seem like a natural choice for this – there are efficient Sets as well as BitArrays and you can use the natural notation for them.
I mostly agree but one argument for Go would be performance (at least in theory) and the lightweight and "fun" feel of the language.
BTW - how would you compare Julia to languages like Python, Ruby or Go? If you ignore the libs and maturity, is there anything about Julia that makes it relatively less suitable for, let's say, writing a web app, a web server or a desktop application?
Your multiple core usage may be from the JVM busily using those extra cores to JIT compile (and garbage collect). Once compiled, they'll be swapped in-flight into your running code.
As for achieving `generic' code through static generation using an external tool, I had had considerable success with it in some earlier projects. Except that the number of types is much higher in this project, and things could not be as simply - or clearly - generated statically.
I cannot publish the code because of the client's IP involved -- not because I fear criticism; see, I was ready to face _this_ criticism :-). Those of you who read my original post in golang-nuts may have already read that, of course!