5 ms·

Looks interesting, from skimming the docs. Only a few obvious downsides/open questions to me: * License prohibits making closed-source things in it. * How ef

Looks interesting, from skimming the docs. Only a few obvious downsides/open questions to me: * License prohibits making closed-source things in it. * How efficient is the generated client-side code? Language mismatch is a major cause of slow generated code (see GWT). In Opa's case, having no arrays (only linked lists) sounds like a disaster for compiling to JS. * I've never seen the model work before where you "don't even need to think about what's running on the client or server." I like features like sharing code (same language) and easy transport (serializable data structures), but frameworks that blur the client/server distinction usually download all of your code, or none of it, or little snippets on demand, or some other strategy that's worse than a manual distinction. * What's development like? Do you really have to recompile your app after every change? My favorite frameworks just let you change the code and reload the web page. * I've seen many, and even written one, tutorial that goes: "Making a chat room in a web browser is hard. But here's a demo that does it in 20 lines!" With all the frameworks and libraries out there these days, it's not that hard. * Tons of dependencies (a personal gripe). Coming from the Java world, where lots of things like reading images are built-in, it's comical to see that Opa requires Java, AND libjpeg and a dozen other things (it doesn't actually run on the JVM I don't think).

hbbio 15y ago
Partial answers/tidbits: The JS code is not as optimized as what you can write manually, although a lot of work was put in making it work "fast enough" (thanks Mathieu). However, we have many ideas on how to reach native performance. Look for instance at how Java got sometimes even faster than C! There are hints @server and @client to specify a side for running a bit of your code. Since, as you say, there are things you know and the machine doesn't. Opa being a compiler, updated projects have to be recompiled. You gain a lot in quality, consistency with this (especially associated to the very advanced type system of Opa). And as we know that compilers are annoying, we made our best to make the compile time short. You probably won't have to take a coffee, sorry. The chat example does not rely on predefined libraries -- that's the difference. You can also look at bigger chat applications like https://github.com/hbbio/OpaChat https://github.com/hbbio/OpaChat and compare with https://github.com/ry/node_chat https://github.com/ry/node_chat. Opa requires Java for building from source - if the package does, that's something you can report at https://github.com/mlstate/opalang/issues?sort=created&direction=desc&state=open https://github.com/mlstate/opalang/issues?sort=created&d...
- Groxx 15y ago
  >Look for instance at how Java got sometimes even faster than C! I don't think browsers are going to let you build a hot-spot compiler in Javascript. Nor do I think that an online, optimizing interpreter in javascript stands much of a chance of improving performance.
  - Yoric 15y ago
    Certainly. However, in many cases, the high-level information that Opa has can be used to produce highly-efficient JavaScript code and/or highly-efficient distribution layout, that would be quite hard, time-consuming and error-prone to replicate by hand. On the JavaScript side, this is already the case e.g. for our implementation of pattern-matching or tail-recursive functions. We have numerous additional such ideas that we have not found time to implement. And then, if NaCl/NativeClient becomes mainstream, that's yet another avenue worth exploring.
    - dgreensp 15y ago
      There are ways this story fails in practice, like the "language mismatch" I mentioned. For example, in Google Web Toolkit, which compiles Java to JavaScript, theoretically the static type information should be a huge boon to optimization. And indeed, the compiler does some fancy stuff, including static inlining, and segmenting the code so that chunk 2 is only downloaded when a method call crosses the boundary of chunk 1. However, consider something like a HashMap. A JavaScript programmer might use a single JS object as a hash, whereas the GWT programmer has the luxury of using a java.util.HashMap, which is theoretically compiled down to something efficient, maybe just as efficient. In practice, this is hard or impossible for the compiler, and HashMaps are compiled to a system of objects that's much more complex. There are great reasons for this -- primarily, HashMaps can have any object as a key, not just a string; also the nature of the HashMap API and behavior under subclassing -- but the result is if you want something fast, you need to use a FastStringMap or some such class, backed by a "native" JS object. But in general, when you're not worrying about performance, you might find yourself using many HashMaps, even parsing JSON into nested HashMaps! So now each JS object is represented by a bunch of JS objects needed to make the mechanics of the HashMap abstraction work. I worry that not having arrays leads to a similar problem. In magic happy land, a call like List.pop that removes the last element of a list would be implemented as a tail-recursive operation on heads and tails, which the compile would then recognize and turn back into a call to Array.pop! In practice, this kind of thing is unlikely. As with HashMaps, the programmer is forced (or told) to use heavyweight data structures to simulate lightweight ones, with the hope that the compiler will recognize that this is a case where the lightweight structure applies and transform it back! As for "online" compilation, I guess this is easier on the JVM. Clojure, Rhino, Scala, and Java are all compiled and can be set up to recompile on the fly after every change to the program. Node.js too. Having developed this way, I don't think I could go back to having to do anything after changing the code besides reloading the page.
Yoric 15y ago
I've never seen the model work before where you "don't even need to think about what's running on the client or server." I like features like sharing code (same language) and easy transport (serializable data structures), but frameworks that blur the client/server distinction usually download all of your code, or none of it, or little snippets on demand, or some other strategy that's worse than a manual distinction. There are two things here. For prototyping, Opa will automatically decide what goes to the client and what goes to the server. We are very much aware that this may not yield the best performance. So, when you move from prototyping to optimization, using your knowledge of the application security policy, you can add security hints that the compiler will use to optimize client-server placement, knowing that this does not break the policy. And finally, if you want even better control, you can annotate any piece of code to instruct the compiler to place it on the client, or on the server, or both. In any case, the compiler will inform you if the set of constraints you put has no solution. Tons of dependencies (a personal gripe). Coming from the Java world, where lots of things like reading images are built-in, it's comical to see that Opa requires Java, AND libjpeg and a dozen other things (it doesn't actually run on the JVM I don't think). I concur that the dependencies are a (minor) annoyance. Just one point: Java is used only to build Opa from source. More precisely, during Opa compilation, we run the (very nice) Java-based Google Closure Compiler as a measure of the quality of our JavaScript libraries. If I recall correctly, that build step is optional, too.

