Julia Computing Granted $600k by Moore Foundation | Hacker News Reader

Julia Computing Granted $600k by Moore Foundation

moore.org

At first glance Julia looks excellent. Glad to see money going to a project that makes sense :)

I guess Python is "the competition" so here's my thoughts on that competition (from knowing fairly little about Julia). From my limited experience Python is actually easy enough to grasp for most scientists without a programming background so I'm not sure the "easier" argument is what should be focused on. At the "lower end of the spectrum" (that is not super hard data crunching and/or less affinity for programming) there's social sciences, psychology, marketing, economics etc. and they use a variety of higher level tools (the pesky SPSS) for their routine tasks and are usually willing to invest time for more data crunchy activities (often R but Python is common as well in say economics with data-crunchy models).

The big attraction of Python (for me) is that you don't just get the data crunching but also the boilerplate you'll need around it (data normalization, stroing stuff in databases and getting it out, turning your models into simple web-apps etc.) + IPython notebook and distributions like anaconda make setup and quick experimention fairly simple.

If I were to give advice to someone entering science I'd certainly suggest "learn python". However...the more languages we have the better, MATLAB makes me cringe for multiple reasons. Go Julia :D

IPython notebooks have gone multi language:

https://jupyter.org/

https://blog.jupyter.org/2015/04/15/the-big-split/

I think Julia was one of the early alternate languages.

Indeed, the "Ju" in "Jupyter" is for Julia!

Out of curiosity, can you have multiple languages in one notebook with the output of one cell, in say Python, be input for a second cell in Julia or R? (emacs org-Babel allows for this -- a feature I use often.)

I just googled it, I don't know a lot about Jupyter, but yes:

http://blog.dominodatalab.com/lesser-known-ways-of-using-not...

http://ipython.readthedocs.org/en/stable/interactive/magics....

To some extent - yes. E.g. you can run R in a Python notebook; just each R cell need to be started with '%%R' (and one need to load rpy2).

See e.g. https://github.com/DELabUW/szkola-letnia-2015/blob/master/za...

Beaker notebook [1] seems to do precisely that, though I have yet to use it in practice.

[1] http://beakernotebook.com/index

Yes, most easily through so-called "cell magics".

I would like to point out that the Julia and Python communities have a pretty good relationship. We have given talks at several Python conferences, and there is great interoperability as well.

IPython notebook nowadays supports Julia, R, etc and has been renamed: https://jupyter.org/

Python fans are a bit unnerving, they seem to be more vocal among the similar alternatives R, Octave/Matlab, SPSS. Some people simply prefer Julia for its nice language syntax and its native raw speed, deal with it.

> Python fans are a bit unnerving, they seem to be more vocal among the similar alternatives R, Octave/Matlab, SPSS

It'd be difficult to list four languages that are more different than those in your list. There's some overlap in the tasks each is suited for, but they're hardly alternatives.

From my experience trying to argue your point, python people are the ones who most often refuse to understand it.

Have you tried https://www.juliabox.org/ yet?

> However...the more languages we have the better, MATLAB makes me cringe for multiple reasons.

I didn't want to get into this holywar, but god darn it, what kind of half-assed language uses the notation C = A.dot(B) for C = A * B? It's as if the authors of Numpy took just enough classes of Linear Algebra 101 to learn about dot products, and then dropped out of college to pursue their glamorous careers developing their Matlab knockoff.

The original creator of numpy (Travis Oliphant) was a professor working in scientific computing. And numpy is a library, not a language. Thank you for your constructive criticism of freely distributed gifts to the community.

Trying to come up with an appropriate response to your comment reminded me of this: http://goo.gl/KqXXDV

This is great news for Julia!

As a long time Python user, I disagree with the insinuation of competition between the two communities. In fact, I've met all of the core developers of Julia and of the major Python data science projects, and they see each other as fellows and colleagues!

For example, last year at PyData NYC, Stefan Karpinski gave the following talk, titled 'Julia + Python = \N{heavy black heart}'

https://www.youtube.com/watch?v=PsjANO10KgM

This past week, at PyData NYC, Stefan Karpinksi also shared the stage with Andy Müller (scikit-learn) and Jared Lander (author of R for everyone) to discuss the future of machine learning with the audience and addressed how the various tools, languages and communities fit together.

In fact, most people may not realise, but Julia, Jupyter, IPython, numpy, pandas, matplotlib, &c. are all fiscally sponsored projects of the same 501(c)3 non-profit, NumFOCUS (which is the organisation that also runs the PyData conference series)!

