Hacker News Reader

Comment by 3JPLW | Hacker News Reader

Honest question: did you read the post at all? Even the quick summary addresses this.

Chris' whole point is that the biggest benefits of switching to Julia will be felt by the folks that are developing the packages and libraries for others to use. He's advocating that the best way to get you to want to switch isn't incremental language-level features, but rather it's first-in-class domain-specific packages.

This is something that will take time, but Julia's language-level features are uniquely positioned to enable the development of such packages. Chris is extremely productive (and definitely an outlier), but in less than two years he managed to coordinate and build a first-in-class ecosystem for differential equations.

So he's not advocating for you to switch at all — he's advocating for folks to build the packages (like his) that will get you to want to switch.

View on HN

Agreed. A relevant excerpt:

> But for end users throwing together a 100 line script for a data analysis? I don't think that this crowd will actually see as much of a difference between other scripting languages if the packages in the other languages they are using are sufficiently performant (this isn't always true, but let's assume it is). To people who aren't "pros" in the language, it will probably look like it just has a different syntax. It will be a little faster than vectorized code in other languages if code is in type-stable functions, but most of the differences a user will notice will come from the mixture of features and performance of packages. Because of this, I am not sure if marketing the features of the language is actually the best way to approach the general audience. The general audience will be convinced Julia is worthwhile only by the package offering.

(For context, this was after several hundred words of compelling, detailed examples of Julia's language-level advantages).

EDIT: the author then goes on to claim

> that "lack of packages" isn't really a problem with the ecosystem: you can find a great package that does what you're looking for.

with several examples, pointing to poor discoverability, uniqueness, distribution and branding.

He also recommends more practical, use-case-specific how-to guides.

My experience is that Julia promotes lucid and error free code vs R (especially) and Python. For me this matters more and more due in part to the business impact of my 100 line scripts but more significantly due to the impact of other people's 100 line scripts.

This is now happening. The DifferentialEquations Library in Julia seems to be best in class.

More importantly: I can imagine writing algorithmic improvements to it for my use case, which is where I hit a wall with python + scipy/numpy/numba.

I can't go and use my python skill to teach a scipy routine about some feature I need.

This is where Julia really shines. Hopefully as more researcher's realize they can quickly make customized/specialized implementations for their projects it'll help reinforce momentum. It's awesome being able to quickly dig into a library, grok the algorithm and tweak it. Actually could make for some fun hackathons!

I did read the post.

> but rather it's first-in-class domain-specific packages.

You'll note I didn't cite lack of libraries as a reason I'm reluctant to use Julia. I agree that a solid ecosystem is critical for adoption, but my point is that, for me, it's not sufficient to overcome the human/time/cost factors.

Reply on news.ycombinator.com