Hacker News Reader

Comment by LesZedCB | Hacker News Reader

what's the tradeoff of clojurescript over native clojure? wouldn't the java clojure runtime be much faster?

Steady-state performance tends to be better on the JVM but startup performance is always much better on top of JavaScript. That makes it an enticing trade off for shells which is a process that you start new ones of constantly and where the performance of the shell itself is often not very important. (Performance-critical or hard-to-duplicate code like, say, line editing code, can be done equally well on either platform via FFI.)

Why not just make a server that starts up once in the background and then a lightweight c frontend to the server that essentially just pipes every keystroke to the server?

Shells are supposed to inherit a ton of state from their parent — [e]uid, groups, working dir, env vars, nice, umask, chroot, ... This takes zero effort in unix, but would all have to be (securely!) re-implemented to be able to send code to a shared execution daemon...

And I expect the right implementation for many of these params will be running separate daemons anyway (eg. you clearly want one per user).

Clojure/JVM apps are very slow to start, which makes them particularly unsuitable for a shell, where you typically don't want to wait a few seconds for the prompt to become interactive.

I find to hack on clojurescript on node easier. Also it is easier and starts faster.

But many parts of code are platform agnostic. I think it would be cool to eventually port the system specific parts to java apis and have both.

What does your development environment look like? Every time I bail on a Cljs project it's because tooling is worse than for Clj.

I use Spacemacs and have the following in inside my .spacemacs in the dotspacemacs/user-config functions:

      (require 'cider)                                  
      (setq cider-cljs-lein-repl                                                                             
        "(do                                        
            (require 'figwheel-sidecar.repl-api)                                                         
            (figwheel-sidecar.repl-api/start-figwheel!)
            (figwheel-sidecar.repl-api/cljs-repl))")

Then I just use figwheel to manage my cljs projects (I think this is the default now for reagent and luminus projects, it's also the default for re-natal for react native development in cljs). Life is pretty good and I have a nice debugger via Chrome.

I prefer the debugger in CIDER (which doesn't work for cljs) to the debugger in Chrome, but the Chrome debugger is decent (and it's what I'd have in Javascript anyway). There is a nice chrome extension to help with clojurescript eval in the browser/debugger called dirac: https://github.com/binaryage/dirac

This configuration is tremendously slow for me for some reason. Looks like Chrome put a tab "to sleep" when it loses focus. That leads to long freezes while you type anything in cljs file. Am I missing anything?

Whoa, awesome. That was super helpful. I'm also a spacemacs user, but my pain was mostly for non-browser Cljs. I should have specified, you're right: developing browser Cljs is pleasant because of figwheel :)

I also use figwheel for Android development via React Native. It seems to work pretty well.

yes. and multithreaded.

Theres no meaningful reason to use cljs other than to avoid java or if the java runtime isn’t available (eg. browser).

startup time: not sure it's good ux to wait seconds for every command...

lumo/cljs is instantaneous

It's not like you need to spin up a separate JVM for each command.

500-600ms is, to be fair, a big one time cost.

The downsides are pretty darn significant though. I can’t imagine a situation where I would trade ‘starts a bit faster’ for ‘throw away all parallelism in code’ personally... but hey. Plenty of people use node for very serious stuff.

I suppose I just think this is an example of fast and cheap on the fast/cheap/good scale.

But this is a shell. You start _all the time_, including plenty of times where you don't really notice: other processes often start subprocesses via your shell to get your environment right. Meanwhile, the shell is usually just waiting for you, so it's not like it's an intrinsically parallel process. This doesn't impact the shell's ability to run multiple things at once: the shell eventually creates subprocesses. One would expect an event-loop like Node to be perfect for this sort of thing.

Reply on news.ycombinator.com