http://numfocus.org/projects/index.html

This is great news for Julia.

As a person who has spent the best part of year coding almost exclusively in Julia (I work in finance, we were one of the main sponsors of JuliaCon, though these are my personal thoughts) I want to chime in a little.

To get to 1.0 many of the cons in the language will be solved and there are plans in place for much of this.

I never cease to be surprised by the brevity of code to solve complex problems. Something which would be hundreds of lines in Java/C++ often turns into 50 or so lines of much more readable code.

When asked to describe Julia I struggle but end up this way 'I can make Julia 'dance' like no other fast programming language' though to be fair modern JS is pretty close for many tasks.

The parametric type system is to me the strongest part of the system - I describe it simply as 'templates that work', it is ridiculously powerful and (to me) is the most compelling reason to learn Julia.

I personally find even at 0.4 it is very usable even for tasks which are not math. Though the run time is currently fairly heavy.

So congrats to the Julia team.

"many of the cons in the language will be solved"

Can you elaborate on this?

Re type system, how does it compare to python in use?

I'm not the best placed person to answer about Python, my background is primarily C++/Java and functional languages. The types in general get out of the way. The ability to specialize behavior by types makes for some very interesting patterns and for a module writer add a huge amount of power. For the user of the module they rarely see the types.

The cons, top three from the top of my head, implicit array concat ( going in 0.5 ), String types ( going soon ), anonymous function performance ( gone by 1.0 )

None of these are show stoppers, but they do sometimes fall into the category of surprising. The core dev are very aware of the issues and if you look at the road map for 1.0 many are either well on their way to being fixed or are scheduled to be resolved.

As someone who spent some time learning Julia and wants to like it, here are the problems I experienced when I was trying to actually write software with it that I would keep using, as opposed to just scripting some numeric operation I needed to do.

* Non-numeric things are not well optimized. Building a dictionary full of strings was slower than Python when I tried it.

* The module system is confusing because of the principle that files should be "mostly unrelated" to modules. The documentation gives you no advice on how you should organize your code so that it's easy to import, understand, and maintain. The advice I got at a meetup was "just include() everything".

* Package management is a loose wrapper around git. The git commands it runs do not always succeed.

* Curly braces do something different in every version.

For anyone interested in trying to get to know Julia (like me), I've found these talks useful as a starting point:

Introduction to Julia - Part 1 | SciPy 2014 | David Sanders - https://www.youtube.com/watch?v=vWkgEddb4-A

Get To Know JuliaLang - Guest Talk by Co-Inventor Viral Shah - https://www.youtube.com/watch?v=OC3hsct63Ok

If anyone can recommend other resources that would be appreciated.

Here is a good short blog post: http://www.nowozin.net/sebastian/blog/the-julia-language-for...

This is great news for Julia and the scientific computing community in general. MATLAB doesn't scale, and python solutions are too scatter brained for me.

I actually, more and more think that python is an excellent language for science.

The only issue is that, when it comes to numerical computation, there is only "one right way to do it", which goes against Python philosophy. Meaning, either you do it while using vectorial operations mostly everywhere, or it's just too slow to work.

The only real advantage I see in Julia, is that it doesn't constrain you to a specific way to think about calculations. You can think about them in a vectorial way (which is not always possible) or you can just use an iterative approach. Both work fine.

This is what I mainly expect to get from Julia, but we must admit that the inertia behind python and it's excellent libraries for numerical computation, make it hard to change to Julia.

> The only issue is that, when it comes to numerical computation, there is only "one right way to do it", which goes against Python philosophy.

But ... This is actually one of the pillars of Python:

There should be one-- and preferably only one --obvious way to do it

<https://www.python.org/dev/PEPs/pep-0020/>

My bad... I sometimes mix Perl and Python philosophy.

> I sometimes mix Perl and Python philosophy.

That's like mixing up Vulcans and Romulans. Very dangerous indeed.

>...there is only "one right way to do it", which goes against Python philosophy

There should be one-- and preferably only one --obvious way to do it.[0]

[0] https://www.python.org/dev/peps/pep-0020/

Like I said. I was mixing Perl's and Python philosophy.

It's strange I know. I work in Python almost every day and I've never touched Perl code.

At least, I guess I'll have a silver lining at cracking my head in vectorizing everything from now on.

