Live data from Hacker News

ClojureScript

github.com

91–95 of 95 posts

Re: ClojureScript

#91
post #85
post #60

Earlier quoted context omitted.

Theoretically almost any language that can run on x86 will now run in Javascript thanks to Fabrice Bellard: http://bellard.org/jslinux/ I don't think anyone has managed to get a JVM to run on his Linux port yet though. More practically, Javascript itself runs fine on the JVM (via Rhino). There are Ruby-on-JS[1] and Python-on-JS[2] efforts as well (both Ruby & Python run on the JVM) [1] http://ejohn.org/blog/ruby-vm-i…

x86 emulation is the wrong solution to this problem because of the difficulty of interop. Compiling to bytecode at least lets you treat JS functions as FFI calls. The first project to do this was Clue in 2008 ( http://cluecc.sourceforge.net/ ), now all the hype is about emscripten ( https://github.com/kripken/emscripten ) LLVM bytecode to JS compiler. Doing compilation GWT/Clojurescript style is going to reduce integ…

Yeah, I wasn't too serious about the x86 "solution". It's an impressive hack, but that's all ATM.

I forgot about the LLVM compiler - that's a very promising project.

Re: ClojureScript

#92

I havent look at the implementation yet, but the question that comes to mind is is this one step closer to "Clojure in Clojure"?

Yes, it's a big step in that direction. Rich said it should be easy to change JS target for another.

I would assume however that threading concerns have not been taken into account for the "Clojure-in-Clojure" on display in ClojureScript however, based on https://github.com/clojure/clojurescript/wiki/Differences-fr...

That suggests to me that concerns over thread safety that are taken into account in the Java implementation, say of the core data structures, STM, etc, are not taken into account in the std. lib. of ClojureScript. That would make it unlikely for this code to be a useful origin or starting point for, say, an LLVM backend.

Rich is a very clever fellow and makes fascinating trade offs between pragmatism and idealism in his language design. He continues to build languages quite tied to some existing runtimes which embrace their advantages and drawbacks. Consequentially, it will be very important to keep the rationale in mind while evaluating the real impact of ClojureScript. https://github.com/clojure/clojurescript/wiki/Rationale As neat as it would be to see, it will be a long time before an x86 or ARM backend emerges.

As far as I know, the G1 Garbage Collector in the JVM is still the top of the crop of production GCs and even Haskell with GHC7 is still working towards something of similar potency. See http://hackage.haskell.org/trac/ghc/blog/new-gc-preview

Concurrent GCs and other aspects of runtimes geared towards heavy concurrency are insanely hard. Just something to keep in mind.

Re: ClojureScript

#93
post #26

Earlier quoted context omitted.

Bear in mind that the wording is very careful. We took great pains to say things like "not currently implemented." ;-)

"ClojureScript does not currently support regular expression literals using #"" " This one seems like a big deal, given how often I find myself using regexes in clojure. Is it on its way and is there a workaround currently?

I'm sure you can use the native RegExp class:

    (def pat (RegExp. "Some(.+)"))

Re: ClojureScript

#94

It's interesting how closely tied to Google Closure this is. I wonder if that will present issues in the future. Regardless, ClojureScript has definitely made really smart use of it.

"It's interesting how closely tied to Google Closure this is. I wonder if that will present issues in the future."

It will definitely present issues to verbal communication.

"Yes, you see, Clojure uses Closure as part of it's implementation blah blah..."

"Wait, Clojure uses Clojure?"

"No, with-a-J-Clojure uses with-an-S-Closure..."

Re: ClojureScript

#95
post #26

Earlier quoted context omitted.

Bear in mind that the wording is very careful. We took great pains to say things like "not currently implemented." ;-)

"ClojureScript does not currently support regular expression literals using #"" " This one seems like a big deal, given how often I find myself using regexes in clojure. Is it on its way and is there a workaround currently?

There you go:

https://github.com/clojure/clojurescript/commit/a201e9d8dec8...

Post reply on HN