rcb

What I love about it: 1) it's VERY fast, 2) the documentation is phenomenal, 3) the defaults are sane, and the configurable options are well thought out, 4) rock-solid stable.

It's a beautiful piece of software and I've really enjoyed using it. No regrets on the purchase. To me it was worth the $250.

I've seen two sources of memory leaks in Erlang based systems: 1) unbounded process message queues, and 2) passing binaries across process (pid) boundaries.

Many beginning erlangers run into these, and they're relatively easy to identify and correct. With a little practice, these become easy patterns to recognize and avoid.

As far as httpc, I'm unaware of that bug -- but I can say that I recently worked on a commercial product that leveraged httpc as a core component of the service, and it worked fine.

I've found that it's extraordinarily difficult for me to do my best work in a cramped open space when there is activity surrounding me. From my own experience, it seems that some % of our minds are actively processing movement or sound, even if we're not consciously aware or distracted by it.

Unless I'm bootstrapping something, or working at an ~angel seeded company, I'll refuse to work in an open space unless there is a flexible policy about working from home, where I do have my own private office.

I'll agree with what others have said: Open spaces are about saving money, but they're also a big part of the dog & pony show that tech company executives put on when courting potential investors. This is possibly more important now that most software deployments are no longer happening on accessible data centers. Beyond that, open spaces provide an easier path to scaling engineering headcount, often in a Fred Brooks-ian sort of way.

To me, more than anything these decisions speak to the engineering or C level culture established within a business. If the talent feels the need to wear noise canceling headphones to function, then there is a problem that isn't being addressed.

If a company is FORCED to implement this because they have decided to base their operations in an urban area with outrageous rent, then give the talent the flexibility to work offsite. If the management doesn't trust their people enough with that degree of autonomy, well, I guess that's a different discussion altogether.

The anti-M$ hate & paranoia that HN seems to have inherited from /. seems so beyond antiquated in this day and age.

On topic: This is great news. Congratulations to MS.

And, why are "fun" and "joy" terms ruby bloggers use for languages? Is this code for "easy" and "familiar?" As in, "this language is easy to learn.. It does not require us to learn difficult but mind-expanding concepts to become proficient."

Replacing ruby/rails with something (just about anything!) results in far fewer servers. Isn't this obvious to all? Is this really news to the average HN reader?

If that's an I/O bound API server, bet those two servers could be brought to one in a language/runtime that's more productive but a little less "fun" to learn.

Erlang: [I+9 || I <- lists:seq(1,5), I >= 3] Haskell: [i+9 | i <- [1..5], i >= 3]

Like go, both Erlang and Haskell both have strong concurrency stories. For an I/O bound server in a production environment, Erlang is a very safe choice.

Compared to these list comprehensions, that ruby example looks unwieldy.

Edit: US carriers, specifically AT&T.

Six months after purchasing my phone, AT&T still hadn't enabled visual voicemail, and numerous WP fixes (including several security patches) were never made available to my device. I'll blame AT&T for that, as well.

I was so disgusted by the experience that I went back to iOS, spending nearly $1300 on two mobile phones over a period of six months.

WP is a fantastic operating system, and for many reasons I do prefer it over iOS. What I did not like was the third and fourth tier app ecosystem, AT&T's interference with service upgrades and patches, and how MS sold me hardware when they knew it essentially would be EOLed with their WP8 announcement.

It's a fast dual-head box. One screen is all Windows (and I'm typing this from IE 10), and the other is xmonad and emacs on Arch Linux on VirtualBox.

I'm also an Apple user (and AAPL shareholder), owning two (2010 and 2011 model) MBPs, and it is my opinion that Windows 8 is gorgeous and very, very stable. Microsoft has finally simplified the desktop experience, with sane security defaults, and in my opinion are very close if not at par with Mountain Lion on ease of use and attention to detail.

Finally, the system's performance as a desktop machine is at least %25 better than Unity/Gnome 3/KDE, and the overall fit and finish is years ahead of any leading open source DE. It was the Desktop Linux experience that has encouraged me to look elsewhere.

I'd encourage everyone to keep an open mind wrt MSFT. They're on the right track. This is not the same company I grew up hating.

The erlang distribution includes an optional static analysis tool called dialyzer, and for a little over two years I've used it consistently. Without question it has provided a significant improvement in my productivity and the quality of software I deploy. Also, the type annotations in the code (such as they are..) do help with documentation (edoc) and human understanding.

So, yeah, it's a controversial topic, but 'compile time' type validation seems to work for me. ymmv, of course!

Here are some benefits to single core erlang, off the top of my head.

* Erlang's VM is phenomenal at handling concurrent I/O even on a single core. Free epoll/kqueue backed async i/o and iovec ops.

* OTP, applications, supervision trees, state encapsulation, fault isolation, cheap GC.

* Built-in distribution, node/process monitoring, code hot-loading, mature tools and introspective capabilities on runtime state/performance.

* Some degree of "free" scale when a company is ready to deploy that app on a machine that has more cores.

I'm not sure what you mean by requires a lot of RAM up front -- compared to C/C++, yes.. but, relative to ruby, python, or the JVM? That's not been my experience.

"While we make heavy use of the core of Clojure, we don't use its concurrency primitives (atoms, refs, STM, etc.) because a function like pmap doesn't have enough fine grained control for our needs."