6 ms·

Congrats to the Julia team. I am a python developer who has dabbled with Julia but it never stuck for me. I think Julia was built by academics for other acade

Congrats to the Julia team. I am a python developer who has dabbled with Julia but it never stuck for me. I think Julia was built by academics for other academics running innovative high performance computing tasks. It excels at the intersection of 1) big data, so speed is important, and 2) innovative code, so you can't just use someone else's C package. Indeed, Julia's biggest successful applications outside academica closely resemble an academic HPC project (eg Pumas). I think it will continue to have success in that niche. And that's not a small niche! Maybe it's enough to support a billion dollar company. But most of us in industry are not in that niche. Most companies are not dealing with truly big data, on our scale, it is cheaper to expand the cluster than it is to rewrite everything in Julia. Most who ARE dealing with truly big data, do not need innovative code; basic summary statistics and logistic regression will be good enough, or maybe some cloud provider's prepackaged turn key neural nets scale out training system if they want to do something fancy. I think for Julia to have an impact outside of academia (and academia-like things in industry) it will need to develop killer app packages. The next PyTorch needs to be written in Julia. Will that happen? Maybe! I hope so! The world would be better off with more cool data science packages. But I think the sales pitch of "it's like Pandas and scikit but faster!" is not going to win many converts. So is Jax, Numba, Dask, Ray, Pachyderm, and the many other attempts within the Python community of scaling and speeding Python, that require much less work and expense on my part for the same outcome. Again, congrats to the team, I will continue to follow Julia closely, and I'm excited to see what innovative capabilities come out of the Julia ecosystem for data scientists like me.

