For example, I'm running into developers and architects who are scared to death of Rails apps, but love the idea of writing new Grails apps.
From what I've seen, there is a LOT of resource overhead that goes into using the JVM to support languages such as Groovy, JRuby and Jython instead of straight Ruby or Python.
Ruby and Python can both be interpreted on just about any OS, so I don't see any "write once run anywhere" advantage... why bring the hulking JVM along with you?
Java is a much, much more mature platform, with a lot of existing class libraries that could be "dropped in" and used, than, say, Ruby or Python (or even Perl, for that matter). So for people who like using existing code, rather than writing everything themselves, Java is a huge win.
For example, recently I've been looking for something like JAXB for Python or Ruby. In the end, I ended up using JRuby just because I haven't found any mature, widely-used XML-binding libraries.
The huge advantage of writing code (in any language) for the JVM is that it's usually very easy to tap into the enormous wealth of mature Java libraries out there, if necessary.
And I don't know where you got this idea of a "hulking" JVM with a huge resource overhead. The JIT tends to produce code that is quite fast, and the core JVM is anything but huge by today's standards. It does tend to have a huge memory footprint when running, but that's because modern machines have a lot of RAM and the GC works best when it has a lot of RAM to play with. If desired, the GC can be fine-tuned to hell and back to be more conservative.
As someone else put it: "The best thing about Groovy is that I don't have to use Java. The second best thing about Groovy is that I can use Java".
An assumption that seems to be built into the question is that new projects are greenfield projects. Many organizations have made a huge investment in Java over the last decade+ and require any new project to work within the existing (internal) code ecosystem. As pointed out, there's a huge bonus in all the publicly available Java libraries (whether free/OSS or commercial), but the need to work with existing code and even as a component within an existing system is at least as important (if not more so) to large organizations.
A lot also comes down to the maturity and capability of the platform, which is to say the JVM and everything that comes with it (the entire Java ecosystem). A few examples off the top of my head:
You can plug a remote debugger into a running JVM and get all kinds of information about a running application that is simply impossible with Python, Ruby, etc. Going a step further, there's JMX, a standard way to write code so that objects can be monitored and even tweaked in a live application. Take a look at JConsole and see if you don't drool just a little (despite the ugliness of the interface).
Going even further in this direction, there's OSGi, a standard for writing highly modular code that can be deployed, started, stopped, and even upgraded in a live application. With OSGi you break a large application into many smaller "bundles" which can then be maintained (deployed, started/stopped, upgraded) separately. This is a really big deal in large applications, or any applications that need to remain running at all times.
The platform has very good support for asynchronous, reliable messaging. You get JMS as a baseline, and many excellent and powerful libraries built on it for doing complicated things with very little code (cf. Apache Camel, ServiceMix, Mule, and many others). This is another feature that's extremely valuable in larger applications or those which must run within a larger code universe.
The JVM has real (OS-level) threading, while Python et al. are very limited in this regard (notoriously so). (That being said, shared state concurrency -- threading -- is the wrong approach; cf. Erlang, Alice, Mozart/Oz, etc.)
There are numerous JVM choices beyond the standard Sun implementations, like JRockit, IBM's JVM, etc. This is a developing area with other languages -- Python has Jython, Iron Python, even PyPy and Stackless; Ruby has JRuby, Rubinius, and others -- but as good as these are they can't match the maturity found in the various JVM offerings.
All that being said, I really don't like Java the language and avoid it as much as possible. These days with all the excellent alternative languages for the JVM I don't have to. Groovy gets my vote for its accessibility and tight integration with the platform (and even the language), and because of Grails, which I sometimes like to call "Rails for grownups". I like other JVM languages better, particularly Clojure and Scala, but these aren't as accessible to the average programmer. Scala is popping up a lot lately, though, especially thanks to its high profile use at Twitter, so there's hope for interesting and truly excellent languages making it in larger environments. But that's another topic.
why bring to hulking JVM along with you?
JVM isn't bloated, nor is it slow. on the contrary, it's a lean, fast, deeply optimized VM. Unfortunately, it's optimized for static OOP languages.
Still, good compilers targeting JVM do create good performing programs. I don't know about JRuby; but Jython's goal is to be all-around faster than regular C Python, and they're getting close (it's already faster at several important use cases).
Remember that a good JIT (like those for JVM) can apply some optimizations unavailable on static C compilers, getting faster code from them isn't a pipe dream. Of course, a VM optimized for your language should be faster than a 'not-really-generic' VM like JVM; but there's the maturity issue: JVM has a lot of work done there, while JITs for Ruby and Python aren't anywhere near.
Unfortunately, there doesn't seem to be any better generic bytecode VM. Microsoft's CLI suffers from similar limitations as JVM (ironPython is much slower and heavier than JPython). The best candidate seems to be LLVM. Does anybody know why isn't there more dynamic languages over LLVM? I've seen a couple of Scheme compilers, but seem to have several problems.
Groovy is NOT an interpreted language, it is a dynamic language. The groovy compiler produces JVM bytecode that runs inside the JVM just like any other java class. In this sense, groovy is just like java, simply adding syntax to the java language that is meaningful only to developers and not to the JVM.
Developer productivity, ease and flexibility of syntax make groovy attractive to the java ecosystem - ruby or python would be as attractive if they resulted in java bytecode (see jython).
Java developers are not really scared of ruby; as a matter of fact many quickly embrace groovy or jython both close to ruby and python. What they don't care about is leaving such an amazing platform (java) for a less performant, less scalable even less used language such as ruby (for all its merits).
The big knock on RoR is that it isn't scalable and hard to deploy. By using the Java platform, you can leverage your existing infrastructure.
grails war
Produces a war file that is easily deployed on Glassfish, Jboss, etc.
Ruby and Python can both be
interpreted on just about any OS, so I
don't see any "write once run
anywhere" advantage... why bring the
hulking JVM along with you?
Mostly because you want to take advantage of the HUGE existing ecosystem of Java libraries, APIs and products, which dwarfs anything available for Ruby or Python, especially in the enterprise domain.
Also, keep in mind that JRuby and Jython are faster in a lot of benchmarks than the regular (C implementations) of the languages, especially Ruby (even Ruby 1.9).
Having multiple languages targeting the same virtual machine has a lot of benefits, such as leveraging a common infrastructure, code reuse, shared APIs, the ability to use whatever language is conceptually best for you, or for a specific problem domain, etc.
The same things happens in the .NET space, with multiple languages targeting the CLR. The Parrot (vaporware) VM project also aims to the same thing, and it's a stated goal of the LLVM project too.
The reason is Hotspot.
It is an engineering tour de force.
the other reason not many mentioned is existing infrastructure related to jvm - if you already have a server running java stuff, why not use it instead of bringing in yet another platform (like rails)?
I've encountered this and also been baffled by it, and here's my theory.
Enterprise software is full of Java programmers. Like programmers of all stripes, many Java programmers are convinced that their language is the fastest, the most flexible and the easiest to use--they're not too familiar with other languages but are convinced that those who practice them must be savages and barbarians, because any enlightened person would, of course, use Java.
These people have built vast, complicated Java infrastructures: rube-goldberg machines of frameworks and auto-generated code full of byzantine inheritance structures and very, very large XML files.
So, when someone comes along and says "Hey! Let's use a C interpreted language! It's fast and has neat libraries and is much quicker for scripting and prototyping!" The Java guy is firstly like "I have to run a make file to configure this? QUEL HORREUR!" Then the reality of having to deploy and host this on servers that are running dated OSes and dated versions of Tomcat and nothing else starts to set in.
"Hey, I know! There's a java version of this interpreted language! It may break down in the fast lane on the bridge in rush-hour, and it sometimes catches on fire, but I can get Tomcat to run it. I don't have to dirty my hands with learning non-java stuff, and I can shoehorn it into the existing infrastructure! Win!"
So, is this the "right" reason for choosing a java implementation of a scripting language? Probably not. Depends on your definition of "right". But, I suspect that it's the reason they're chosen more often than snobs like me would like to believe.
Related
CodenameOne supports compiling Java code down to native iOS binaries. Does it support other JVM based languages such as Clojure or Jruby ?
Not out of the box but its indeed possible. In the past Steve ported Mirah which is a Ruby subset to run on Codename One. This was when we were using the old VM but should work with the new VM too.
A community member was also able to port Haxe a while back but I'm unsure where that ended.
The main point of contention when porting a JVM language is that Codename One doesn't support reflection and so a duck typed language implementation that generates reflective code would be "problematic".
The reason for avoiding reflection is quite simple, the code size would grow tremendously effectively negating a lot of the advantages of the smaller handcoded VM. Its also quite hard to optimize reflection code in an AOT environment so it will perform badly when compared with a JIT.
A lot of the usage of reflection can be replaced with bytecode manipulation ahead of time so the VM can work as if its standard Java code even when it isn't.
We generally like the idea of running other languages on top of Codename One and would like to help if you run into issues. The main reason we don't invest time in these things ourselves is to keep our focus in place.
I am planning to implement a template engine to my erlang project, and the most important thing is the performance. Currently I have a lot of Velocity Java template, and I want to migrate templates available to erlang.
I googled it, and found things like;
http://www.ivan.fomichev.name/2008/05/erlang-template-engine-prototype.html
erlydtl
google-ctemplate
sgte
Pure erlang implementation would be the best, but c(c++) based template engine, i.e. google-ctemplate, performs better, I would use it with erlang linked in driver.
Have no experience on this matter yet, so anyone's suggestions would be super great.
thanks
My personal favourite is erlydtl. It compiles the template to an erlang module, so there's no filesystem access or parsing time consumed when you call 'render'.
I think rebar has erlydtl support these days, so getting your templates compiled is a lot less hassle than it used to be. Just name them *.dtl and they'll get built when you run rebar compile.
It should also be fairly competitive speed wise as it's in-process (skip the IPC cost of a port program), compiled (and could be compiled to native code if you wanted to), and generates iolists which are pretty efficient.
A common statement said regarding Lua is that it doesn't come with batteries included; meaning that it lacks a lot of extra libraries.
I think there are a lot of Lua libraries out there and more are being developed all the time, but it is likely people don't know about many of them since the Lua community in general is very pragmatic about getting work done and doesn't waste a lot of time with self promotion.
So what are some great Lua libraries that more people ought to know about?
Shameless self-promotion plug: http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/
I hope you find something that's useful there.
My personal favorites are:
LuaSocket, a socket library enabling the use of internet with Lua
The Kepler suite a set of libraries for web application development in Lua.
LuaSQL and LuaSQLite for toying with DB stuff.
All this apart (or not as matter a fact) I highly recommend murgaLua for a batteries-included-but-not-bloated Lua distribution. It's crossplatform, and packs (non exhaustive list):
a binding to FLTK for developing GUI applications
LuaSQLite for sql stuff
LuaSocket
Basic encyption with slncrypt (blowfish, sha1, ...)
Decent RNG
And since the last beta release even a binding to FANN
Audio via ProteAudio
FFI via alien
...
And this whole beast packs in a measly 782kB executable.
I do not think there is the lack of "self promotion" , Lua is one of the best "glue" languages out there (if not the best), therefore allot of the code written for Lua is application specific.
For example, I´ve written a pretty extensive (networking) utility library for Lua and a pretty decent IDE, but its product specific and wont be released for general use.
http://www.intellipool.se/idedoc/
I'm coming across references to 'Grails' and 'Groovy' quite often these days.. mostly on how great a productivity booster it is as opposed to standard Java EE, or things like JSF, Struts etc.. And there's also an impressive set of case studies in support of this on their web site too. So I just thought I would explore some of it..
As I start off on this, I was curious if there was any material (link, blog, article, paper..) that explains what are the special features in Grails+Groovy (and not found elsewhere, in the Java EE world) that makes it a more productive environment to work in?
The Wikipedia Grails page provides a basic explanation:
Grails has three properties which attempt to increase productivity when compared to traditional Java web frameworks:
No XML configuration
Ready-to-use development environment
Functionality available through mixins
The first point should really be "less configuration" as a result of RoR-popularized configuration-by-convention: the framework addresses development of a certain class of applications and provides sensible defaults in that context.
The second point is also valuable: a hello world application can be both developed and deployed in a couple of grails commands. This reduces the barrier to entry, increases mind-share and makes for a more streamlined development experience compared to pure Java development.
I'll use an example from the Grails GORM page to illustrate the 3rd point. Grails allows you to write this kind of code to retrieve a book by its title from the "book" table without having to set much of anything up:
Book.findByTitle("Groovy in Action")
Of course, it's the result of a much more general property of Groovy: its dynamic nature.
For more practical productivity increase reports, see e.g. the Sky report.
A framework becomes useful when it minimize effort to do something. That's why C became more successful than Assembly, C++ improved on C, and Java on C++.
Although not strictly listed in pro and cons, I like the discussion of the subject in a blogpost by one of the early Groovy developers. Furthermore, I also like the discussion on another modern database-backed-webapplication framework by Martin Fowler, one of the leading architects in the Java EE world.
I also came across Groovy first, while testing Java applications. You will come in touch with work of Dirk Koenig, e.g.short Groovy presentation.
By the way, if you want to develop "cloud" related applications, then Ruby opens up a bunch of doors as well.
I think Erlang is very well suited for server systems developed in my workplace (currently developed in Java). I am a bit skeptical how this would be accepted both by developers (who have no idea about functional or Erlang) and by managers.
Any ideas on how to approach the issue? I am thinking about some hybrid system, where the hardcore highly reliable infra uses Elrang, and app specific stuff developed in Java (as nodes?)
There are a few approaches, and neither have any guarantees to actually work
Implement something substantial in a short time frame, perhaps using your own time. Don't tell anyone until you have something to display that works. Unless you have a colleague in on it.
Pull up lots of Erlang projects that are good demonstrations of the features you want. Present it to your managers and try to frame them about the risk in keeping using Java with this kind of technology available.
If the company you work for actually have a working code base in Java already, they're not likely to take you seriously when you suggest to rewrite it in another language.
The true test that you believe in Erlang being a much better choice: Quit and start up a competing company and bring the technology insight you have in your current industry. Your managers are really comparing a similar risk-scenario as you would do if you were to quit your job, and they are looking for the same assuring facts for success as you would do, to consider leaving a "safe" paycheck.
As for how to integrate, check out the jinterface application in Erlang. It allows Java code to send messages to Erlang nodes, and it allows Java to expose mailboxes to the Erlang nodes as if there were Erlang processes.
It's all about ROI (Return On Investment) to a manager: a manager will be concerned about performance (of the company). In order to appeal to his business nature, you'll have to make a case for it using dollar$ (or whatever appropriate currency).
Beware that undertaking a "skunkwork" project on the side to "prove" your solution based on Erlang might backfire: "so you had time to play with Erlang, why didn't you spend the time on the project then?" (Of course, not all managers/companies would think this way).
You have to take into account the whole proposal e.g. impact on the team, skills to be developed etc. It's all about money.
If I have an advice for you: start small, plant a seed, nurture it and watch it grow.
A wise man once said to me:
"It's not about technology, it's about
the product & market".
Start by not targetting a rewrite but using erlang for a new feature/project. Rewrites can be expensive and taking a chance on erlang for something that is already a time consuming and costly undertaking is a hard sell. But if there is a new piece that could be done in erlang and java, you stand a better chance. The project will be small enough hopefully that you can discover early if erlang is a good fit and adapt accordingly. And when erlang proves itself in that project you will have better data to make your case with.
We're introducing RabbitMQ into our infrastructure, which currently runs a combination of C++, Java and Python applications. I'm not specifically intending to move the team towards Erlang, but if I were, introducing a well-written third-party tool that just happens to use Erlang is a very good way to get the foot in the door.
One major caveat is that while Erlang is a wonderful language to learn, the surrounding technology (OTP in particular) has a huge learning curve and is extremely primitive in many ways (debugging, IDE's, etc.). It is getting better all the time, but reluctant converts will crucify you if you don't warn them about the pain of learning to program in a radically different environment. Even simple things like the lack of code-sense technology (E.g., type 'foo.' and the IDE tells you what methods you can call on foo) can leave a really bad taste in the mouth.