7 cutting-edge programming experiments worth trying

Erlang, Node.js, Go: Here's how to get started with the hottest programming trends without getting burned

The words "cutting edge" may be crisp and definite, slicing through air like a knife in a bar fight. But few things strike fear in the minds of enterprise IT like the claim that a new product is built by a team working on the "cutting edge" of technology.

The problem isn't aversion to the new or being too old to change. After all, enterprise teams need all the best new ideas that come along -- even before they're completely done. But they also need all the stability and certainty that the old faithful stacks of code bring.

[ Beware the 15 workplace barriers to better code. | Find out the 9 key career issues today's developers face and the 7 biggest myths about programming. | Work smarter, not harder -- learn how with InfoWorld's roundup of tips and trends for programmers in the Developers' Survival Guide. | For quick, smart takes on the news you'll be talking about, check out InfoWorld TechBrief -- subscribe today. ]

The trick to making the most of the cutting edge is to experiment, not to jump in with both feet. Try your code where it can be most effective and see whether the cutting-edge tool offers the performance and features you need. Then check to see whether you're trading off anything essential. Experiments don't always reveal the hidden weaknesses or trade-offs immediately. So work in increments, and when your experiment is fully vetted, move to a more serious implementation.

Here are seven experiments with the "latest and greatest" worth undertaking today. None of technologies were invented last week -- in fact, some are more than two decades old. But they're attracting significant attention from the leading edge for what they can offer the modern enterprise stack today. Try them out. They're good places to begin moving beyond the trusted worlds and trying something faster, simpler, or cleaner.

Cutting-edge experiment No. 1: Erlang for clean concurrency

The cutting edge exists largely to solve problems -- to scratch an itch, as they say. The cloud exists because managing a data center is a job full of headaches. New languages like Erlang came along because the old ones weren't up to the job.

More than 20 years old, Erlang is gaining new fans because it offers effective structures for minimizing the trouble of running concurrent threads. Web servers juggling multiple users concurrently are more likely to behave correctly if they're written in Erlang because the language is designed to help programmers make the right decisions by limiting the way their programs are written. A genius could do the same thing with any language, but Erlang offers a set of safety rails in its design to keep the threads from getting as tangled. The language pushes functional design and message passing to sharing variables that need to be locked and unlocked. This makes creating an enterprise cluster that handles many users far simpler.

Erlang was developed by Ericcson for its internal telecom systems before releasing it as open source. The larger community that arose around Erlang since then now offers support tools for installing the basic runtime for most major operating systems, and there's a large collection of open source projects. Many use the OTP or Open Telecom Platform as a foundation for supplying a data service like a website, which most simple projects begin with. (See erlang.org for downloads.)

There are limits, though, to what any language can do. Many of the problems that new tools are designed to fix aren't the result of ignorance or failure; they just represent different decisions. Think "trade-offs" instead of "problems."

The cloud, for instance, may offer simplicity and flexibility, but it provides this in exchange for control and security. Erlang programmers trade some of their freedom for this new model. If your code deals with many isolated users who don't need to interact directly, it's simple to write your code in the Erlang model. But if you need your threads to communicate -- and think you have the chops to make it work -- Erlang makes your life harder.

Start small and find out whether your proposed use of Erlang is on the right side of the trade-off or the wrong one.

1 2 3 4 Page 1
Page 1 of 4