Over at Accelerating Future, Michael Anissimov is worried about what we might call a hard nano-takeoff:

The first nanofactories will be both impressive (in their exponential qualities and complete automation of manufacturing) and unimpressive (their chemical inflexibility, possible cooling requirements, electricity consumption, limited initial design space, etc.) I predict they will be revolutionary enough that the first model may also be one of the most widely distributed. Unless there are serious restrictions on nanofactory self-replication, a near-exponential flood of nanofactories and nanoproducts will follow, flowing from the first system to cross that adoption tipping point.

I beg to differ. The first nanofactories will probably be DNA/RNA/protein gadgets requiring thousands of steps by skilled scientists to coax them to build a new gadget (which will consist only of DNA/RNA/protein), or diamondoid gadgets in high vacuum requiring thousands of steps by skilled scientists to coax them to build a new gadget (which will consist only of diamondoid), or possibly even tungsten carbide gadgets doing EDM with nanotubes, requiring thousands of steps by skilled scientists to coax them to build a new gadget (which will consist only of tungsten carbide, the nanotubes having to be supplied from outside). Early nanofactories will be cranky and experimental, expensive, require expensive inputs, be able to produce only very limited products, and be very lucky to replicate themselves before they break down.

And they won’t be able to build anything like the conquer-the-world whizbangs that Michael is worried about.

And that’s if we arbitrarily define a nanofactory as being something that’s theoretically capable of replicating itself in the first place.

Having a nanofactory will be a lot like having an ENIAC. In 1946. There’ll be no need to worry about the Internet viruses and spam for a little while. Very, very few people will have the skill to get anything useful out of it at all. Think first generation, second generation, etc. computers — decades of development. It’s easy for software people to forget just how hard it is to make things work in the real, physical world. Rates of development in computers — the Moore’s Law curve — have been ten times corresponding growth rates in general industrial development. When the nano/AI revolution gets going in earnest, physical-world rates may catch up, but we have to get there first.

So, expect nanofactories to go through a long series of generations of increasing speed and capabilities — and of the capabilities of their products. The people who will get down that path the fastest are very likely to be the same ones who already have nuclear weapons — the governments of the major world powers. There will be no real reason for them to upset the applecart. They already have a jaundiced eye out for others trying to steal a march with advanced technology, and their having nanotech will make that kind of watching only easier to do. Sure, in the long run, nations that are on the verge of being able to build nuclear weapons now will be likely to be able to build nanoweapons.

If you had an advanced nanofactory today, you’d be in the position of someone in 1946 being given an IBM Blue Gene with no software, and no interface beyond panel lights and console switches (i.e. you enter your program in binary). There’s a lot of work between that and a TTY command line, much less a widgets-and-windows GUI.

By the time we have working nanofactories, I opine, we’ll have fairly capable AI that will help us develop that kind of software — the product designs and manufacturing methods for them — faster and less expensively than otherwise. But consider: nanocomputers are very likely to be among the earliest products from nanotech as it develops. Which means that there will be AI in not only the nanofactories, but, wherever necessary, in the products. Which means that, by the time someone’s nano-assassin floats over on the jet stream, it’ll find smart nano-cops (already busy herding errant salmonella) waiting for it.