EvanMiller

The main benefits of running code in the Erlang VM are:

1. All network I/O is non-blocking, even if you write code in a blocking manner (i.e. no callback programming when writing scalable servers)

2. Erlang's processes are green threads, so you get massive concurrency for free (i.e. no cooperative thread programming when doing large-scale multi-tasking)

3. In an OTP environment, code will be executed as part of a supervision tree, so it will be very difficult to crash the interpreter (i.e. no strict need for error- and exception-handling code)

So while this interpreter will probably be quite slow for single-threaded tasks compared to the standard interpreter, there will be benefits if you want to run a lot of Lua code concurrently in a networked environment.

The alleged behavior of these companies is appalling to me. Halting an employee's application to another company is an abuse of power and amounts to theft. In my opinion the perpetrators here should do time in prison, just the same as executives who collude to fix commodity prices.

If you're looking for an Erlang web framework check out Chicago Boss. Brand new tutorial and everything:

http://www.chicagoboss.org/

Of course, the project still needs some performance work, as highlighted in this post:

http://labs.evolope.com/post/16054431816/a-comparison-of-web...

So CB is a long way from its theoretical maximum (largely because I haven't done any performance engineering on it yet).

"Performance", by the way, depends largely on the task at hand. For complex template rendering/delivery, Erlang will probably beat anything out there because of Erlang's intelligent use of immutable data and I/O lists. Most other languages do a "memcpy" for every chunk of the template as it's being built into a final string. Erlang, on the other hand, keeps around pointers to the separate pieces of memory and then does a scattered write (writev) when it's time to send the result to the client.

"In our tests, Go's performance blew away most of the competition."

Since it didn't blow away "all" of the competition, this reader is curious about which other stacks held their ground.

This reader is also curious as to why Erlang wasn't in the competition, since Erlang meets all of the stated requirements (same programming language for backend and frontend systems, fast HTML templating system, fast start-up, modular recompilation, lots of connections on one machine, language tools for handling application-level concurrency, good performance, robust RPC layer to talk between tiers, lots of libraries, and open source). I'm guessing there was an unstated requirement along the lines of "syntax is not weird".

For those of you stuck with R14B or earlier, Thomas Lindgren's smart_exceptions library will add line number information to exception backtraces: https://github.com/thomasl/smart_exceptions

It is possible they didn't use the right tool for the job.

I think this is great news. I remember the excitement of first discovering Nginx back in 2006 and realizing that the world's most popular web server (Apache) was based on inferior technology. Here was this unknown proxy server written by one guy in Russia, but inside the well-structured, completely undocumented code base was the power to serve almost all the world's web traffic. And he was always more than happy to respond to dumb questions on the mailing list and incorrect patches to his personal account.

"Going corporate" will make Nginx feel like less of a hacker's playground, but I think that's OK. Like the Linux kernel in the late Nineties, Nginx has grown up and is stable enough for huge companies to rely on for critical functionality. Now that Nginx has a marketing budget of more than $50, it will be installed on many, many more servers and generally make the web faster and more reliable for everyone. That seems like a great outcome to me.

This should be called "not-as-blocking" MySQL queries. As they say in the blog post, the calls to send and read still block, but they've made it so you don't call read until there is at least something to read. I imagine this will be an improvement over many setups.

To add to the list of truly non-blocking MySQL libraries, check out Erlang's MySQL driver: https://github.com/Eonblast/Emysql

The author emphasizes the first picture (which shows Misultin delivering 3X the throughput of a Node.js server), but I think the most interesting picture is the Response Times (picture #3). Look at the purple and yellow lines. When Node.js starts overloading at 3000 reqs/sec, the average response time drops to ~300 ms (just guessing, I'm not good at reading log graphs). But when Mochiweb starts overloading at 5000 reqs/sec, the average response time is around ~50ms.

In other words, the slowest of the Erlang servers has twice the throughput of Node.js, and handles server overload much more gracefully (at least in this contrived example).

Looks neat, but I'm not sure how useful this will be in practice. If your problem domain seems to be linear, Eureqa won't offer any advantages over linear regression. If your problem domain is non-linear, Eureqa won't be able to answer the question of where the heck the sine and cosine terms are coming from, and might induce people to make up fudgy theories to explain their origin. I'm reminded of Arthur Eddington, who explained why the fine structure "must" be 136, then when better measurements were taken explained why it "must" be 137:

http://en.wikipedia.org/wiki/A._S._Eddington#Fundamental_the...

I could see Eureqa being useful 100 years ago, when everyone was scratching their heads over the blackbody radiation data and nobody realized there was a big fat e^nu term in the denominator keeping us all from giving off infinite quantities of gamma rays. (Thanks Planck.)

Anyway, not to be a hater, but in disciplines where statistical significance is valued, Eureqa is useless, because by cherry-picking models it completely invalidates significance tests.

I do wonder whether Stack Overflow will become a victim of their own success. By providing a place to get answers from experts to technical questions, actually employing an expert is worth much less than before. In other words, Stack Overflow is turning knowledge into a commodity. This makes experts less valuable in the marketplace. It therefore makes running a job-listings page (or "elite CV service") less profitable.

Furthermore, since SO profiles are public, other job-listing companies in the market can easily leach off the reputation mechanism just by adding a "Stack Overflow profile" field.

Stack Overflow is a wonderful site, but I think their free services are a long-term threat to the profitability of their premium services. When knowledge is free, there's no reason to employ an expert.

Learn C, then decide.

1. If you like programming logic puzzles then you will enjoy programming in C. In C, everything is a number, memory address, or byte array. So every "while" loop you write is a new logic puzzle! But seriously, the things that people tend to gripe about (pointers, segfaults, etc.) won't affect you if you are good at logical reasoning and learn your way around a debugger.

2. Learning C will teach you what's going on "under the hood" and make all other programming seem easy. For some reason people like to say the JavaScript or Ruby are great "beginner's languages," but I disagree. I think you should learn to drive stick shift first and then graduate to automatic. Too many people learn automatic and then think stick shift is unnecessary. Then when their friend with a convertible gets drunk at a party, nobody can drive home, and everyone has to sleep on the floor. If you know C, you will be the hero of the party, and if something deep inside the system breaks or there's a seemingly insoluble performance problem, you'll be the guy everyone turns to.

3. I see a number of growth fronts for C programming.

A. Tablet programming. If you're not just writing Babe Alarm Clock apps and want to get the most out of limited hardware, you will want to know C. You might only write 5% of the app in C, but for critical logic paths, it can make the difference between an app that feels like a prototype and one that feels like a magic show.

B. Desktop programming. The Mac App Store will completely change the economics of desktop software development. You'll be able to get a program in people's hands (and money in your bank account) with minimal expenditures on sales or marketing. This opens up a lot of potential for innovation and the creation of new vertical markets that people didn't think existed. Microsoft will probably follow suit with an App Store before long. For desktop programming on Mac or Windows, you will want to know C because:

-- As with tablet programming, sometimes you need to write a critical logic path in C to get the responsiveness that users expect.

-- The number of open-source libraries out there is large and continues to grow. In most cases, knowing C lets you take advantage of them, even if only to write a binding for some other language. In many cases you will be able to write a great program just by slapping a pretty face onto an LGPL library or two.

-- GPU programming (OpenCL, DirectCompute, CUDA) looks to be an area of large potential growth, and as I understand it the APIs look a lot like C. For certain kinds of computations the GPU has 50X the throughput of the CPU. That's like going from a 66 MHz Compaq with a Turbo button to whatever 2GHz workhorse is sitting on your desktop right now. The ramifications for scientific computing are large; many programs designed around a "click and wait" paradigm can be rewritten to be fully interactive. There's a lot of potential for disruptive innovation here.

C. Server programming. The web still has a lot of growing to do, and fast-growing web companies need folks who know C. Most people will tell you that for web programming you just need PHP or whatever, but when the going gets tough, you're going to bust out some C. When I was on the server team at a fast-growing chat company, nominally I just needed to know PHP and Perl, but I found myself needing C in order to: 1. Fix a bug in Memcache that was horking our graphs 2. Fix up the prediction algorithms in RRDtool 3. Write a PHP extension for monitoring CPU time on Windows. I couldn't have done any of those things without knowing C. If you want to be at a company that uses the latest and greatest open-source server technology, at least somebody will need to know C when you run into the programs' problems or limitations.

D. Web programming. This is still several years off, but the Google Native Client is on the horizon:

http://en.wikipedia.org/wiki/Google_Native_Client

If it takes off, we're looking at a lot of desktop C/C++ code that will need to be adapted or rewritten to run in web browsers.

4. If you're hoping to be "very well paid" (esp. starting out at age 36) knowing C is a good strategy. First, it sets you apart from the stack of resumes touting Cocoa and jQuery knowledge. Second, knowledge of C is an excellent way to get involved in open-source and have your contributions widely used (and your coding skills validated). As a former boss of mine said, there are basically two paths to the major leagues in software development: first is to go to the right schools and get recruited into the right companies, and the second is to contribute to open-source. The most popular open-source projects are all written in C.

On a personal note, I've had to learn a dozen or so computer languages at various points and I find C to be the most satisfying. It's a difficult language compared to most, but if you know it, like it, and get good at it, you can let other people worry about bullshit like CSS workarounds and concentrate on getting the most out of a computer. Knowing C will seem completely unnecessary as you get started on any idea, but as soon as you start thinking any of these thoughts:

- "I've done everything, but it's still not fast enough" - "I've done everything, but it still eats too much RAM" - "If only I could use this library" - "If only I could use this system call" - "If only I could fix this bug"

...then if you know C, you will be the hero of your own party.

Lessons learned:

1. Adding a feature to someone else's product is a risky business model. If it's popular, the product-maker will implement your feature, at which point your goose is cooked.

2. Adding a free feature to someone else's free product isn't even risky. It is among the surest methods of losing money.

3. Know when to sell. The missed opportunity here was search. With their data and methods, Xmarks was able to improve query results for a predictable fraction of searches. At this point (2008), they should have sold to one of the up-and-coming search engines -- Windows Live or Ask.

"3. Parallel action by competitors is in itself normally quite harmless and does not subject them to liabilities."

Not sure what your sources are, but courts have ruled that parallel action can be sufficient evidence of conspiracy under Section 2 of the Sherman Act. See e.g. American Tobacco v. United States (1946), available here:

http://supreme.vlex.com/vid/american-tobacco-v-united-states...

The Supreme Court wrote:

"[The conspiracy's] existence was established, not through the presentation of a formal written agreement, but through the evidence of widespread and effective conduct on the part of petitioners in relation to their existing or potential competitors."

If I remember correctly from my anti-trust class last year, the American Tobacco precedent still stands. You don't need written or audio evidence to get a conviction; anti-competitive behavior in the marketplace is sufficient.

ErlyDTL, a Django Template Language compiler: http://github.com/evanmiller/erlydtl

Chicago Boss, an MVC web framework in progress: http://github.com/evanmiller/ChicagoBoss

This doesn't get mentioned enough, but Erlang has excellent compiler tools, so if you're willing to roll up your sleeves, you can usually hack the language to fit your problem. For instance, Chicago Boss ships with a nice but completely non-standard database querying syntax, described here:

http://www.chicagoboss.org/api-db.html

You will weep for joy when you rewrite a gnarly SQL query with a few well-chosen Unicode set operators.

The compiler tools also make it easy to generate Erlang AST and compile it to BEAM (Erlang bytecode). That's how ErlyDTL works. I haven't done performance benchmarks myself, but the folks at Zotonic report that their Django templates and controller code come out 10X faster than comparable PHP code.

I think a couple of things prevent Erlang from being a do-all language:

1. Lack of libraries. The situation has been steadily improving, but Erlang's VM and processing model makes it difficult to draw upon the "C tradition" in the same way that Perl, Ruby, and the others can take a popular C library and write a thin wrapper around it.

2. Inferior OS integration, at least with UNIX. For instance, custom signal-handling facilities are non-existent, and you have to jump through strange hoops to do simple stuff like close only the write end of a read-write pipe, or get the exit code of an exec'd process. Weak sauce for anyone who has spent a lot of time with Perl, Ruby, or C.