hbbio 15y ago

Partial answers/tidbits: The JS code is not as optimized as what you can write manually, although a lot of work was put in making it work "fast enough" (thanks Mathieu). However, we have many ideas on how to reach native performance. Look for instance at how Java got sometimes even faster than C! There are hints @server and @client to specify a side for running a bit of your code. Since, as you say, there are things you know and the machine doesn't. Opa being a compiler, updated projects have to be recompiled. You gain a lot in quality, consistency with this (especially associated to the very advanced type system of Opa). And as we know that compilers are annoying, we made our best to make the compile time short. You probably won't have to take a coffee, sorry. The chat example does not rely on predefined libraries -- that's the difference. You can also look at bigger chat applications like https://github.com/hbbio/OpaChat https://github.com/hbbio/OpaChat and compare with https://github.com/ry/node_chat https://github.com/ry/node_chat. Opa requires Java for building from source - if the package does, that's something you can report at https://github.com/mlstate/opalang/issues?sort=created&direction=desc&state=open https://github.com/mlstate/opalang/issues?sort=created&d...

Groxx 15y ago
>Look for instance at how Java got sometimes even faster than C! I don't think browsers are going to let you build a hot-spot compiler in Javascript. Nor do I think that an online, optimizing interpreter in javascript stands much of a chance of improving performance.
- Yoric 15y ago
  Certainly. However, in many cases, the high-level information that Opa has can be used to produce highly-efficient JavaScript code and/or highly-efficient distribution layout, that would be quite hard, time-consuming and error-prone to replicate by hand. On the JavaScript side, this is already the case e.g. for our implementation of pattern-matching or tail-recursive functions. We have numerous additional such ideas that we have not found time to implement. And then, if NaCl/NativeClient becomes mainstream, that's yet another avenue worth exploring.
  - dgreensp 15y ago
    There are ways this story fails in practice, like the "language mismatch" I mentioned. For example, in Google Web Toolkit, which compiles Java to JavaScript, theoretically the static type information should be a huge boon to optimization. And indeed, the compiler does some fancy stuff, including static inlining, and segmenting the code so that chunk 2 is only downloaded when a method call crosses the boundary of chunk 1. However, consider something like a HashMap. A JavaScript programmer might use a single JS object as a hash, whereas the GWT programmer has the luxury of using a java.util.HashMap, which is theoretically compiled down to something efficient, maybe just as efficient. In practice, this is hard or impossible for the compiler, and HashMaps are compiled to a system of objects that's much more complex. There are great reasons for this -- primarily, HashMaps can have any object as a key, not just a string; also the nature of the HashMap API and behavior under subclassing -- but the result is if you want something fast, you need to use a FastStringMap or some such class, backed by a "native" JS object. But in general, when you're not worrying about performance, you might find yourself using many HashMaps, even parsing JSON into nested HashMaps! So now each JS object is represented by a bunch of JS objects needed to make the mechanics of the HashMap abstraction work. I worry that not having arrays leads to a similar problem. In magic happy land, a call like List.pop that removes the last element of a list would be implemented as a tail-recursive operation on heads and tails, which the compile would then recognize and turn back into a call to Array.pop! In practice, this kind of thing is unlikely. As with HashMaps, the programmer is forced (or told) to use heavyweight data structures to simulate lightweight ones, with the hope that the compiler will recognize that this is a case where the lightweight structure applies and transform it back! As for "online" compilation, I guess this is easier on the JVM. Clojure, Rhino, Scala, and Java are all compiled and can be set up to recompile on the fly after every change to the program. Node.js too. Having developed this way, I don't think I could go back to having to do anything after changing the code besides reloading the page.

Yoric 15y ago

I've never seen the model work before where you "don't even need to think about what's running on the client or server." I like features like sharing code (same language) and easy transport (serializable data structures), but frameworks that blur the client/server distinction usually download all of your code, or none of it, or little snippets on demand, or some other strategy that's worse than a manual distinction. There are two things here. For prototyping, Opa will automatically decide what goes to the client and what goes to the server. We are very much aware that this may not yield the best performance. So, when you move from prototyping to optimization, using your knowledge of the application security policy, you can add security hints that the compiler will use to optimize client-server placement, knowing that this does not break the policy. And finally, if you want even better control, you can annotate any piece of code to instruct the compiler to place it on the client, or on the server, or both. In any case, the compiler will inform you if the set of constraints you put has no solution. Tons of dependencies (a personal gripe). Coming from the Java world, where lots of things like reading images are built-in, it's comical to see that Opa requires Java, AND libjpeg and a dozen other things (it doesn't actually run on the JVM I don't think). I concur that the dependencies are a (minor) annoyance. Just one point: Java is used only to build Opa from source. More precisely, during Opa compilation, we run the (very nice) Java-based Google Closure Compiler as a measure of the quality of our JavaScript libraries. If I recall correctly, that build step is optional, too.