Can Julia be the next web scripting language?

[musicde...@gmail.com]

It is faster than JavaScript.

[musicde...@gmail.com]

It is faster than JavaScript.

[John Myles White]

I think replacing JavaScript requires something more than a speed improvement over JS. You'd need to provide a compelling reason for deprecating essentially the entire modern Internet and then starting from scratch in Julia.

-- John

On Sep 15, 2013, at 8:36 PM, musicde...@gmail.com wrote:

> It is faster than JavaScript.
>

[musicde...@gmail.com]

Let's be theoretical. Is Julia suitable for web programming?

[John Myles White]

That's a little hard to answer since it's a pretty broad question. What do you mean by web programming? Server-side web page generation? Client-side in-browser manipulation of the DOM?

-- John

[Benjamin Silbaugh]

With the right social engineering/conditioning, Fortran could be the next web scripting language.

Okay, that may be a bit hyperbolic. The point is, getting a language to be used by a particular community requires more than technical merit (e.g. speed, ease of use, etc). You have to make people believe that it's the language that they should be using, and get them excited about using it.

[Stefan Karpinski]

I could certainly be just as effective for server-side web programming as Ruby and Python are – and it's considerably faster, putting it more in the performance realm of Go and Java.

[Jerzy Głowacki]

I suppose Julia would be the successor to JavaScript if it was converted by Emscripten and run by asm.js. But for now there seems to be an Enscripten bug which invalidates Julia IR code.

[Páll Haraldsson]

On Thursday, December 18, 2014 10:59:53 AM UTC, Jerzy Głowacki  wrote:

I suppose Julia would be the successor to JavaScript if it was converted by Emscripten and run by asm.js. But for now there seems to be an Enscripten bug which invalidates Julia IR code.

Hi,

Curious, what bug is that? You have a bug number or know what it relates to (on Emscripten side)? "Invalidates Julia IR code"? Intermediate Representation? Does the bug only affect Julia? Have anything to do with JavaScript "ints" (that it their "non-existence", JS uses doubles as int)?

Did you really mean to say "Julia would be the successor" or "Julia could be a successor"?

Is there any obvious "successor" or fairly much used alternative currently? I've heard about Coffeescript, Typescript and Dart etc. languages made to compile to JavaScript. And Scala.js. Scala was meant to run in JVM and Scala.js has slightly different semantics because if JS's ints. I wandered if Julia could do the same.

I assume you are talking about compile Julia the language/environment to JavaScript and run the the REPL in a browser?

Should it be easier to compile Julia code to C (possible now) and that C code via Emscripten to JavaScript? Emscripten says they handle "portable C code". Doesn't Intel's Julia2C claim "portable C"? I don't really see how Emscripten handles "ints". There is no requirement that C's ints are less than 64 bit? Do not even have to be two's compliment, right? I fail to see how they densely pack "ints" (that are 64-bit doubles) into 32-bit in arrays..


PS. I dreamt my first dream in Julia code tonight. Might be a sign it's the language for me.. :) Reminds me: "Dreaming in code" is a good book on (Python and) Chandler (and e.g. Kapor/Mozilla)..

PS2. Is there an alternative gateway to the forums. I just hate using the web(browser it's slow). Google Groups used to be for Usenet, but not this forum..

[Tom Short]

It's getting closer. First, the --compile=all and --dump-bitcode=yes options to Julia are a big help in dumping LLVM bitcodes. The contrib/build_sysimg.jl code is useful for this after modifying it to include these Julia command-line options.

There are a few issues with using Emscripten with Julia code:

* 32-bit code -- Emscripten expects 32-bit bitcode. On a 64-bit platform, Julia generates 64-bit bitcode. I tried using the build_sysimg.jl script with a target of i686, but Emscripten still gave me errors.

* struct error -- See this bug:

    https://code.google.com/p/nativeclient/issues/detail?id=3932

* Symbol naming -- Code generated by Julia has a lot of symbols like #sym that Emscripten doesn't like. This can be handled by either Emscripten or on the Julia side.

Lastly, libjulia bitcode needs to be generated. I've gotten about 80% of it to compile after stripping out the libuv stuff. There are also libraries like BLAS, but these can be added as needed.