Didn't mean to suggest that it was named after him, but rather developed by Ericsson the company, in house. The name is "deliberately ambiguous" according to someone who should know. (http://www.cs.chalmers.se/Cs/Grundutb/Kurser/ppxt/HT2007/general/languages/armstrong-erlang_history.pdf at 3.2)

Indeed the website for the language is "golang" just as ericsson is to ERlang, google is to GOlang. Seems maybe an OO corollary to erlangs functional paradigm. Will have to look deeper. I do love a new language,

I looked hard at netezza for a big project with "absurd" requirements (many 10^4 new records per second, ad hoc queryable by clients). It seemed to be the ideal solution. Nice to see it might have worked. How fast does your data grow?

I actually had this experience in my new Mazda2. It was quite scary. I was going up a steep hill and the engine revved a little higher than normal, I did a bit of gear changing (it is an auto) and the revving continued, as I pulled up to the queue of traffic at the lights at the top of the hill (with the massive truck behind me!). It was all getting out of control. What was weird was that the throttle was still responsive, depress it, the engine revved up, back off it de-revved, but back to well above idle.

I too was worried about the engine electronics, until I checked the floor mat and found it had slid up over the base of the accellerator, pulled the mat back and all was ok. All in all probably about a minute but very disturbing at the time. I can totally see the source of an accident in such an event. It really felt like an electronic issue at the time, until I realised what it actually was.

Indeed. And this has been my point about the "new technologies" for a few years (specifically in the Stock Exchange space but also more generally). These new languages and platforms have lowered the barriers to creating average, adequate systems. If you use excellent people to do good design then you can really lower the implementation and operation costs of these systems and produce excellent applications. By excellent I mean cheap and fast and good or perhaps rather a triangle of cheap, fast and good that has much shorter vertices than the traditional model which makes the overall compromise easier to bear.

BUT, and it is a huge BUT. These systems cannot survive at the edges of performance. You give up too much control to the "framework" regardless of which one it is; .NET, Java, Smalltalk, Rails, whatever. As a result you cannot approach the limits of performance of the hardware at your disposal. Stock exchanges are, by their very nature a shared resource, minimum latency problem which means that every CPU cycle you are not using doing _real_ work is someone not getting serviced as well as the next guy. It is hoped that when you do the design and implementation right, you can take this tradeoff below the threshold of caring for the participants of your market.

At the top end of these systems you have to be using haute design and implementation to cut it.

A comparison that might shed light is cars, family sedan, Ferrari, F1. The family sedan of today is a highly efficient, cheap and really very good quality implementation of a car, but it just can't compete with a Ferrari on performance and whilst a Ferrari will get close to an F1 in many aspects of performance all the extra engineering in the F1 car is designed to wring out the last iota of performance that means that no matter how good the Ferrari is, it can _never_ get any closer to the F1 car. (As a sidelight note that the failures that result from a fault in each of these types of vehicles probably correlates to what goes wrong in the system space as well, not pretty!!).

As such, any system written within the constraints of a "Consultancy/Outsourced/Managed Code" environment simply cannot be at the leading edge of performance.

It is interesting to try and compare the characteristics of a Trading System with other more traditional HPC applications for which supercomputers would ordinarily be used as well as with other high requirement problems. I recall looking at VISAs data processing throughput and on their busiest day in history (23rd of December 2006 IIRC) they processed 180 million transactions in a day), and their IT spend was phenomenal. O can't find that data just now but in the year to June 30 2009, VISA processed just under 40 billion transactions, that translates to about 1300 per second. A stock exchange is an order of magnitude more transactions than that (perhaps more depending on how you count it) and the handful of seconds you wait at the Checkout for your VISA payment to authorise is 4 orders of magnitude longer than a stock exchange requires (10 seconds compared to 1/1000 of a second). That means that a stock exchange is constrained in two dimensions by a total of 5 orders of magnitude more demanding requirements than a system as comprehensive as VISA. I have no real experience about a climate model or nuclear simulation, but I get the feeling that it is a huge dataset issue and your "release valve" is that whilst execution time is ideally to be reduced, the simulation takes as long as it takes and you wait until it is done. CErtainly more Gigaflops than a Stock Excahnge but not as demanding in terms of the number or rigour of the contraints under which you must operate.

To make that work, you kinda need to be down at the metal.

To make sure that you also make it work 100% of the time you need to be bloody careful.

All in all it's a funky, funky problem and we haven't even got into the hard/interesting stuff about trading more complex products than the simple equities that we are talking about for LSE and their direct competitors. And these products require another dimension of constraints where the number of shared resources increase and the systems must process "many" of the transactions of these underlying equity markets and then provide the same performance metrics to their own customers.

Control over your algorithms is not just important it's mandatory. The frameworks that work so well in many environments just don't cut it under that set of constraints

Which is why whenever a client asks that exact question about how distance affects the "customer experience" of my sub millisecond trading system, I tell them - move closer. Not only is it a serious answer, but almost all the serious performance exchanges are offering co-location services to get the client systems on the same LAN yet alone on the same backplane.

IIRC correctly there are event some patents about co-locating the client algorithm inside the exchange trading system itself (broadly speaking). Although I am certain that if my recollection is correct then there is no formal implementation of this idea. It's something I have toyed with myself for a number of years. Kinda funky. If you can manage the risk of a rogue client, it's a trader's nirvana.