I've been following Julia for over a year (basically since their first public announcement), and I'm genuinely impressed with the team, their attitude, and their approach to designing a new language. Their performance numbers (on microbenchmarks) are awesome. The use of LLVM shows sensibility and pragmatism, and while I don't yet fully grok the type system, I think they're on the right track. I'm also really excited to see a couple of experienced R guys (John Myles White and Harlan Harris) join the Julia bandwagon. Despite the lack of a convincing story when it comes to distributed computing, it's a really promising project.
But, when I think about pushing a significant project on Julia, it feels really risky. I think it feels like betting on Python in 1995 would have. Sure, sitting here today the decision should have seemed obvious, but how many promising languages rose and died in the same timeframe?
I think Julia is a pretty good bet. Its target audience seems to love it. I've got too much on my plate right now to put the hours in on it.
Sure, you have to manage risks, but why not put insignificant but necessary projects on it? Just pick a few that someone can rewrite in a day or two if needed. (This is of course assuming you're part of the target audience and not just looking for a new web framework, but it doesn't sound like that's the case.)
I think getting a usable web stack on julia will take it a long way in terms of making it useful for problems at-scale.
My major nitpick with julia so far, if I can be real, is that its package tooling isn't enough like npm. <_< While this gives away my obvious biases, I do think that spending time on making a really good package ecosystem is important, and is something not enough people take seriously.
It's easy for non-ops people to install packages, but I'm not sure it is easy to do large scale deployments. I'm not hating on npm, but there is still a lot to do with managing all of the dependencies in a way that makes it easy to deploy consistent packages. Pip doesn't solve this problem either, so it isn't unique to npm.
There are some tools for using npm for large scale deployments. Packages are scoped locally to an app, you can bundle them if you want, and there's a "shrinkwrap" command for making sure the installed deps are exactly the same every time. Personally, I would either go with, "peg every version to an exact semver" or "bundle ALL the deps".
Sad thing with Julia: when I took a look at it as a language for ML/AI, I loved it (beside the 1-indexing, but one can get used to it...), but all the libs I cared about were in Python!
...now I take a look at Julia for webdev and, again, everything I am familiar with or care about for webdev is in ...Python. And being a high performance language, it actually steps in to the territory of Go here.
Julia is gonna have a very hard time displacing Python (or Go), since they are kinda targeting the same niche, but I really, really want to see Julia winning more ground! Now don't get me wrong, I understand that most normal-minded people (including Julia's creators) never saw it as a competitor for Python or Go, but this is how I want to see it.
...a homo-iconic language, with hygienic macros and no crippling anti-features like statements/expressions dichotomy or one-line-only lambdas, and all of this without giving up on syntax and going the parenthesized way (take that Lisp!), what more could one wish for, really!?
And there is also an effort underway to get iPython notebook integration (we met with Fernando Perez when he was in Boston to receive his award from the FSF and spent an afternoon hacking to get to this https://github.com/JuliaLang/julia-ipython - it's still in the very early stages of development though)
Yes, that is possible as well. I don't think it's all factored out into a nice Python package yet, but the code to do so is part of the julia-ipython repo.
Since Julia is within a factor of 2 of C on some common micro-benchmarks (http://julialang.org/), and since it has a decent IO library (libuv, borrowed from node.js), it wouldn't surprise me if performance is on par with the JVM.
Funny. Replace the word "Python" with "R" and you get the same thoughts I had.
In some ways, I wonder if Julia is creating more silos instead of having these smart folks work to integrate the wonder of Python with the vastness of the R library... Dream the impossible dream.
"Julia is a high-level, high-performance dynamic programming language for technical computing, with syntax that is familiar to users of other technical computing environments. It provides a sophisticated compiler, distributed parallel execution, numerical accuracy, and an extensive mathematical function library. The library, largely written in Julia itself, also integrates mature, best-of-breed C and Fortran libraries for linear algebra, random number generation, signal processing, and string processing. In addition, the Julia developer community is contributing a number of external packages through Julia’s built-in package manager at a rapid pace. Julia programs are organized around multiple dispatch; by defining functions and overloading them for different combinations of argument types, which can also be user-defined. For a more in-depth discussion of the rationale and advantages of Julia over other systems, see the following highlights or read the introduction in the online manual."
HTTP specification API, web-server, Sinatra-like DSL, and client implementations already exist in Julia (and are listed in the package manager): https://github.com/dirk/HTTP.jl
The server is also pure-Julia and doesn't require a shared library, unlike this project.
But, when I think about pushing a significant project on Julia, it feels really risky. I think it feels like betting on Python in 1995 would have. Sure, sitting here today the decision should have seemed obvious, but how many promising languages rose and died in the same timeframe?