What python solutions are scatterbrained? Have you tried Numba?

I'm not the parent author, but why I haven't tried the Python ecosystem:

I've heard of NumPy, PyPy, SciPy, Pandas, matplotlib, and now Numba. I don't particularly know what these do or how they overlap or interact. Which is kind of the point: to a complete outsider, the world of Python scientific computing feels like a wild west where everybody is happily proclaiming that their setup is just right.

Additionally, Python is slow; Julia is fast. I've heard things like "well, Python is only slow at certain things, and makes it easy to write C code when needed." I don't want to write any C code. Same goes for "typically only a small portion of your Python code is a bottleneck, and it's easy to port that to C."

A huge part of the appeal of Julia is that you don't have to worry about language interoperability, calling C, etc. Everything can be written efficiently and readably in Julia, and because the base language is designed around scientific computing, there's little worry about add-on scientific computing packages not playing nice together.

Now, I fully believe that I could get the right Python environment and set of packages set up be productive. But to get going with Julia, I just download Julia and go.

Also, JuMP [1] is just amazing.

[1] http://www.juliaopt.org

> I've heard of NumPy, PyPy, SciPy, Pandas, matplotlib, and now Numba. I don't particularly know what these do or how they overlap or interact. Which is kind of the point: to a complete outsider, the world of Python scientific computing feels like a wild west where everybody is happily proclaiming that their setup is just right.

It's not terribly complicated once you spend a little time working with the libraries. Working with arrays? import numpy. Machine learning? import sklearn. Plotting? import matplotlib. Need to do some interpolation, integration, or work with some strange orthogonal polynomials, (etc...)? import scipy. Sure, there's some minor overlap between scipy and numpy, but nothing that causes any problems in my experience.

What I love about using python is that, in addition to all the great math and science libraries, you have all the other python tools at your disposal. Working with xml? import xml. Web-scraping? import urllib2 (or whatever people use now), PyQuery. Additionally, there's all the file system business work that's a joy to do in python using os, sys, etc... libraries.

> NumPy, PyPy, SciPy, Pandas, matplotlib, and now Numba

I'm not sure I buy this argument. Except for pypy, these are all complementary packages and work together. If you breakup anything into its constituent parts, you can make it seem complicated if you want to.

> But to get going with Julia, I just download Julia and go.

Until you need to do something very straightforward like web scraping or interacting with AWS and find out that nobody's released a package for that yet, so you're going to have to reinvent the wheel before you can get to the scientific question that is of actual interest.

Julia looks very interesting as a language, let's just hope it doesn't end up a ghetto like R (lots of awesome statistical tools, a dearth of libraries and tools for everything else).

> Until you need to do something very straightforward like web scraping or interacting with AWS

For web scrapping: https://github.com/porterjamesj/Gumbo.jl For AWS: https://github.com/JuliaParallel/AWS.jl

Definitely, Julia doesn't have as many libraries as Python, but most common needs are covered. And for the rest you can actually call Python through PyCall.jl

This just proves my point, though. Gumbo is an HTML parser, not a scraper. The AWS library "will" support EC2 and S3. Again, this is all perfectly normal and it'd be absurd to expect such a young project to have a rich ecosystem. I think the Moore foundation grant is awesome and hope to use Julia someday. It's just that (1) as a scientist, you really just want to get shit done and (2) because it's marketed solely to scientists, I'm concerned Julia might never develop an ecosystem of general-purpose tools. R certainly hasn't.

Not sure what you mean by "web scrapper" than, but if you just need something to download web pages (in addition to parsing HTML), then Requests.jl covers it pretty well.

IIUC from GitHub page, AWS.jl has most API implemented, just not thoroughly tested. So it's not really mature or robust, but from my experience with packages at the same stage of development it should be pretty usable for a scientist who "just wants to get shit done".

I totally share your concern regarding marketing solely for scientists, though.

Can't you call out to python with pycall for that?

My experience with bridges is that they always suck, and the ways in which they suck are extremely difficult to debug and never obvious until after you've made a significant investment.

Shit I've seen: silent memory corruption, silently dropping the last element of an array if and only if it is the last declared field in the structure, killing the debugger every time you hit the bridge, inaccessibility of critical code because it uses X unsupported language feature, event-loop integration nightmares (IO suppression / null-routing / deadlock), exception incompatibility, unconfigurable signal/interrupt stealing. And that's all without counting the "usual suspects" of documentation, performance, and testing issues.

