Hacker News Reader

Comment by oxff | Hacker News Reader

You could reword the question to be about Rust and C/C++ and much of the same would apply.

There are generic answers:

- Refactoring business logic costs. That's why it doesn't happen often.

- Interop between two different codebases (new Julia, old Python) costs (both at an org scale and at programming scale).

- It's a new lang. Hiring new programmers to a new meme language is very risky. You lose that programmer, your project is in trouble.

- You are underrating Python ecosystem strength.

- Python first mover advantage.

There are Julia specific reasons:

- No Julia programmers outside of MIT where as everyone has touched Python.

- Python is "simpler".

- Last I read Julia has some growing pains, like REPL boot times?

View on HN

Also in the ~10 years Julia coders have been arguing Julia is inevitable, I haven’t seen a killer demo that shows something miles better than pandas, pyspark, PyTorch etc. In the same timespan if you look at Rust and Go they were able to capture large market share from compelling OSS projects that made people want to learn the language. Probably the missing piece for the Julia community is to create some library that does something innovative that makes people want to switch just to try it.

The differential equations and maybe the mathematical optimizations packages in Julia are good examples of OSS projects that are far better than their peers in python/R/matlab.

check out JuMP---it's by far the cleanest interface to defining & solving optimization programs I've ever used

I agree that JuMP is great, however most people (outside of academia) aren't solving optimisation problems in a vacuum. Once you start trying to build a useful application with data IO and transformation, configurations, UI, queueing and batch processing, and all that 'boring' stuff around your optimisation program it often gets easier to do it in a different language, like for example python. If nothing else you will have a much larger pool of developers to hire from. You now have the choice between trying to call JuMP from Python and just using a python library like Pyomo, which is almost as good as JuMP.

I believe Julia guys also work on vastly different problems. I don't think they care about typical IT things like go does.

I don't think they care about typical IT things

For a language that builds much of its marketing around solving the "two language problem", it is somewhat ironic that they then turn around and create their own two language problem by ignoring most of the problems most programmers have.

> No Julia programmers outside of MIT

I don't know how true that is but it meshes with my impression. The creators/maintainers seem to have a rather narrow view of who their target audience is and what use cases they have. And it reads to me as though they are unwilling to put any resources into making Julia a general-purpose language. Claims to the opposite don't convince me.

Of course they have the right to make that ecosystem as narrowly focused as they want, but then comparing it with Python is apples and oranges.

WRT boot times, yep it can take a little bit. There are packages like revise [0] or daemon mode [1] that ameliorate this issue while developing the code- and if it is a long running script like DL training, a long startup time will not matter.

https://github.com/timholy/Revise.jl https://github.com/dmolina/DaemonMode.jl

Reply on news.ycombinator.com