March 3, 2021
Hot Topics:

Opa vs. Node.js: What If Things Go Wrong?, Page 2

  • By Adam Koprowski
  • Send Email »
  • More Articles »

Opa vs. Node.js: What If Things Go Wrong?

We all know that writing the code isn't the last step -- often the "fun" begins only then with testing and debugging. Therefore, it is only fair to see how the languages compare in that respect. In fact, there are three aspects to consider here: how well the languages help detect errors, their support for debugging, and their support for testing. We will not look at testing in this article as both languages are quite comparable in that respect. We will begin by looking at debugging facilities.

In Node.js the developer writes JavaScript code both for the client and the server. In Opa on the other hand, the client-side JavaScript is automatically generated from the more concise Opa code. To debug Node.js apps, one can choose between node-inspector or the V8 debugger, which is part of Google Chrome Developer Tools in Eclipse. With Opa the situation is a bit more complicated; as of today, there's no dedicated debugger. Moreover the client code is an automatically generated JavaScript; hence, as auto-generated code goes, it is much less readable (although there are some options in the compiler to alleviate this problem somewhat).

On the other hand, Opa offers huge promises concerning error detection, thanks to its static typing (which in contrast to many statically typed languages does not require the programmer to annotate programs with types as Opa features almost complete type inference) and static analysis performed by the compiler. In principle, that means that it should be able to detect a large range of errors even before running the program. To test this in practice, we performed a range of tests both on the Node.js and Opa code. We tried inserting a number of errors that happen a lot in practice and seeing what happens.

We started with simple typos in function names. In the Node.js application, in the function presenting the number of users connected in the chat-room, we replaced length with lenght; an error I tend to make all the time. Then we re-ran the application which started as if everything was fine. The error manifested itself only when the flawed piece of code was executed -- in this case we hit it right away as the aforementioned function is called whenever a person enters or leaves the chat-room, but it's easy to imagine errors in less used functionalities, where such problems would not be triggered and observed that easily. The error itself, visible in the JavaScript debugger, basically read:

GET http://localhost:8001/join?_=1327952561187&nick=akoprowski 400 (Bad Request)

and pointed to the place where the relevant Ajax request was made. It will then still take some work and debugging experience to link this error with the typo that we introduced.

We then made equivalent error in Opa's code replacing length with lenght here. Opa would now not allow us to run such a flawed program and reported the following error (shortened here for presentation):

File "src/main.opa", line 152, characters 21-28
Expression has a record type incompatible for access to field lenght. […]
Hint: Perhaps you meant length or merge?

We then tried a similar test with user-defined data-types. We replaced text with txt in the record defining a chat message in Node.js and in Opa. The results were the same: runtime error in Node, not directly related to the problem and a clear error message in Opa.

Then we decided to see what would happen with malformed HTML, an important building block for interfaces in both languages. In Node.js in tables presenting chat message, we replaced the second closing tag with "," which resulted in a working program (modern browsers are quite good at "fixing" markup errors) but wrong presentation. We also played with some other similar markup errors, some of them leading to difficult to spot deficiencies in the output.

In Opa's example, tables are not used but when we introduced this very error to the snippet presented in the Server-/Client-side Separation and Communication section, we got a clear error message:

Hint: File "src/test.opa", line X, characters X-X
Open and close tag mismatch

We got similar compile-time errors when trying other variants of flawed HTML.

Finally, we tried playing with arithmetic errors. Both in Node.js and in Opa, there are equivalent functions computing memory usage in megabytes. Just to keep things simple, we replaced the second occurrence of the number 1024 with a string "1024." We found similar results: an undefined runtime error in Ajax call for Node.js and the following compilation error in Opa:

File "src/main.opa", line 91, characters 28-41.
Function was found of type 'a, 'a -> 'a but application expects it to be of type int, string -> 'b.
Types int and string are not compatible.

While the above error message may not be very clear for somebody who never used Opa, take our word for it -- for regular Opa users this is as clear as a day.

To sum up, we think those results are quite astounding. A large class of programming errors that goes unnoticed in Node.js and requires heavy testing and debugging is automatically detected in Opa and reported with helpful (most of the time) error messages. And we only scratched the surface, as Opa is actually capable of detecting much more involved problems than those presented and discussed here.

This should not be overlooked and is perhaps the most important feature distinguishing Opa. It also corresponds to something that Haskell programmers know for years: with a properly designed language it is possible to write "almost correct" programs at the first go and tremendously decrease time and effort spent on debugging and testing.


The growing popularity of Node.js and Opa, which unify client and server-side coding, is a clear indication that the Web of today is too complex, and the programming model needs to be refined and simplified. While Node.js is an inventive framework based on an existing, popular language (JavaScript), Opa has a lot to offer for those willing to invest time in learning a new language. I hope you will explore these languages further.

Originally published on https://www.developer.com.

Page 2 of 2

This article was originally published on February 24, 2012

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date