5 ms·

So if I wanted to write CLI applications in Clojure, is this my best bet? Cause the JVM is about the least suitable platform I have ever worked with for CLI app

So if I wanted to write CLI applications in Clojure, is this my best bet? Cause the JVM is about the least suitable platform I have ever worked with for CLI apps...which is most of what I do. I'm constantly in this pickle of wanting to use Clojure but defaulting to Ruby because the JVM is so terrible at it.

pjmlp 14y ago
Get one of the many AOT compilers for Java. No more JVM startup time to worry about.
mambodog 14y ago
You could also use node.js with Clojurescript, if you're willing to accept the compromises of Clojurescript.
- saosebastiao 14y ago
  I'm not familiar with the compromises of clojurescript nor running node.js as a CLI platform. Got any links that can help explain? Can it be compiled to a static executable?
bbq 14y ago
If the startup slowness is your problem, look into Nailgun: http://www.martiansoftware.com/nailgun/ http://www.martiansoftware.com/nailgun/ If that's not your problem with the JVM, what is?
- saosebastiao 14y ago
  Nailgun is an additional dependency. And pretty insecure at that.
  - bbq 14y ago
    Well, that would do it. =)
- Rayne 14y ago
  Nailgun is not a good solution to the problem. If the JVM startup speed is a problem, your best option is to use something not on the JVM and not use hacks that make it feel faster.
  - bbq 14y ago
    That's not true. Yes, it's worth considering outside of the JVM if being on the JVM means your application isn't interactive enough (startup speed doesn't matter for long running, fire & forget tasks). At the same time, splitting your application into a client/server architecture is not a hack but an engineering decision. There are times when this decision is natural e.g. Music Player Daemon (MPD)[1]. For most CLI applications, there's no clear benefit (but the general approach has no clear downside either - the code overhead of this approach can be brought very low). Certainly, in a production application you would want to secure the messaging channel (Nailgun doesn't). [1] A music playing server: http://www.musicpd.org/ http://www.musicpd.org/. Some of the clients happen to be command line: http://mpd.wikia.com/wiki/Clients#Command_Line_Clients http://mpd.wikia.com/wiki/Clients#Command_Line_Clients
fiatmoney 14y ago
Depending on what you're doing, you can consider the REPL as your CLI and run everything in that process.
uvtc 14y ago
The readme for ClojureC says it's still experimental at this point. I'm not sure how far along it is. You might poke around its tests to see what it does so far.
rhizome31 14y ago
The problem is that the slowness is not limited to running command line programs, the REPL is slow to start, compilation is slow and so is running any leiningen task. As suggested in another comment I gave a quick try at ClojureScript but the compilation process is also slow. Clojure is an appealing language but to me the general sluggishness of the environment is too irritating. The existence of things like Nailgun and Drip seem to confirm that there's a real problem there. I suppose if you're coming from a C-based runtime like Ruby or Python, you have to adapt your workflow. I imagine that a lot of Clojure people come from Java and have already shaped their workflow around the JVM.

pjmlp 14y ago

Get one of the many AOT compilers for Java. No more JVM startup time to worry about.

mambodog 14y ago

You could also use node.js with Clojurescript, if you're willing to accept the compromises of Clojurescript.

saosebastiao 14y ago
I'm not familiar with the compromises of clojurescript nor running node.js as a CLI platform. Got any links that can help explain? Can it be compiled to a static executable?

bbq 14y ago

If the startup slowness is your problem, look into Nailgun: http://www.martiansoftware.com/nailgun/ http://www.martiansoftware.com/nailgun/ If that's not your problem with the JVM, what is?

saosebastiao 14y ago
Nailgun is an additional dependency. And pretty insecure at that.
- bbq 14y ago
  Well, that would do it. =)
Rayne 14y ago
Nailgun is not a good solution to the problem. If the JVM startup speed is a problem, your best option is to use something not on the JVM and not use hacks that make it feel faster.
- bbq 14y ago
  That's not true. Yes, it's worth considering outside of the JVM if being on the JVM means your application isn't interactive enough (startup speed doesn't matter for long running, fire & forget tasks). At the same time, splitting your application into a client/server architecture is not a hack but an engineering decision. There are times when this decision is natural e.g. Music Player Daemon (MPD)[1]. For most CLI applications, there's no clear benefit (but the general approach has no clear downside either - the code overhead of this approach can be brought very low). Certainly, in a production application you would want to secure the messaging channel (Nailgun doesn't). [1] A music playing server: http://www.musicpd.org/ http://www.musicpd.org/. Some of the clients happen to be command line: http://mpd.wikia.com/wiki/Clients#Command_Line_Clients http://mpd.wikia.com/wiki/Clients#Command_Line_Clients

fiatmoney 14y ago

Depending on what you're doing, you can consider the REPL as your CLI and run everything in that process.

uvtc 14y ago

The readme for ClojureC says it's still experimental at this point. I'm not sure how far along it is. You might poke around its tests to see what it does so far.

rhizome31 14y ago

The problem is that the slowness is not limited to running command line programs, the REPL is slow to start, compilation is slow and so is running any leiningen task. As suggested in another comment I gave a quick try at ClojureScript but the compilation process is also slow. Clojure is an appealing language but to me the general sluggishness of the environment is too irritating. The existence of things like Nailgun and Drip seem to confirm that there's a real problem there. I suppose if you're coming from a C-based runtime like Ruby or Python, you have to adapt your workflow. I imagine that a lot of Clojure people come from Java and have already shaped their workflow around the JVM.