Maybe the Julia-Python bridge doesn't have any of these problems. But I'm not going to be the one to find out.

The PyCall Julia-Python bridge is shockingly good. It was written by Steven Johnson, also the author of FFTW – the world's state-of-the-art Fast Fourier Transform library for a two decades now. He is one of the best, most thorough programmers I know. When he writes something, it works.

R is for the stats part of the project. It does just that. I'd never implement a full system in it, but it does the stats bit fantastically.

I usually use cython for optimizing python, which is a lot easier than working directly with the CPython C API. You do need to know C to get the most out of it, but you can go a long way just adding type declarations to python to speed it up.

Here, I'll use logical indexing to pull out all the positive even numbers from this array of random integers:

Numpy:

  a = np.random.random_integers(low = -100, high = 100, size = (100,))
  a[np.logical_and(a % 2 == 0, a > 0)

(or a[(a % 2 == 0) * (a > 0)])

Logical indexing is used everywhere in numerical computing. Using functions like logical_and() or boolean multiplication or addition is more difficult to follow than Matlab or Julia.

Julia:

  a = rand(-100:100, 100)
  a[(a % 2 .== 0) & (a .> 0)]

Well, that's beautiful. Element-wise operations are prefixed with "."

You have made a very verbose numpy version :) Here is a slightly better one:

    a = np.random.randint(-100, 100, size=100)
    a[(a & 2 == 0) & (a > 0)]

Python does indeed have logical boolean operators.

I think this is clearer than your Julia example because:

- The numpy version makes it clear that you are using random integers, not floating point values.

- The keyword argument for "size" makes it clear what that second 100 is for. (The use of the first two numbers, -100 and 100, is pretty clear from context.)

- In numpy, most operations are element-wise by default, because the result would be ambiguous or not useful otherwise. This removes the line noise of the extra "." before operations.

Don't get me wrong, I think Julia is awesome. I just think you've constructed a very poor example for numpy.

> The numpy version makes it clear that you are using random integers, not floating point values.

That's also completely clear in the Julia version, if you learn a little Julia.

> In numpy, most operations are element-wise by default, because the result would be ambiguous or not useful otherwise.

This is why I think the Julia approach is better. If I write `a == 7`, am I testing whether `a` is 7 or whether any of the elements of `a` are 7?

> That's also completely clear in the Julia version, if you learn a little Julia.

In every language I've used, the default is for a "rand" function to return random floats between 0 and 1, and given arguments it returns floats between the arguments. I don't think it has to do with learning Julia, it is just that including "integer" in the function name makes it clear the function returns integers.

> This is why I think the Julia approach is better. If I write `a == 7`, am I testing whether `a` is 7 or whether any of the elements of `a` are 7?

I think this is more of a comment about mixing arrays and scalars in a dynamic language. I made my comment assuming you are performing operations on arrays. If you are comparing two arrays, I think the default of element-wise operations makes more sense.

In julia the rand function is more general in that it samples from a distribution, which you can pass as the first argument (defaulting to uniform on [0,1]). Since the first argument is an integer range, you get an integer value.

MATLAB is also rather expensive if you are not a student.

there is octave, an open source alternative

Octave is quite slow tough.

And doesn't have the Matlab GUI.

all true, but it is 99% syntax compatible with Matlab. As a student I had saved a lot of money using Octave

If you don't mind trying yet another library, care to have a look at arrayfire-python ? https://github.com/arrayfire/arrayfire-python

We started off as a C/C++ library but are constantly adding support for new languages. The one benefit of ArrayFire would be the ability to use the same codebase across CPU, CUDA and OpenCL devices.

There is a start for Julia bindings, but not currently maintained.

https://github.com/JuliaComputing/ArrayFire.jl

OOP is "weird" in Julia compared to Python and others and first time users may find it off-putting, but just power through and eventually you'll realize just how awesome multiple dispatch is and the lack of traditional classes. It's a more functional style that is very powerful (and in my opinion, more readable) in scientific computing.

One of the reasons to consider Julia, as noted in the article:

>its flexibility and high performance (comparable to C)

This is one of those points that is so rare to see in new, high-level languages, and quite welcome in the world of high-iteration numerical computation.

I hope they can have it accessible to people who are not that interested in fancy computer science concepts, but rather want to read in data, do computations, and write out data/graphs again. Without massive boilerplate or hair pulling.

