Distribute Application as Native Single Binary

| Comments


Some time ago I had a pleasure to implement Ruby-based tool which theoretically must be easy to install and have no or limited dependencies. I’ve picked JRuby and packed/distribute the application as a jar. I.e. JRE was the single dependency I had. In general it was very nice distribution model despite the fact that non-Java users must install JRE (Java SE Runtime Environment) to run the application.

All other approaches like Ruby, Python, Perl, etc. were not acceptable as they requires additional user’s efforts for tool installation and/or package distribution.

The idea was/is to have single native binary for all major platforms which requires no dependencies. Simply copy and run.

Now, the question: did I have other alternatives to implement this tool? Could it be implemented as native static binary? - Answer - YES. But, at that time there were only two mature solutions (acceptable for me): C and C++. And neither of them were very good for tool implementation and prototyping at the same time. Also, as far as I know, it’s not a simple task to implement really cross-platform app, at least for Windows/Linux/OSX in C/C++. It adds additional maintenance efforts which I tried to avoid.

Looking now at this task I can say that this king of application is nice to implement in Go. Go has everything I need for really cross-platform application development and single static binary output which is awesome for tools/utilities writers.

I decided to look around and understand which other popular languages support compilation/packaging to native (semi-)single static binary. The term “semi-single” static binary will be explained later.


Quick googling give us the next languages:

Haskell, OCaml and Lisp are not widely used. And these langs should be picked carefully due to language specific learning curve.

D language is not young and has small community. But it’s much simpler and clean compared to C++, IMHO.

Rust is the new hype along with Go. I guess it will be good alternative to C/C++. Also, the language is much more powerful compared to Go, it might be additional selling point.

Dynamic Languages

There is no direct compilation from interpret/dynamic language to native static binary. But, it’s possible to pack application with language runtime into “archive”/executable to behave like static native binary.

Based on the list above, Python has many alternative to accomplish single distribution artifact task. I.e. it’s better to pick Python than other alternatives. Also, it looks like Ruby has limited and poor choices, i.e. it’s not suitable for this kind of task.


IMHO, Go has the most appealing tool chain for accomplish this task.

Grails 2.x Best Practices Collection

| Comments

Recently, I had a pleasure to look into several Grails v.2.3+ projects. Despite the fact that I’m not a Grails developer I discovered some anti-patterns. Then I started looking around to find some Grails projects best practices. And they are well known and people still doing mistakes. However, I’ve found several nice resources and I’m (going to quate) quoting them here. I keep references back to original source and use “copy-paste” approach to have aggregated post in single place.



Interesting Grails people http://www.anyware.co.uk/2005/2011/09/12/optimising-your-application-with-grails-resources-plugin/ http://www.bobbywarner.com/