/dev/dump

The backstory here is that mostly I love the Go programming language. But I've been very dismayed by certain statements from some of the core Go team members about topics that have significant ramification for my concurrent application design.  Specifically, bold statements to the effect that " channels " are the way to write concurrent programs, and deemphasizing condition variables.  (In one case, there is even a proposal to remove condition variables entirely from Go2!) The Go Position Essentially, the Go team believes very strongly in a design principle that can be stated thusly: " Do not communicate by sharing memory; instead, share memory by communicating." This design principle underlies the design of channels, which behave very much like UNIX pipes, although there are some very surprising semantics associated with channels, which I have found limiting over the years.  More on that below. Certainly, if you can avoid having shared memory st

Folks who follow me may know that Go is one of my favorite programming languages.  The ethos of Go has historically been closer to that of C, but seems mostly to try to improve on the things that make C less than ideal for lots of projects. One of the challenges that Go has always had is it's very weak support for versioning, dependency management, and vendoring.  The Go team's historic promise and premise (called the Go1 Promise ) was that the latest version in any repo should always be preferred. This has a few ramifications: No breaking changes permitted in a library, or package, ever. The package should be "bug-free" at master.  (I.e. regression free.) The package should live forever. For small projects, these are noble goals, but over time it's been well demonstrated that this doesn't work. APIs just too often need to evolve (perhaps to correct earlier mistakes) in incompatible ways. Sometimes its easier to discard an older API than to up

(Congressman Duncan Hunter is my Representative in the House.  Today I sent the letter below to him through the congressional email posting service (which verifies that I'm his constituent).  A copy is here for others to read.  I encourage everyone, especially those in districts with Republican congressional representation to write a similar letter and send it to their congressman via the site at house.gov -- you can look up your own representative on the same site.) Congressman Hunter, I have read your "position" statement with respect to the administrations "Zero Tolerance" treatment towards immigration, and the separation of families seeking asylum, and I am *most* dismayed by the position you have taken. I would encourage you to start by reading the full text of the following court order, which describes the reprehensible actions taken by the administration: https://t.co/adhGO6BDJR This is not hearsay, but legal findings by a US Court. Your claim t

Over the past several weeks I've learned far more than I ever wanted to about the self publishing process.  I'm posting some of my findings here in the hopes that they may help others.  TLDR; If you're going with eBooks, and you should, consider using an author website to sell it "early", and once your book is finished publish it with Kindle Direct Publishing and Smashwords.  Keep the author website / store up even after, so you can maximize returns.  Price your eBook between $2.99 and $9.99. If you're going to go with Print, start with Amazon Kindle Direct Publishing first, unless you're only needing a small run of books printed only in the USA (in which case TheBookPatch.com looks good).  Once you're book is really done, and you're ready to branch out to see it available internationally and from other bookstores, publish it with Ingram Spark. Get and use your own ISBNs (From MyIdentifiers.com -- buy 10 at a time), and make sure you opt o

(No, this is not about GitHub or Microsoft... lol.) Back in March (just a few months ago), I signed up on Leanpub to publish the NNG Reference Manual .  I was completely in the dark about how to go about self-publishing a book, and a community member pointed me at Leanpub. Leanpub charged $99 to set up, back in March, and offered a 90% (minus 50 cents) royalty rate.  On top of it they let me choose a price from free, or $0.99 to $99.  Buyers could choose within that range.  This looked great, although I was a bit hesitant to spend the $99 since there was no way to try their platform out. Note that at this time I was not interested (and am still not interested) in their authoring tools based on Markua.  I had excellent tooling already in Asciidoctor , plus a bunch of home-grown tools (that I've since further expanded upon) to markup and layout the book, plus previewing, etc. Everything was great, and I made sales ranging from $0.99 to $20.  Not a lot of sales, but enough to

The developer crowds are swarming off of GitHub in the wake of today's announcement that Microsoft has agreed to purchase GH for $7.5B. I've already written why I think this acquisition is good for neither GitHub nor Microsoft.  I don't think it's good for anyone else either... but maybe at least it alerts us all to the dangers of having all our eggs in the same basket. At the moment my repositories will not  be moving.  The reason for this is quite simple -- while the masses race off of GitHub, desperate for another safe harbor, the panic that this has created is overwhelming alternative providers.  GitLab reported a 10X growth.  While this might be good for GitLab, its not good for people already on GitLab, as there was already quite a well understand performance concern around GitLab.com. At least in the short term, GitHub's load will decrease (at least once all the code repo exports are done), I think.  The other thing is that Microsoft has come o

So apparently Microsoft wants to buy GitHub . This is a huge mistake for both companies, and would be tragic for pretty much everyone involved. GitHub has become the open source hosting site for code, and for a number of companies, it also hosts private repositories.  It's the place to be if you want your code to be found and used by other developers, and frankly, its so much of a de facto  standard for this purpose that many tools and services work better with GitHub. GitHub was founded on the back of Git, which was invented by Linus Torvalds to solve source code management woes for the Linux kernel. (Previously the kernel used an excellent tool called BitKeeper for this job, but some missteps by the owners of BitKeeper drove the Linux team away from it.  It looks like GitHub is making similar, albeit different, commercial missteps.) Microsoft already has their own product, Visual Studio Team Services , which competes with GitHub, but which frankly appeals mostly to Micr

There seems to have been some pretty misleading data out on the Internet, indicating that " nanomsg is dead".  The main culprit here is a " postmortem " by Drew Crawford.  Unfortunately comments are apparently not working on that post according to Drew himself. The thing is this (apologies to Samuel Clemens):  "reports of the death of nanomsg have been greatly exaggerated". So it's time to set the record straight. I've been working hard on nanomsg, and the Scalability Protocols that are intrinsic to nanomsg for quite some time.  It has been generally occupied my full time paid job for approximately the past year.  I've been working on this stuff part time for longer than that. The main focus during this time has been a complete rewrite of the core library, known as  NNG .  NNG, or nanomsg-next-gen, aims to be a far superior version of nanomsg, with significant new capabilities, greatly improved reliability, scalability, extensibility,

Unless you've been living under a rock somewhere, you probably have heard about the crypto currency called "Bitcoin".  Lately its skyrocketed in "value", and a number of other currencies based on similar mathematics have also arisen.  Collectively, these are termed cryptocurrencies. The idea behind them is fairly ingenious, and based upon the idea that by solving "hard" problems (in terms of mathematics), the currency can limit how many "coins" are introduced into the economy.  Both the math and the social experiment behind them is something that on paper looks really interesting. The problem is that the explosion of value has created a number of problems, and as a result I won't be accepting any of these forms of currencies for the foreseeable future. First, the market for each of these currencies is controlled by a relatively small number of individuals who own a majority of the outstanding "coins".  The problem with thi