The Moore’s law is in crisis. The slowdown in CPU speed increase became noticeable as we’ve approached quantum sizes for transistors, where things behave differently, e.g. tunnelling effect kicks in. There is enough written on this topic already.
While alternatives to a silicon chip are under active research, the uncertainty remains, at least for now. Relying on exponential hardware growth introduces a valid business risk now. Many businesses however are still implicitly and sometimes explicitly relying on Moore’s law.
Now there is a high probability that hardware speed is not going to be aligned with business growth for free anymore. This means that the technology and processes behind application stacks should be revisited. Wasting CPU time will hardly be justified financially anymore. For example using high level dynamic languages for everything or ignoring computation complexity when designing algorithms will cost a lot more when projected on two to four years of business operation.
The choice of a programming language already highly depends on the efficiency of the concurrency model. This is caused by the shift towards multicore architectures.
The problem is that many developers are experienced in one or many high level languages. It will not be immediately possible for them to start using a lower level language, such as C, where they have to start caring about memory safety, build internals, etc.
Fast language for everyone?
In the context of the current situation Go language is gaining popularity, while taking care of one part of the problem. It’s a very efficient compiled language with garbage collection, super simple build toolset, and easy to use concurrency model, which abstracts architecture details allowing it to scale transparently on multicore systems. Many developers are actually switching to Golang from higher level, dynamic languages.
Assisted application optimization?
The other part of the problem are applications. All the benefits of a fast language performance are easily canceled out by an exponential time algorithm, inefficient memory usage or I/O. Automatic profiling tools are needed to help developers proactively find and resolve algorithm problems. Moreover they should guide developers in what to optimize first and where exactly. Go comes with a built-in interactive performance profiling toolset pprof, which is good starting point.
At StackImpact, we’ve designed a production profiler, which automates production profiling for developers empowering them to create efficient applications. The blog post Profiling Go Applications in Production explains it in more details.