On Nov 14, 2013, at 3:28 AM, Sean Johnson <belu...@acm.org> wrote:
> Agreed. This is a huge point. And not just in lowered hosting costs, but also
> potentially a better user experience (lower latency).
I am actually not sure how true it is. While the raw throughput of JVM
applications
is indisputably much higher than those based on non JVM ruby virtual machines,
in my experience the response latency in JVM is much more unpredictable and
have a much higher worst case. I believe this is due to the fact that ruby HTTP
servers tend to spawn multiple processes to handle requests which lead to a
per-process garbage collection, and thus to shorter pauses. At least that was
true
for all the applications I built around Sinatra. I never used rails, so cannot
comment on that.
Regarding multithreading, modern ruby implementations like rubinius are
completely multithreaded and it's up to the application code to take advantage
of it. However, the lack of proper multiprocessing primitives in the language
and lack of multithreading in the ruby interpreters for a long time lead to
libraries and frameworks designed around the asynchronous abstraction
and are generally not thread-safe. So in practice, it's very hard to take
advantage of that support.
For me, the biggest advantage of using ruby vs clojure for web development
comes from the development standpoint. While I love clojure as a language,
which is arguably a much more powerful and better designed language than
ruby is, it suffers from the typical problems any JVM platform has:
1) long startup time. While there are workarounds to this problem like
using a persistent vm, it's still a hassle compared to a non-jvm platform
where one does not even have to think about it;
2) horrible dependencies management. In jvm world you have to use
maven or ant style jar artifacts, which are tarballs with compiled
java classes inside. Those have no versions in them, so when
something breaks you cannot easily debug the issue just by looking
at the corresponding line of code like one does in ruby: I routinely
have to decompile class file to look at the code to try to figure out
what broke (I even set up mc to invoke jad(1) automatically when
I view a class file). The lack of versions in classfiles lead to another
problem: you are never sure that the jars hosted on the public
artifact sites correspond to the code versions they advertise, I
found it to be not true in a lot of cases and spent hours debugging
issues which were not present in the actual source code of the
library I used. There is also no verification of who uploads those
jar files to the artifactory and you cannot AFAIK provide maven or
ant with the checksum of the artifact you want, so those are as safe
to use as running a random code downloaded from the internet.
Unfortunately, it seems that the only way to do development on
the jvm platform at the time is to set up your own artifactory and
set up an automated build for each dependency version you
are using. :-(. Which slows develoment a lot.
Another issue I often face is that class files are not namespaced
via symbol versioning like native libraries are. That is the entire
JVM application has to use a specific dependency version for
all it's code. What happens if some library you use uses a different
dependency version than you need? You end up maintaining a
fork.
Some of this is true for ruby libraries as well, but late binding,
relaxed version specifications and generally better API stability
in ruby world makes this issue rare. And if it happens, it's much
easier to submit a fix upstream and rely on it, at least in my
experience.
3) General lack of decent tools. The only jvm debugger, jdb,
while nice, does not allow you to attach to an already running
process like gdb would. Profiling tools are pretty much GUI
only so won't allow you to collect profiled data in an automated
way. The same goes to JMX counters: you can only collect
them by using a gui application, or by using java API; there are
no command line tools provided in standard distribution which
complicates ad-hoc monitoring and collection. There are no
easy to use tools or APIs to work with bytecodes, jars, manifests
and so on either.
I guess the bottom line is that jvm does not play well with the
outside world and you pretty much have to commit to JVM
platform if you want to use it for development. Any interoperation
with other platforms and OS services was a big hassle for me.
I hope that clojurejs on nodejs will make the life much easier
in that regard.
As as a side note, I used erlang/webmachine for one of my
recent projects and found the experience quite pleasant. While
the language is not as powerful as clojure or any other kind of
lisp is and metaprogramming capabilities are quite limited,
it is very easy to spawn processes to do background processing
and communicate with them, and error and failure handling is
awesome. It also plays really well with unix, and tools are
great and well documented. I wish someone would do clojure
for BEAM. :-) (although there is LFE, but it does not seem to
be popular and does not provide all those nice things clojure
does).
--
ST4096-RIPE
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