It seems to be really hard to create smooth user experiences for the common use cases of such complex products. I think people have been trying to oust Matlab for 31 years or so.

Disclaimer: I haven't checked Julia for a few years. Requiring hand reloading of files after editing and no native graph support were a few major problems for a workflow back then.

The scientific community is not going to adopt any new language until most used idioms can be easily found in a quick search and copy-pasted. It is extremely difficult to arrive there.

I totally agree that having dynamic dispatch in the first position of the features list, for example, does not help. But, in my opinion, it is ok for a pre-1.0 language. That is what makes exciting seeing some external help to release a stable version.

What's wrong with dynamic dispatch?

Nothing at all. But, if Julia takes off, I would not expect it to be the main selling point.

It can be a very interesting feature for somebody into language design, but the average Joe working in a lab is not going to learn a completely new language and rewrite all his Matlab code because of it. Most probably, he has not idea what it is or why he would want it.

It was an example of how, at this point, it seems like the web site is more directed towards language developers than potential users.

Actually, I think the main page is directed toward those scientific users who create their own custom projects and/or libraries. This also goes back to your earlier point in that early in a language evolution you need more library and package creators so you can have a broad ecosystem for the more day to day programmers. One example of this need, is the creator of the fftw library (a cornerstone fft implementation in C) wrote several popular packages for Julia. I think there's a talk he gave at the 2014 JuliaCon.

In this regard, multiple dispatch is actually a huge selling point! I've written in Fortran 90 code, C, Python, and enjoyed most of those languages. There is something unique about being able to pull up the source code for almost every operator/function in the language, implemented in that language. Fortran has this, but is much more statically oriented and difficult for quick scripting. Python, well I'm hopeful pypy keeps building momentum. Or perhaps Pyrhon ported to web assembly, in more pure Python.

The hand reloading of files doesn't seem to have changed. I still have to reload my modules after every edit. I'd love someone to show me a better way if it exists.

https://github.com/malmaud/Autoreload.jl

Could this be part of the language? How do actual users get around this issue?

>trying to oust Matlab for 31 years or so.

Apparently Python is having some success there http://blog.mikiobraun.de/2013/11/how-python-became-the-lang...

I still don't 'get' the language. I still have to think like running interpreted code. Definition of methods, scope, is a bit confusing/error-prone for my taste.

http://docs.julialang.org/en/release-0.3/manual/parallel-com...

I am still hopeful. I will give another look at it soon.

There are definitely some scope issues with the distributed computing functionality, see e.g. https://github.com/JuliaLang/julia/issues/13649 for a general tracking issue (also, that is the 0.3 version of the manual).

Julia certainly does have several features worth being excited about: calling C without wrappers, macros, good JIT performance. But I think what really matters is the ecosystem. With python, there is tons of libraries such as Numpy and Scipy for scientific computing, django for web backend, etc. It is unclear whether the community will embrace Julia fully within the next few years.

>With python, there is tons of libraries such as Numpy and Scipy for scientific computing,

I do remember early on when this wasn't the case. Especially when comparing it to Matlab or R. I was discouraged by one professor from learning it. But time has proved otherwise. Julia will likely be the same.

If you compare Julia and Scipy at similar points in their evolution, Julia is far ahead of where Scipy was. And that's while the language itself is still evolving.

It seems like I should mention that we (Julia Computing) are actively hiring. If you think what we're doing is interesting and would like to join in, please do reach out!

Any particular positions, or is this one of those "you'll know if you're able" kind of things?

Well, last time I posted something like this I think I made it sound way too narrow, so I'm trying overly broad this time, to get people who are interested to get in touch, because even if we don't have anything for them at this very moment, we might in the near future.

To narrow down, what we're looking for in the immediate future, anybody with interest in core language development, compilers, tool chain support, etc. Additionally, we will probably be hiring for our applications development team very soon, so if you're interested in data science, stats, etc. and like working with people on solving their challenging problems, please do reach out as well.

Please put effort into a good IDE that leverages the type system! I've been using Julia for two years now, and there's enough code to navigate through that it's becoming difficult to maintain. I'm really starting to miss Java/C#/ even C++ IDEs where you can easily jump to a definition or get a non-fuzzy autocomplete. Not to mention the refactoring support of the IntelliJ products. For a language that promises to handle both the high level and the low level, it really is not scaling well with codebase size. I've also been reassessing my needs and realizing that only about 20% of my codebase is quantitative code, and then with most of the work being sent off to raw CUDA or Theano. So I'm actively considering a better tooled language. I love how expressive Julia is, but that may be getting in the way of tooling. One issue that would help a lot is return type declarations (https://github.com/JuliaLang/julia/issues/1090). Return types would dramatically ease creation of IDE plugins.