krastanov 5y ago
There is another important niche I am particularly excited about: programming language research geeks and lisp geeks. The pervasive multiple-dispatch in Julia provides such a beautiful way to architecture a complicated piece of code.
- ampdepolymerase 5y ago
  Those two niches don't pay. They are effectively useless outside of the occasional evangelism on HN.
  - pjmlp 5y ago
    Who do you think puts money to action on LLVM, GCC, Swift, Rust, .NET (C#, F#, VB), Scala,....?
  - trenchgun 5y ago
    Money does not create code, humans do.
    - xiaodai 5y ago
      Money don't do jobs, humans do. You see the logical fallacy in ur argument now?
  - UncleOxidant 5y ago
    There's a Compiler and Runtime Engineer position listed at https://juliacomputing.com/jobs/ https://juliacomputing.com/jobs/ which presumably pays money.
- pjmlp 5y ago
  Yep, that is my niche.
- vletal 5y ago
  > The pervasive multiple-dispatch in Julia provides such a beautiful way to architecture a complicated piece of code. On the other hand it makes function discovery almost impossible [1]. Combined with the way how 'using' keyword exports a predefined subset of functions, this makes the language doomed from larger adoption outside of academia at least as long as there is no superb autocompletion and IDE support. [1] https://discourse.julialang.org/t/my-mental-load-using-julia-is-much-higher-than-e-g-in-python-how-to-reduce-it/18902/4 https://discourse.julialang.org/t/my-mental-load-using-julia...
  - mccoyb 5y ago
    Have you seen Shuhei Kadowaki's work on JET.jl (?) If you're curious: https://github.com/aviatesk/JET.jl https://github.com/aviatesk/JET.jl This may seem more about performance (than IDE development) but Shuhei is one of the driving contributors behind developing the capabilities to use compiler capabilities for IDE integration -- and indeed JET.jl contains the kernel of a number of these capabilities.
systemvoltage 5y ago
Great summary. I've worked with scientists that love Julia and more power to them. As a software engineer, there are still rough edges in productionizing Julia (yes, I know there are a few examples of large scale production code). As soon as you take Julia out of notebooks and try to build moderately complex apps with it, you realize how much you miss Python. Having used Julia for last 4 years and having to maintain that code in production environment, I am strongly convinced that Julia has a niche but it is not going to be a contestant to Python/Java/C++ depending on the use case. Which really is a shame - I want one goddamn language to rule them all. I want that and tried to give a fair chance to Julia.
- amkkma 5y ago
  > As soon as you take Julia out of notebooks and try to build moderately complex apps with it, you realize how much you miss Python Why's that? What features or lack thereof of Julia contribute to that experience?
  - systemvoltage 5y ago
    There is too much to talk about and I’d want to give an objective impression with examples in a blog post, but one of the major grips I have is how little information Julia provides you with stack traces. Debugging production problems with absolutely zero clue of what/where the problem might be is one of the most frustrating aspects. I’ve spent so many hours debugging Julia using print statements. Debugger is janky, Juno/Atom support is not very good. Nothing feels polished and robust. Dependencies break all the time. We are stuck with Julia 1.2 and too much of an undertaking to go to latest version. Package management is an absolute disaster - this is the case with Python but Julia is worse. Julia Registry has many issues (compat errors). Testing and mocking is also underwhelming. I think startup times have improved but still not very developer-friendly. Sorry not an objective answer you’re looking for. There also things that Python has such as excellent web-dev ecosystem and system libs that are missing in Julia. Python has everything. Want to generate a QR code image? Easy in Python. Want to create PDF reports with custom ttf fonts? A breeze in Python.
    - 5y ago
jjoonathan 5y ago
> The next PyTorch needs to be written in Julia. Will that happen? Maybe! I hope so! The Two Language Problem makes this more likely than one might think. Those high level python packages that plaster over python's many mediocrities have to be written and maintained by someone, and while extremistan bears the brunt of the pain and has done a remarkable job shielding mediocristan, it's extremistan that gets to decide which language to use for the next killer app. Of course, python has more inertia than god, so it won't go quietly.
- stillwater919 5y ago
  Your comment almost reads like a poem
ssivark 5y ago
> do not need innovative code I think this is a good deciding factor. Not just for “big data”. In my experience, with its combination of flexibility and raw speed, Julia makes implementing new algorithms (from scratch) a breezy experience. The strong research/academic presence in the community also helps towards encouraging decent Julia libraries for a lot of cutting edge work. So if you are working in an area where that could make a significant difference, it’s an excellent reason to use Julia. > will need to develop killer app packages. The next PyTorch needs to be written in Julia. Will that happen? If enough cutting-edge work happens in Julia, it’s likely that a few great tools/platforms will emerge from that. We’re already seeing that in the scientific modeling ecosystem (as an example), with Differential Equations infrastructure and PumasAI.
queuebert 5y ago
> The next PyTorch needs to be written in Julia. If a major company would pick up Flux.jl and fill out the ecosystem that would be AMAZING. PyTorch and Tensorflow feel like duct tape and chewing gum all day, every day.

krastanov 5y ago

There is another important niche I am particularly excited about: programming language research geeks and lisp geeks. The pervasive multiple-dispatch in Julia provides such a beautiful way to architecture a complicated piece of code.

ampdepolymerase 5y ago
Those two niches don't pay. They are effectively useless outside of the occasional evangelism on HN.
- pjmlp 5y ago
  Who do you think puts money to action on LLVM, GCC, Swift, Rust, .NET (C#, F#, VB), Scala,....?
- trenchgun 5y ago
  Money does not create code, humans do.
  - xiaodai 5y ago
    Money don't do jobs, humans do. You see the logical fallacy in ur argument now?
- UncleOxidant 5y ago
  There's a Compiler and Runtime Engineer position listed at https://juliacomputing.com/jobs/ https://juliacomputing.com/jobs/ which presumably pays money.
pjmlp 5y ago
Yep, that is my niche.
vletal 5y ago
> The pervasive multiple-dispatch in Julia provides such a beautiful way to architecture a complicated piece of code. On the other hand it makes function discovery almost impossible [1]. Combined with the way how 'using' keyword exports a predefined subset of functions, this makes the language doomed from larger adoption outside of academia at least as long as there is no superb autocompletion and IDE support. [1] https://discourse.julialang.org/t/my-mental-load-using-julia-is-much-higher-than-e-g-in-python-how-to-reduce-it/18902/4 https://discourse.julialang.org/t/my-mental-load-using-julia...
- mccoyb 5y ago
  Have you seen Shuhei Kadowaki's work on JET.jl (?) If you're curious: https://github.com/aviatesk/JET.jl https://github.com/aviatesk/JET.jl This may seem more about performance (than IDE development) but Shuhei is one of the driving contributors behind developing the capabilities to use compiler capabilities for IDE integration -- and indeed JET.jl contains the kernel of a number of these capabilities.

systemvoltage 5y ago

Great summary. I've worked with scientists that love Julia and more power to them. As a software engineer, there are still rough edges in productionizing Julia (yes, I know there are a few examples of large scale production code). As soon as you take Julia out of notebooks and try to build moderately complex apps with it, you realize how much you miss Python. Having used Julia for last 4 years and having to maintain that code in production environment, I am strongly convinced that Julia has a niche but it is not going to be a contestant to Python/Java/C++ depending on the use case. Which really is a shame - I want one goddamn language to rule them all. I want that and tried to give a fair chance to Julia.

amkkma 5y ago
> As soon as you take Julia out of notebooks and try to build moderately complex apps with it, you realize how much you miss Python Why's that? What features or lack thereof of Julia contribute to that experience?
- systemvoltage 5y ago
  There is too much to talk about and I’d want to give an objective impression with examples in a blog post, but one of the major grips I have is how little information Julia provides you with stack traces. Debugging production problems with absolutely zero clue of what/where the problem might be is one of the most frustrating aspects. I’ve spent so many hours debugging Julia using print statements. Debugger is janky, Juno/Atom support is not very good. Nothing feels polished and robust. Dependencies break all the time. We are stuck with Julia 1.2 and too much of an undertaking to go to latest version. Package management is an absolute disaster - this is the case with Python but Julia is worse. Julia Registry has many issues (compat errors). Testing and mocking is also underwhelming. I think startup times have improved but still not very developer-friendly. Sorry not an objective answer you’re looking for. There also things that Python has such as excellent web-dev ecosystem and system libs that are missing in Julia. Python has everything. Want to generate a QR code image? Easy in Python. Want to create PDF reports with custom ttf fonts? A breeze in Python.
  - 5y ago

jjoonathan 5y ago

> The next PyTorch needs to be written in Julia. Will that happen? Maybe! I hope so! The Two Language Problem makes this more likely than one might think. Those high level python packages that plaster over python's many mediocrities have to be written and maintained by someone, and while extremistan bears the brunt of the pain and has done a remarkable job shielding mediocristan, it's extremistan that gets to decide which language to use for the next killer app. Of course, python has more inertia than god, so it won't go quietly.

stillwater919 5y ago
Your comment almost reads like a poem

ssivark 5y ago

> do not need innovative code I think this is a good deciding factor. Not just for “big data”. In my experience, with its combination of flexibility and raw speed, Julia makes implementing new algorithms (from scratch) a breezy experience. The strong research/academic presence in the community also helps towards encouraging decent Julia libraries for a lot of cutting edge work. So if you are working in an area where that could make a significant difference, it’s an excellent reason to use Julia. > will need to develop killer app packages. The next PyTorch needs to be written in Julia. Will that happen? If enough cutting-edge work happens in Julia, it’s likely that a few great tools/platforms will emerge from that. We’re already seeing that in the scientific modeling ecosystem (as an example), with Differential Equations infrastructure and PumasAI.

queuebert 5y ago

> The next PyTorch needs to be written in Julia. If a major company would pick up Flux.jl and fill out the ecosystem that would be AMAZING. PyTorch and Tensorflow feel like duct tape and chewing gum all day, every day.