>On the other hand, if you don't mind using other languages for the host code, there are a number of libraries in Java, Python, etc. that make it much simpler and more feature-complete than this library.
What features would you consider to be missing?
>Major problem with many of those libraries, including this one, is that, while they help you with hello world, they cripple the real-world functionality. All this low-level stuff that is there in the standard usually has its use. Of course it could and should be simpler, but most of those wrapper libraries guess too much and make many optimizations inaccessible or very hard to achieve.
Of course, though I wouldn't say cripple. With abstraction comes an associated performance cost. Chlorine is intended to reduce the barrier to entry. It's one of those "do things that don't scale" ideas. It hides some of the boilerplate from you, and is meant to help you quickly validate your ideas. If you need more fine-grained control over memory allocation, execution order, etc., you can always turn to the C/C++ API for performance, and it shouldn't be too difficult to port.
>The library that I wrote for Clojure (and Java), ClojureCL (http://clojurecl.uncomplicate.org) even supports OpenCL 2.0 (which is usually not supported in other libraries), while still allowing you all sorts of low-level performance optimizations accessible in the native C API, and is (in my opinion) rather simple to use compared to other libraries, and requires little boilerplate.
My goal is to make GPU programming more accessible, so it's always good to see competition! Anyway, Chlorine is OpenCL 1.1/1.2 only, mainly because OSX is not OpenCL 2.0 compatible (knowing Apple, it may never be).