That's definitely very high on the TODO list!

Any tidbits about whats in store for the stats ecosystem? Tidyr/Dplyr style workflow? Flexible and Generalized stats MLE/ Bayesian modeling using distributions? Streaming and out of core support? What will the timeline be like?

I'm trying to make an architecture decision right now and this would be helpful (and whet my curiosity :p)

As someone who worked briefly with Julia (My "standard" tools are Haskell and C) this is really awesome news. Way to go Julia team!

Are there small or big tech companies using Julia in production? I'm interested in use cases outside of research labs

StaffJoy (https://www.staffjoy.com/) are using Julia for staff schedule optimization, and a large multinational is using it for train schedule optimization. Its also in use (at least on a trial basis) in the financial sector.

It'd still be a fairly large risk to develop something built-to-last on Julia at this point, so not really the best time for most companies to jump in unless something about Julia really solves a problem they are having.

I've seen a decent amount of chatter over the past year on the Julia mailing list from people integrating Julia into production. It's still in the beta stage, though, so risk-averse corporate users are generally being advised to hold tight until 1.0 is released. This (somewhat outdated) thread should give you some idea of where things are headed: https://groups.google.com/d/topic/julia-users/2mR24E0EtIg/di...

At the last Belgian Julia meetup there were 2 local companies present (10+ employees) that do all their development in Julia: http://www.tangent.works/ http://www.dynactionize.com/ I understand Blackrock has been sponsering the debugger work.

Will julia ever be popular for general computing and Web stuff? It's s till fast for non scientific use cases, has multi threading (in master) and is getting go like channels.

FWIW, I work on Web-related stuff in Julia (like http://shashi.github.io/Escher.jl). I find Julia's type system more natural for general purpose modeling of data than, say, Python's classes. It's also really easy to enforce things like immutability or make stuff blazing fast if one needs to with little effort. Julia's multiple-dispatch is a great companion. On many occasions I've wondered if my code is even complete because it winds up being so small. Another thing to like is the hackability of any code. The standard-library is in Julia, you can look at any function's code from the REPL, and many more developer friendly features.

Jonathan Malmaud, Iain Dunning, Randy Zwitch, Mike Innes (OP) and many others write and maintain general purpose/web-related library code. I'm sure they will agree with some of what I said.

Definitely agree. Obviously a lot of people come to Julia for the performance, but even without that it's just a really nice language to work with. For me the speed is a nice bonus that gives Julia a surprisingly broad range of use – from one-shot scripts to fully-fledged C++ replacement (though obviously for quite a different class of applications than, say, the ones that Rust targets).

It's interesting that people see multiple dispatch as some esoteric computer science-y thing. In reality, it's just a way of organising code and complexity, just like object orientation is – and it has some compelling advantages over OO as well. For me, it's one of the killer features that I really miss in other languages, and it's well worth taking the time to understand it.

It would be great to see people doing more web stuff in Julia, but for the foreseeable future there will be some important caveats. The web libraries (including in Base) just aren't that fleshed out or battle-tested right now, and there's no Google-scale engineering effort making sure that the runtime is reliable over thousands of CPU hours. Whoever dives into that first will have to have a clear sense of the long-term value.

Thanks for your honesty re the web stuff.

I agree multi dispatch is awesome, and python has some implementations of it as well.

http://matthewrocklin.com/blog/work/2014/02/25/Multiple-Disp...

Escher looks really interesting, and a really good match to a hypothetical project I'm planning. So does Julia --- I've done a little scientific computing, mostly in C++, but I'm mostly interested in general-purpose programming, and a quick glance over Julia's feature set makes it look really promising. (Although I'd still like a static type checker.)

If all the logic happens server-side in Escher, what's the responsiveness like? Do you have a live example anywhere?

Are there any plans to transpile Julia into Javascript?

Responsiveness is excellent when your Julia process is on the same machine as the browser - which in itself addresses a large set of use cases scientific computing audience has (such as presentations). When the Julia process is connected over the network, there is obviously a lag between updates. But it's no better or worse than an AJAX/WebSocket application. The intention is to use web components to encapsulate UI components and their behavior (including self-contained animations) and Julia to read from them and update their attributes. So one can switch to writing web components and using them in Escher if responsiveness is really a concern. With the programming model in Escher, it will be easy to hoist some computations to the browser once there is Julia to JavaScript compilation. However, I don't plan to write the transpiler (yet) ;).

So Web Components become the C of the MVC triad, with invisible RPC over the network to Escher for the MV running in Julia? I really like that idea, particularly if the RPC protocol falls back gracefully from WebSocket to long-polling to polling.

Do you know of anything using Escher for public web-facing applications yet?

> Are there any plans to transpile Julia into Javascript?

Since Julia uses LLVM IR, it should be possible to go from LLVM to Javascript using emscripten.

Yes escher is amazing thanks :)

"more natural for general purpose modeling of data than, say, Python's classes"

Can you elaborate? In most cases single dispatch does just fine. Then class = type except much slower

Not the parent, but I agree with Julia types being more natural for many purposes.

It's far easier to create new Julia types for modeling a new domain than Python classes. Genrally, types are much more succinct to declare than classes. They're also type checked and parameterized which allow you to do some rather nice things with an API design that would require a lot of if/else behavior checking in Python classes.

The separation of implementation and data declarations via multiple dispatch makes a large assortment of problems much easier to solve. For example, it's much easier to extend the built in behavior of default Julia types such as dictionaries by adding your own custom method (often on line of code) which is incredibly useful for short data processing script.

There isn't as much web focus in Julia currently, but once the implementation makes it easier to possibly "pre compile" an executable I think there could be a big boom in usage for web engines.

I'm on a mobile device currently and can't really write out more explicit details. Maybe later I can write out a lab example.

0.4 already ships with Go-like channels. http://docs.julialang.org/en/latest/manual/parallel-computin...

I think it will be interesting to see what happens with WebAsm. If Julia targets this at some point (it is based on LLVM, so there is a chance of this), then I think it will start to look quite attractive for various use cases that it isn't currently cornering.

Makes sense. But regardless, the core language is better than go in almost every way (as far as I know)... and it has python like syntax. I wonder if thats enough.

I personally think Julia is technologically superior to a number of popular languages, with a voracious appetite for even more smarts. But you are right that this isn't necessarily enough.

Based on what I've seen so far, I think Julia could eventually break into the Tiobe top 20 languages (it's currently in the top 100). On the other hand, I think this is plenty. As a language currently aimed at (admittedly fairly large) niches that would be an outstanding outcome.

