Hacker News new | past | comments | ask | show | jobs | submit login

> How is Julia different than Pypy

Well, no GIL for a start, which is a pretty strong selling point when running on several dozen of cores at once.

> I don't see the plus value in Julia compared to Python or Java

I don't see how you can put Python and Java in the same bag.

> It will still be slower than C/C++

Not that much https://news.ycombinator.com/item?id=17204750

> probably less portable

Who cares? 99.99% of HPC are Linux clusters anyway. And Julia runs on macOS and Linux, that cover the overwhelming majority of the concerned users.

> and all the legacy libraries have to be rewritten in Julia.

https://docs.julialang.org/en/v0.6.0/manual/calling-c-and-fo...

> I don't know where to place that effort in the grand scheme of things.

According to you interrogations, browsing their website would be a good start.

https://julialang.org




Thank you for the detailed answer. Here's my feedback on some of the points :

> I don't see how you can put Python and Java in the same bag.

What I meant is that the trio Python/Java/C is ubiquitous for many people in both entreprises and scientific fields, from embedded to web servers. It allows for great reusability of codes and people's skills.

> Who cares? 99.99% of HPC are Linux clusters anyway. And Julia runs on macOS and Linux, that cover the overwhelming majority of the concerned users.

But will Julia be able to output the necessary instructions for the future hardware accelerators, which could be totally different architectures? I'm thinking of all the new neural networks cores, the DSP, fpgas, and heterogeneous computing from different rival vendors. It seems Julia is deeply dependant of LLVM.

> and all the legacy libraries have to be rewritten in Julia.

> https://docs.julialang.org/en/v0.6.0/manual/calling-c-and-fo....

If you have to reuse C and Fortran libraries, why not just use Python which can do the same, or even Lua, or Lisp. Python is already the defacto language to glue libraries together onto a higher level algorithm.


> But will Julia be able to output the necessary instructions for the future hardware accelerators, which could be totally different architectures? I'm thinking of all the new neural networks cores, the DSP, fpgas, and heterogeneous computing from different rival vendors. It seems Julia is deeply dependant of LLVM.

Yes. Watch HN in the next week or two for an announcement that may interest you ;).


Oh gosh, you're making me impatient now :)


> What I meant is that the trio Python/Java/C is ubiquitous for many people in both entreprises and scientific fields, from embedded to web servers. It allows for great reusability of codes and people's skills.

That's true. But it's also Academia's role to try (and fail or succeed) at developing and evaluating new solutions; and in the case of Julia, I have to concede I'm pretty excited to see where they will be going. The solution of mixing the ‶glue″ and the ‶high performances″ languages in a single one while still letting people call upon older C ABI libs is a little revolution in this context.

> If you have to reuse C and Fortran libraries, why not just use Python which can do the same, or even Lua, or Lisp. Python is already the defacto language to glue libraries together onto a higher level algorithm.

Because Julia is far faster, and because no GIL.

Of course, like in every other tech, what floats my boat doesn't necessarily floats your, so maybe for your usecase Python/Lisp/Lua/Ruby/... is better.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: