Hacker News Reader

Comment by sleavey | Hacker News Reader

Having never used it, I wonder, could Julia replace Python as the de-facto standard in scientific computing and data analysis? What does it do well?

View on HN

Python is not the de-facto standard to my knowledge. It really depends on the field and task. R is huge in my research area, MatLab is king in some other areas, and Fortran is still being used for large-scale number crunching. Will Julia replace all these? That's the ambition but I doubt it's going to happen. For instance, R has a unique and vast ecosystem of extension packages. It would take decades to build something comparable in Julia.

If there were pandas, sklearm and Keras equivalents (don’t even need feature compleye, just mostly there) I would abandon python literally today.

- pandas :: your choice of DataFrames or JuliaDB

- scikitlearn :: no single package since skl is a meta-package of sorts, but most of the stuff is there spread across the eco-system

- Keras :: checkout Flux or Mocha

Welcome to Julia! Also take a look here [1] for more package that might be to your interest.

[1] https://github.com/svaksha/Julia.jl/blob/e305195ab60e6859e78...

Pandas actually has many alternatives. Including JuliaDB, DataFrames, and Pandas.jl

Keras also many. TensorFlow.jl, Flux, Mocha, KNet, MxNet.

Sklearn is all there but bring it together will take a bit. Some important parts are in JuliaML org. Also Clustering.jl, and MultiariateStats.jl (For DR) the classifiers are really scattered. I'ld love to fix that if I had time.

You're really making my day here! :D

Where I am people are really pushing out of the MATLAB/Python world into Julia. It's tailor made for scientific computing in a way that none of the others are.

Clearly we're talking decades, but I am already realizing pay-offs from the switch to Julia (from Python) in my domain.

Rackauckas pointed out an amazing example recently [1]:

https://discourse.julialang.org/t/differentialequations-jl-a...

You have a library that implements calculating with numbers with uncertainties. You have the differential equations library. They don't know about each other but you can use the former in the latter to solve differential equations with uncertainties with a whole bunch of advanced solving algorithms.

This sort of power, having an ecosystem like Python that combines in a performant way, will be huge.

[1] http://www.stochasticlifestyle.com/why-numba-and-cython-are-...

Having migrated my Python+Fortran code to Julia in October last year I would say yes. For reasons why I would read the documentation basics, check the benchmarks and play with a bit of code. I was sceptical when my advisor originally suggested it but now I dread the thought of scientific software in any other language.

IMO industry will start switching once a Scikit-learn or Caret equivalent for Julia shows up. PyCall.jl and RCall.jl should take care of everything else until the rest of the ecosystem catches up.

Last time I tried to move all my stuff to Julia I ran into issues with the data frame equivalent package. It seemed the devs and community were in debate as to whether Julia and the dataframe should be more pure numerical focused a la matlab or python/pandas and appropriate for data analysis. As such null values were handled weird or not supported, which made it practically useless for all of my use cases.

I’d love to know if that was still the case though, because I’d so much rather use Julia than Python for my analysis and stuff.

Actually 0.7 made a big step in resolving these issues:

https://julialang.org/blog/2018/06/missing

Like music to my ears!

Not necessarily, I recommend the talk given today at JuliaCon by the head of an actuary research group at Aviva - a very large insurance company:

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

They've been using it sucessfully for quite some time.

Python has so much inertia at this point that it seems unlikely to happen in the near future.

Probably not quite to the scale as C/C++ vs rust for systems programming, but a similar idea. Rust has all these great features but most people doing systems know C, all their code is already in C, and so the cost of switching is very high.

Not that a switch will never happen, it's just that no matter how good Julia is any transition is going to take a long time. (I do think Julia is a good language though)

I hope so - Julia has been one of the most refreshing software experiences I've tried, and that was only Julia 0.4.

It compiles to native code via JIT on the standard implementation, no need to re-write code in C.

The object system is close to CLOS with support for multi-dispatch.

The object system is IMO the best feature of Julia. All functions are multiple dispatch, so the expression problem is more or less solved. This makes it easy to do things like allowing users to define custom sparse matrix types and use them seamlessly with other matrices and vectors. It makes it easy to abstract away implementation details in a much greater way than Python or R.

My only fleeting experience with Julia is in a Numerical Analysis Course three years ago... but it has 1-indexed arrays so its good for scaring away all people who are programmers before analysts/scientists!

Really though, I think it has a better type system and a syntax that translates easier to mathematical expressions. Other than that, Python's breadth of packages will be hard to overcome.

You get used to the 1-based indexing pretty quick. It's a non-issue. 1-based indexing is the standard in math, and also Matlab and Fortran. For the primary use-case of Julia, it makes sense. Julia REALLY tries to be easy for Matlab users, who still dwarf Python users in science.

> Julia REALLY tries to be easy for Matlab users

Not so much currently:

https://discourse.julialang.org/t/why-eye-has-been-deprecate...

I know it is not the default, but this package has no overhead over the default arrays according to recent benchmarks, and provides 0-indexed arrays: https://github.com/JuliaArrays/OffsetArrays.jl

I confess, not being the default is a big thing. I've definitely had times where I thought "this would be easier with 0 indexed arrays", but it can then be harder to commit to adding a dependency and making that change vs just adding awkward looking "+1"s to all the indexes. Coming from math/science, there's lots of times 1-indexing makes more sense / is more familiar. It's normal there to start counting from 1, so it can be easier to translate.

It's non uncommon in mathematics to index from zero as well.

Even among scientists there are people who don't like 1-indexed arrays (me, one data point)! However, Julia 0.7 and 1.0 have the keyword "begin" so that you can basically program arrays in an index-agnostic way.

When I started programming, all my languages with exception of Assembly used 1-indexing, so no, it doesn't scare all programmers.

I thought that was what R was meant to do?

But, yes, Julia was designed with something like that in mind from what I recall.

R is actually only 3 years younger than Python (25yrs and 28yrs respectively).

And the array data type in Python is just 23 years old.

Reply on news.ycombinator.com