It also makes it fun to work with as a language. It's not just more chicken.

This is something that should be possible eventually. All the Fortran dependencies make it difficult, but as you probably already know, Base will see some trimming and some of these dependencies will become packages (perhaps default, but at least not Base).

I was talking to the WebAsm folks at LLVM Dev a couple of weeks ago and the conclusion was that WebAsm does not yet seem ready to be targeted by us (in particular we would like run-time code loading support for the JIT), but may be there in a year or two.

Yeah I watched one of the recent vids where they presented the latest on WebAsm and I came to the same conclusion. I imagine it is worth looking into and interacting with those guys so that Julia isn't overlooked by them for the time being, and maybe reassess in another year. It was pleasing to see one of the first questions from the audience after that talk was about Julia.

I think that could be a pretty huge deal too. Right now Javascript is being pushed to have enough speed to run applications from 15 years ago in the browser.

If an environment is able to have native speed, run in the browser and still be accessible to the people doing scripting now, it could have pretty large implications.

Go also fits the bill I suppose, but Julia is a much better designed language.

For general computing the question is how to deploy a Julia-based app. For server-side stuff, I suppose it's no worse than Python, but not as easy as Go where you create a standalone executable. For client side, I think it will be quite hard to target browsers or phones since Julia has an unusual kind of just-in-time compilation.

This could be overcome but it's not really Julia's niche which is interactive use of notebooks by scientists or other people who are comfortable writing code.

whenever there is R compared to any other analytics framework, the number one advantage is cited to be CRAN. And the counter is always that "hey python has wheel".

Does anyone think that a dedicated package site for analytics libraries is what is needed ?

From the R documentation:

In the simplest form, an R package is a directory containing: a DESCRIPTION file (describing the package), a NAMESPACE file (indicating which functions are available to users), an R/ directory containing R code in .R files, and a man/ directory containing documentation in .Rd files

But a python wheel is considerably more complicated.

Have you looked at conda and http://anaconda.org? We spent a lot of time curating the most important Python packages for data science into the Anaconda distribution, and conda packages are a great format for distributing complicated software.

this is pretty cool and I think you are on the right track here. but here's the same question here - are you making the process of package creation much easier ?

Because I suspect until you acquire mindshare among the academics (who distribute their research as R code), this will be difficult to scale.

It it is not about a dedicated site for libraries, but more because CRAN is huge and covers most data analytics needs.

I pray they make a breaking change before 1.0 and make it zero based

I doubt it will happen. Zerothly, zero-based isn't as good as 1-based indexing for mathematics and science. And firstly, nobody want to change it.

https://github.com/JuliaLang/julia/issues/558

>zero-based isn't as good as 1-based indexing for mathematics and science

[citation needed]

>nobody want to change it.

Love the claim here, followed by a link that reveals an ongoing controversy. True, the core developers don't want to change it, so it's not going to change. They chose to ignore the protests of many would-be users of the language.

It is worth noting that Fortran, MATLAB, Mathematica / Wolfram Language are all 1-indexed. These are, by far, the most influential and widely-used languages in numerical and mathematical programming for the past ~60 years.

Sure, we should examine the features of languages past, keep the good things, and leave out the bad things.

I thought that Julia was aiming for Python's niche, i.e. good at numerical stuff, but also decent at inter-operating with other languages.

Argh. We were so close to leaving 1-based indexing behind as a historical relic. But now it seems we'll be stuck with it for a while longer. I'm not saying we can do anything about it now. I just want someone to validate my frustration :-)

Frustration validated friend

Not two-based? https://github.com/simonster/TwoBasedIndexing.jl

Actually I'm waiting for 3 based....

"Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration." - Stan Kelly-Bootle.

1 based indexing is very common in many math and statistics oriented languages and frameworks. Since that's the primary target audience for Julia, it makes sense they'd stick with it.

Amen. As stupid as it may sound, this is the only reason I haven't gotten into it ...

No one understands our plight

You're not the only one.

OK, this might sound even stupider, but I feel betrayed by the fact that otherwise good, technical people would voluntarily make such a major mistake, and then defend it so vigorously in the face of so many complaints.

OK, clearly some Julia fans down-voted my comment, perhaps because they misunderstood it. I was trying to say something about human psychology. We can admit that it is silly, but we can't pretend that it doesn't exist. This may be a bigger deal than they realize.

Programming languages are used primarily by humans, which means they must be designed with human psychology in mind. Today, Julia would have (even) more community support if not for this seemingly inconsequential decision. The fact that it seems to be succeeding anyway is largely in spite of, not because of, this design choice.

Congratulations!

By the way, where can I find perf.h in the benchmark suite? perf.c is there but perf.h seems to be missing.

perf.h is generated by the makefile in that directory.

Thanks, I'll try it.

I love Julia. This is great news! :)

Is this going to get us better dataframes and nullable integration?

Yes, that is certainly part of the plan. We will be releasing details in a few weeks.

While some people love dataframes, in both Python and Julia, they feel constraining to me.

Does this mean there will be more features limited to DataFrames?

For example, Gadlfy is nice in many ways but by not using Dataframes it means I have to do my own colors for each data I plot. Some of the statistics features in GLM seem to rely heavily on DFs as well.

Dataframes could be much more useful more broadly if the interface was more consistent, better documented (e.g. still haven't figured out how to instantiate with half my data).

Basically, null-ability is pretty useful feature in many fields, not just statistics. Will the plans include any items to help generalize nullability?

Generalized nullables exist in Base already (http://docs.julialang.org/en/release-0.4/manual/types/#nulla...), unless you had something else in mind.

My question really was ambiguous and more to do with subtle frustration with limitations of the current DF library and the dependence of various nice statistical features in GLM, or plotting in Gadfly, that rely on DataFrames. It's not just nullable types (and also I believe the Nullable arrays in DF are tuned for performance with linear algebra operations, which may not be true for general Nullable arrays). You can get to the features in other ways, but it's easiest to use DataFrames and the documentation is written for DF's. However I think the documentation, scope of functionality for DataFrames, etc is not complete enough for me to quickly use it day-to-day. So I basically just put everything back into arrays and do a couple of custom functions to get my work done. Julia makes this great, but it'd be better to not need to and MATLAB still has many more "easy" functions along these lines.

Reply on news.ycombinator.com