This feels like a very strongly worded title for a fairly lacklustre article.
There’s Python the language and “Python the dsl for tensor frameworks”, the former has arguably lost some ground/mindshare to newer, less “hobbled” languages, and the latter exists not by virtue of its own strengths but as the convenient vehicle for frameworks written by 2 enormous corporations.
Julia hasn’t overtaken Pythons ecosystem yet, but how far its come in relatively little time is the real testament to its community-that which the author decries as lacking.
Using weird outdated rankings and citing “that one package that kind of works in very specific circumstances” (Numba) as proof that all Pythons issues are solved and Julia is over is a weak argument at best, and deceptive at worst.
What Julia could really, really benefit from though is some vocal commercial backing-had google chosen to rewrite Tensorflow in Julia I think 2 things would have happened:
1. the project would have actually succeeded and been finished (in a “this is the tensorflow engine now” sense)
2. It would have done absolute wonders for the Julia ecosystem and mindshare and we wouldn’t be having this taudry discussion.
That didn’t happen (unless some tensorflow product managers want a promotion by re-launching a tensorflow rewrite? ;) ) so they need another source of major support IMO.
> What Julia could really, really benefit from though is some vocal commercial backing-had google chosen to rewrite Tensorflow in Julia I think 2 things would have happened
We have the example of "Swift for Tensorflow", which was pitched by Google as the "next-generation platform for machine learning" (that's from their own website) and didn't result in anything meaningful and is now dead as far as I understand. I'm not that convinced that would work better with Julia.
I think even since 2014 there have been many niche technical computing companies supporting development quite successfully. Bigger players definitely would help, but I think most of that at this time is more public/private research money for scientific computing. Hence Julia has many academic contributors (grad students and post docs a likely majority), many of which are now becoming professors and industry leaders.
The post 1.0 world in Julia has been spectacular for development stability. In the early days it was somewhat tiring trying to develop basic foundational libraries, and keep pace with language changes. 1.0 has stabilized things quite a bit, and the forthcoming LTS (sometime this year maybe) I think will really start to button up some of the major issues people have with package load times and installation.
I'm sorry but deep learning is only a very small part of why Python is preferred by data scientists. The fact that Python was the the preferred language is why the enormous corporations wrote bindings to them. Both of these frameworks exist in the Julia ecosystem.
Julia only hit v1.0 in 2018. It's doing pretty well for being so young in my opinion.
All the arguments against Julia are basically that python has a lot of momentum and it takes time and effort to switch to a new language. I think Julia should really seek to displace MATLAB as a near term goal .
I like the idea of Julia but had a poor time making it work (circa october-november 2020) on my Ubuntu laptop. It also refuses to work in environments like repl.it. I feel like it's quite imature still, and that I'll try to pick it up later when it's better.
I'd be very curious to see a source about your claim that Python is slowing down for uses outside of deep learning, I'm pretty sure you just made that up and it's false, not to be blunt
there have been Julia bindings to Tensorflow for a long time, and you can just use the Python ones in Julia with PyCall anyways. People haven't been doing that.
I hope Julia succeeds and replaces the clunky R and numpy+python "ecosystems". Every few months I try to decide to do all my computing on Julia and quit fooling around with lesser environments. And every time I get stuck at the same point: the slow startup time. I want to draw 100 plots per second, by calling the same Julia script on a bash loop 100 times; but this is utterly impossible. Of course, the Julia community has a standard answer to this concern: this is not how you are supposed to use the language. But I don't listen to them, for the best tools are those that perform well doing tasks they were not designed to do. I feel the same dismay when I get stuck at slow loops in Python, and the Python people tell me that I'm not supposed to use loops. Well, this is the main reason that I want to move away from Python and into Julia.
I'm not interested in the implementation details of the language interpreter. The language is already very good, and the libraries are excellent. My main point of friction against using Julia is the slow startup time that forbids its use in a wide variety of contexts. I feel like the best usage of resources for the Julia community would be to spend all available money in hiring a Mike Pall-esque figure to advise them on JIT. Even if it was a part-time or a one-shot hire.
This just seems like such an artificially constructed problem. You just move that loop into Julia and the problem is solved. It is not hard to write shell code in Julia.
I have rewritten complex build scripts in bash into Julia code. It was not very hard and it made everything run way faster despite mostly shelling out to external programs.
I don't know how secret/protected this shell script of yours is, but I'd be willing to have a go at rewriting the loop part in Julia if you showed it to me.
Anyway I do think the startup speed problem can be solved in Julia and they don't need a rockstar advisor to do it. I think the solutions are already pretty well known. It is more of an issue of manpower. Somebody has to put in the hours to do it.
And that is already being done. First time to plot will be twice as fast as it used to be in the next Julia release. Further improvements can be done, but again that requires somebody to put in the hours. Julia does not have access to Google level resources.
Start up time for the interpreter is 0.13s for me: ~ time julia -E "1+1"
What takes time is precompilation of packages and functions - with Julia 1.6 the precompilation is much faster now than before.
Your bash script that calls Julia 100 times is indeed not something that Julia was made for. It excels in many other areas and that's quite fine. I'm okay with plotting in a bash script in Python if it means that I can use Julia for everything else.
While moving the loop into Julia (as others suggested) is probably the better option, an alternative you could consider is DaemonMode: https://github.com/dmolina/DaemonMode.jl
I.e., have a background Julia process so that you only have to pay the precompile cost once.
If you are going to use Julia in one of the absolute worst workflows for how it is designed, you shouldn’t be surprised it doesn’t work well... That said, have you tried using PackageCompiler to add your needed libraries to the system image? This seems to show a factor of 100 speed up for the time to first plot: https://julialang.github.io/PackageCompiler.jl/dev/examples/...
Why do you find R’s ecosystem “clunky”? The Tidyverse is unequaled for its elegance. I come from the CS world, so I’m supposed to like languages like Python, but I really, really like R, mainly for its elegance.
If this is your big setback did you try using a sysimage? The VSCode extension even has a build task for it. To make the sysimage just be in the base environment and then Ctrl+shift+B and select the Juild build sysimage task. The terminal will tell you where its saving the sysimage. It reduced my startup time to unnoticeable (at least to a person used to MATLAB/Python). I am not a bash guru so I don't know how you do it on command line but its a parameter to julia interpreter.
One thing to be aware of is that you're not running a bash script which simply causes julia to "include" stuff, effectively recompiling everything each time the intepreter is run.
As long as you make sure that all the custom code you want to run is in the form of a precompiled module, I think the time required for the interpreter to launch per se shouldn't be that much of a problem.
> I get stuck at the same point: the slow startup time…
The language maintainers steadfastly refuse to include ahead-of-time compilation. They seem super focused on their narrow use case scenario and ignore everything outside that.
Lots of truths there but also colored by someone who evidently has not been a fan of technologies before and seen how it works.
I am not as pessimistic as a Julia fan. Why? Because I have been where this guy is now ever since I was an Amiga user. I was like that with Python, Ruby, Go and a whole other languages.
And what I learned from that is that it takes time. Neither Python, Ruby or Go had success over night. Yet almost all these languages I homed in on in the past have seen what I would call success later.
I was certain Perl would go downhill when it was at its top. I kept argue with Perl fans that Python was a cleaner language that would see more success. Ditto with Ruby. That turned out to be quite accurate.
I said while D looked like a nice replacement for C++, it simply wasn't big enough improvement to go anywhere. That also seems to have been an accurate prediction.
Go on the other hand had a very obvious appeal from the get go. It did something important different and sufficiently better than before while keeping things simple.
I am confident about Julia, because I have not in 20 years since a language with so much potential and so many advantages. You just got to give it time. This reminds me of myself following solar and wind energy in the early 90s and deciding it was not going anywhere.
Ironically I see people like Michael Shellenberger having become a cynic about wind and solar now that it has actually achieved some measure of success. Why? Because it didn't happen fast enough. He poured all his enthusiasm and hope into this industry long before there was reasons to do so.
People have to be aware of the same about Julia. It is not taking over the world any time soon. There is a long road ahead. And I would not define success as getting to Python scale. But if Julia can get to a similar position as Go is today, then I would call that success.
Julia's already making (fairly substantial) in roads. It's just not as visible as Python, since the niche it's occupying is much smaller and out of the way.
This post overlooks that language adoption is something that happens over decades. It's much too early to conclude anything about Julia adoption.
I also think there's way too much focus in the post about Julia taking share away from Python or R. The real market is Matlab programmers, for one and only one reason - Matlab is extremely expensive.
A number of years ago I was talking with a vice president of one of the Federal Reserve banks that told me one of their priorities was to move away from Matlab due to the high and growing licensing costs. The New York Fed has in fact moved much of its code from Matlab to Julia: http://frbny-dsge.github.io/DSGE.jl/latest/ Julia has momentum in parts of economics that have traditionally been heavy users of Matlab: https://quantecon.org/
> This post overlooks that language adoption is something that happens over decades. It's much too early to conclude anything about Julia adoption.
Spot on, I was doing R back in 2005, when it was slowly become more famous. R fist official release was in 1995. Which means that it took R 26 years to get to the point where it is now. If Julia was launched on 2012, its tipping point may come 20 years later, around 2030.
Julia is a language that looks very simple, but the more you use it, the more you realize how complex and unpredictable it is.
I think that Union types do more harm than good (why would you want a function to return Union of int and float instead of compile error? It totally slows down the program)
Array{Number} is totally different from Array{:<Number}, and shouldn’t be allowed, as it is inefficient.
1-based indexing was a mistake, and I have seen it emitting inefficient code in the PTX compiler.
But the worst and hardest part is the rule/heuristic for multiple dispatch: it’s so complex, that it isn’t even documented. It should probably throw more errors and be predictable instead of trying to be so smart.
The most software I write, the more I am convinced that 1-based indexing is what most languages should be using, either the exception being the very specific use-case of needing to track offsets by hand for some reason. 1-based indexing is so much easier to reason about, but zero based indexing is seen as “the one true way” due its ubiquity, and not because it’s actually better.
> and I have seen it emitting inefficient code in the PTX compiler.
Have you raised this with the devs? This seems like something worth raising as an issue.
Returning a Union of int or float isn't that useful but the point is that Julia is a dynamic language, and if there was no implicit union type it would have to just box the return type into an "Any" box, which actually slows down the program (the union here will cause functions to have two optimized versions, one for int and one for float instead of a generic dynamic one for Any). If it had a compile error for every function that can return more than one type it would make the language even more restrictive than some static languages.
Though for intentional uses of unions, most of the time I use a union of a success type or an error type, or a union of a type and null, or a union of type and missing. They could all be special cases, but I don't see the point of not being just one mechanism.
Is the post only based on TIOBE? The same index that currently ranks JavaScript below Visual Basic and SQL below Assembly? That ranking is off by so much that anyone who takes it seriously loses at lot of credibility from the start.
I'm not entirely on board with the Julia hype train but they certainly got some things right and both the ecosystem and the community are healthy and growing. Julia doesn't need to replace a bunch of other languages immediately to be successful. Implying that the language is dead by using the word post-mortem is just demonstrably false.
I'm also skeptical of TIOBE but the post is not based only on that... The author seems to have been very active with the language, and even drafted a book on the subject. It seems to me that he may have a good feel or intuition for the scene; while this is not very scientific, it is miles ahead of basing an analysis on TIOBE alone. I'm going to be lurking this thread for potential counter-arguments though.
TIOBE is known to change drastically when google decides to change its search engine algorithm.
Also TIOBE is heavily squeued by the sheer number of publications containing a keyword and it does not really evaluate the content or the quality of these publications.
I've checked google trends and for Julia programming language they are showing slow increase, at least that's my guess as generic search for Julia (choosing programing language suggestion) shows decline while searching for "Julia programming language" shows increase.
Stackoverflow trends show show some increase (https://insights.stackoverflow.com/trends?tags=julia), it was also high on the "most loved" list - 6th place just after Kotlin and Go, but it is very low in the "wanted" category. Seems those who use it like the language, but outside that circle there is no much interest.
By calling it post-mortem the author already showed his level of stupidity (or absence of morality). Julia is a new language that have to compete with languages that accumulated a huge ecosystem of developments and continue to grow. Of course Julia is losing in comparison right now.
I don't see any value in this article. It's a wasted time.
Honestly, I learned Python in 1995, and used it where I could for CGI script programming and scripts into the early 2000s, and tried to get jobs programming it throughout that time with no success at all. Throughout that time, Perl was still in use all over but declining, PHP was growing like an unpleasant weed, and it seemed Ruby was ascendant for the "cool" stuff... but Python wasn't cool, most hiring managers had never heard of it, and while Google used it, that was pretty much it for large company support.
Then while I wasn't looking (I lost interest in dynamically typed languages and focused on modern static typed languages) it became insanely popular -- and I actually got pushed out of a lead role at a job in part because folks wanted to rewrite into Python something we did in Java/Scala. Python popularity skyrocketed over the next 10 years. Numpy had something to do with it but also many other factors, not a lot of them initiated by the Python community itself, or by Guido.
All this to say, language popularity is fickle and not terribly predictable. Prognosticating like this is silly.
Julia is nice. Kinda wish I had a job where I got to play with it. Which is about how I was with Python, 20 years ago.
Julia v1 was released in 2018. It's currently about as popular as elixir. Is the author really complaining that it hasn't over taken as the lingua franca in two years? Python is over 20 years old and it's only hit it's stride in popularity over the last 5.
1. There's plenty of niches. I don't think anyone is pushing Julia as the new general purpose programming language.
2. Ecosystems and network effects are real, but if you conquer a niche, you can still win. R's doing fine.
3. Specialists seem to like Julia and are writing good stuff in it. I don't see why that attraction shouldn't bring more users in. Indeed, it's still rising in PYPL, as linked by another comment.
> We were all going to heaven, and that right soon. The language wars would end, we would finally get a lingua franca for anywhere code performance mattered, Julia would take over the TIOBE Index, and we’d all be home for tea and medals.
This type of thinking is so alien to me. A mainstream language like python has its appeals (like a large quantity of docs and many libraries), but TIOBE ranking? Language wars? Who cares about that? At the end of the day a language is a tool, nothing else (Matlab is a good example).
While I don't think this piece was well argued I must agreee with the sentiment that Julia is somewhat of a disappointment, at least for me personally.
Last year I started learning Rust and wanted to use it instead of C++ in the future. I since have programmed quite a lot in it, contributed to open source software and absolutely have fallen in love with it.
So this year I wanted to replace my default scripting language (Python) with Julia and potentially use it for my simulations or ML in the future.
But every time I take a stab at Julia - last time around the release of version 1 - it never really stops feeling foreign. Everything is slightly unintuitive and weird. Also, learning Julia made me realize how amazing Rust's learning resources are. Besides the official book and the API docs (with an amazing template), there are a lot of great third party and actively maintained resources likes cheats.rs. I never felt Rust was unituitive or hard to learn. Even if some concepts are unique, the resources do a great job of introducing them to you. While Julia's learning website lists an exercism course, its manual and a bunch of video lectures.
I think selling Julia as a Python competitor raises wrong expectations. Julia may look easy or Python-like but is far more difficult to use IMHO. They may be similar in terms of applications but at least in how they feel to use, they are very different.
I still haven't given up but whereas I speak very highly and enthusiastically of Rust and recommend it everywhere (yes I am one of those people), I cannot see myself doing the same for Julia in the future.
Ps.: I wish there was a book club-like way of learning programming languages and discussing progress with friends. That would make learning even more fun.
This article starts off with the following premise: “one of Julia’s original promises was to take over other languages in terms of popularity” (paraphrased).
I think this post is a bit immature. These things take time. Julia should just keep on striving for excellence and I'm sure it doesn't need me saying so. I've spent the last decade writing python professionally for web backend software engineering: it is a fantastic language for getting out of your way and allowing you to think and build what you want. And things like pattern matching show that it's still taking significant steps forward. But, languages should be statically typed: modern compilers offer too much benefit to development workflows to turn this down. So you can try to patch typing on to a dynamic language but my impression is that mypy is a hack compared to what was delivered to javascript in the form of typescript.
I suspect that people will eventually swing back towards statically typed languages for the development tooling. Especially as the future needs more programmers and more help for programmers to build things correctly vs the early 21st century era of hackers writing untyped python in vim.
Above comments are mainly aimed at web backend. I'm aware of Python's dominance in data science and machine learning but perhaps ultimately the same will hold true there -- that humanity will ultimately go for solutions that keep developers on the rails more. (Jupyter notebooks are a disaster when it comes to building correct solutions: no encouragement to use version control; out of control invisible global state etc.)
I think claims of Julia's death are premature. I used it all throughout grad school shortly after it was released, and there are things the language does so much better than any other language I know of that I find it hard to imagine it just disappearing into the ether. The only way I can think of it really dying off is if more popular languages absorb the best features of Julia, making it redundant.
It's hard to make inroads into Python's domain because of the strong networks effects, but I think if one or two major companies onboard the language, then we might see a snowball effect.
Personally, I'd like to see a version of Julia with all static typing and Rust-like memory management. That would be pretty close to the perfect language for me.
I agree that Julia can't stack up to Python in terms of a data science / statistics domain. But in everything people use MATLAB for, Julia actually has the upside in many of the qualities discussed in the article: Community, Package Ecosystem, annoying licensing bureaucracy etc etc.
I've always viewed Julia as a language for scientific computing professionals [1].
The article pronounces Julia's death only based on popularity relative to other languages. Yet, it's not clear what the author is comparing it to.
The comparisons I see are MATLAB and FORTRAN, to which Julia seems to stand third in TIOBE Index [2] that the author is using. The author doesn't seem to focus on this.
The author mentions
> Julia’s target user is harder to define. I have struggled with this while writing Learn Julia.
I wonder if it may not be the case that the author has developed his own notion of what Julia ought to be. And I'll agree that Julia may have failed his grand vision to displace large parts of Python, but I do not think that that vision is based in reality. Python users that want to use frameworks written in other, faster languages (like C++) will forever continue to use Python and enjoy the vast libraries that it offers which aren't centred around scientific computing.
[1]: There seems to be a list on https://juliacomputing.com/. Arguably their needs might be very different than the author's. But I can't say because the article's arguments are not based on technical shortcomings.
[2]: In the TIOBE Index (as a proxy for popularity) MATLAB gets 1.04%, Fortran 0.83%, and Julia 0.41% (GNU's Octave, the main FOSS Matlab competitor, is nowhere to be seen). I do not know what these percentages mean though https://www.tiobe.com/tiobe-index/
[+] [-] FridgeSeal|5 years ago|reply
There’s Python the language and “Python the dsl for tensor frameworks”, the former has arguably lost some ground/mindshare to newer, less “hobbled” languages, and the latter exists not by virtue of its own strengths but as the convenient vehicle for frameworks written by 2 enormous corporations.
Julia hasn’t overtaken Pythons ecosystem yet, but how far its come in relatively little time is the real testament to its community-that which the author decries as lacking.
Using weird outdated rankings and citing “that one package that kind of works in very specific circumstances” (Numba) as proof that all Pythons issues are solved and Julia is over is a weak argument at best, and deceptive at worst.
What Julia could really, really benefit from though is some vocal commercial backing-had google chosen to rewrite Tensorflow in Julia I think 2 things would have happened: 1. the project would have actually succeeded and been finished (in a “this is the tensorflow engine now” sense) 2. It would have done absolute wonders for the Julia ecosystem and mindshare and we wouldn’t be having this taudry discussion. That didn’t happen (unless some tensorflow product managers want a promotion by re-launching a tensorflow rewrite? ;) ) so they need another source of major support IMO.
[+] [-] dgellow|5 years ago|reply
We have the example of "Swift for Tensorflow", which was pitched by Google as the "next-generation platform for machine learning" (that's from their own website) and didn't result in anything meaningful and is now dead as far as I understand. I'm not that convinced that would work better with Julia.
[+] [-] sjkelly|5 years ago|reply
The post 1.0 world in Julia has been spectacular for development stability. In the early days it was somewhat tiring trying to develop basic foundational libraries, and keep pace with language changes. 1.0 has stabilized things quite a bit, and the forthcoming LTS (sometime this year maybe) I think will really start to button up some of the major issues people have with package load times and installation.
[+] [-] apples2apples|5 years ago|reply
[+] [-] rademacher|5 years ago|reply
All the arguments against Julia are basically that python has a lot of momentum and it takes time and effort to switch to a new language. I think Julia should really seek to displace MATLAB as a near term goal .
[+] [-] square_usual|5 years ago|reply
[+] [-] prionassembly|5 years ago|reply
[+] [-] make3|5 years ago|reply
[+] [-] make3|5 years ago|reply
[+] [-] enriquto|5 years ago|reply
I'm not interested in the implementation details of the language interpreter. The language is already very good, and the libraries are excellent. My main point of friction against using Julia is the slow startup time that forbids its use in a wide variety of contexts. I feel like the best usage of resources for the Julia community would be to spend all available money in hiring a Mike Pall-esque figure to advise them on JIT. Even if it was a part-time or a one-shot hire.
[+] [-] socialdemocrat|5 years ago|reply
I have rewritten complex build scripts in bash into Julia code. It was not very hard and it made everything run way faster despite mostly shelling out to external programs.
I don't know how secret/protected this shell script of yours is, but I'd be willing to have a go at rewriting the loop part in Julia if you showed it to me.
Anyway I do think the startup speed problem can be solved in Julia and they don't need a rockstar advisor to do it. I think the solutions are already pretty well known. It is more of an issue of manpower. Somebody has to put in the hours to do it.
And that is already being done. First time to plot will be twice as fast as it used to be in the next Julia release. Further improvements can be done, but again that requires somebody to put in the hours. Julia does not have access to Google level resources.
[+] [-] dunefox|5 years ago|reply
What takes time is precompilation of packages and functions - with Julia 1.6 the precompilation is much faster now than before.
Your bash script that calls Julia 100 times is indeed not something that Julia was made for. It excels in many other areas and that's quite fine. I'm okay with plotting in a bash script in Python if it means that I can use Julia for everything else.
[+] [-] celrod|5 years ago|reply
I.e., have a background Julia process so that you only have to pay the precompile cost once.
[+] [-] krull10|5 years ago|reply
[+] [-] AuthorizedCust|5 years ago|reply
[+] [-] newswasboring|5 years ago|reply
[+] [-] tpoacher|5 years ago|reply
As long as you make sure that all the custom code you want to run is in the form of a precompiled module, I think the time required for the interpreter to launch per se shouldn't be that much of a problem.
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] nojito|5 years ago|reply
Parameterized reporting in R/knitr is unmatched in the industry
[+] [-] classified|5 years ago|reply
The language maintainers steadfastly refuse to include ahead-of-time compilation. They seem super focused on their narrow use case scenario and ignore everything outside that.
[+] [-] socialdemocrat|5 years ago|reply
I am not as pessimistic as a Julia fan. Why? Because I have been where this guy is now ever since I was an Amiga user. I was like that with Python, Ruby, Go and a whole other languages.
And what I learned from that is that it takes time. Neither Python, Ruby or Go had success over night. Yet almost all these languages I homed in on in the past have seen what I would call success later.
I was certain Perl would go downhill when it was at its top. I kept argue with Perl fans that Python was a cleaner language that would see more success. Ditto with Ruby. That turned out to be quite accurate.
I said while D looked like a nice replacement for C++, it simply wasn't big enough improvement to go anywhere. That also seems to have been an accurate prediction.
Go on the other hand had a very obvious appeal from the get go. It did something important different and sufficiently better than before while keeping things simple.
I am confident about Julia, because I have not in 20 years since a language with so much potential and so many advantages. You just got to give it time. This reminds me of myself following solar and wind energy in the early 90s and deciding it was not going anywhere.
Ironically I see people like Michael Shellenberger having become a cynic about wind and solar now that it has actually achieved some measure of success. Why? Because it didn't happen fast enough. He poured all his enthusiasm and hope into this industry long before there was reasons to do so.
People have to be aware of the same about Julia. It is not taking over the world any time soon. There is a long road ahead. And I would not define success as getting to Python scale. But if Julia can get to a similar position as Go is today, then I would call that success.
[+] [-] gbrown|5 years ago|reply
[+] [-] zhdc1|5 years ago|reply
[+] [-] hatmatrix|5 years ago|reply
[+] [-] bachmeier|5 years ago|reply
I also think there's way too much focus in the post about Julia taking share away from Python or R. The real market is Matlab programmers, for one and only one reason - Matlab is extremely expensive.
A number of years ago I was talking with a vice president of one of the Federal Reserve banks that told me one of their priorities was to move away from Matlab due to the high and growing licensing costs. The New York Fed has in fact moved much of its code from Matlab to Julia: http://frbny-dsge.github.io/DSGE.jl/latest/ Julia has momentum in parts of economics that have traditionally been heavy users of Matlab: https://quantecon.org/
[+] [-] xtracto|5 years ago|reply
Spot on, I was doing R back in 2005, when it was slowly become more famous. R fist official release was in 1995. Which means that it took R 26 years to get to the point where it is now. If Julia was launched on 2012, its tipping point may come 20 years later, around 2030.
[+] [-] higerordermap|5 years ago|reply
[+] [-] xiphias2|5 years ago|reply
I think that Union types do more harm than good (why would you want a function to return Union of int and float instead of compile error? It totally slows down the program)
Array{Number} is totally different from Array{:<Number}, and shouldn’t be allowed, as it is inefficient.
1-based indexing was a mistake, and I have seen it emitting inefficient code in the PTX compiler.
But the worst and hardest part is the rule/heuristic for multiple dispatch: it’s so complex, that it isn’t even documented. It should probably throw more errors and be predictable instead of trying to be so smart.
[+] [-] FridgeSeal|5 years ago|reply
The most software I write, the more I am convinced that 1-based indexing is what most languages should be using, either the exception being the very specific use-case of needing to track offsets by hand for some reason. 1-based indexing is so much easier to reason about, but zero based indexing is seen as “the one true way” due its ubiquity, and not because it’s actually better.
> and I have seen it emitting inefficient code in the PTX compiler.
Have you raised this with the devs? This seems like something worth raising as an issue.
[+] [-] ddragon|5 years ago|reply
Though for intentional uses of unions, most of the time I use a union of a success type or an error type, or a union of a type and null, or a union of type and missing. They could all be special cases, but I don't see the point of not being just one mechanism.
[+] [-] superbcarrot|5 years ago|reply
I'm not entirely on board with the Julia hype train but they certainly got some things right and both the ecosystem and the community are healthy and growing. Julia doesn't need to replace a bunch of other languages immediately to be successful. Implying that the language is dead by using the word post-mortem is just demonstrably false.
[+] [-] arcturus17|5 years ago|reply
[+] [-] txdv|5 years ago|reply
Also TIOBE is heavily squeued by the sheer number of publications containing a keyword and it does not really evaluate the content or the quality of these publications.
[+] [-] piokoch|5 years ago|reply
Stackoverflow trends show show some increase (https://insights.stackoverflow.com/trends?tags=julia), it was also high on the "most loved" list - 6th place just after Kotlin and Go, but it is very low in the "wanted" category. Seems those who use it like the language, but outside that circle there is no much interest.
[+] [-] dandanua|5 years ago|reply
I don't see any value in this article. It's a wasted time.
[+] [-] st3fan|5 years ago|reply
[+] [-] cmrdporcupine|5 years ago|reply
Then while I wasn't looking (I lost interest in dynamically typed languages and focused on modern static typed languages) it became insanely popular -- and I actually got pushed out of a lead role at a job in part because folks wanted to rewrite into Python something we did in Java/Scala. Python popularity skyrocketed over the next 10 years. Numpy had something to do with it but also many other factors, not a lot of them initiated by the Python community itself, or by Guido.
All this to say, language popularity is fickle and not terribly predictable. Prognosticating like this is silly.
Julia is nice. Kinda wish I had a job where I got to play with it. Which is about how I was with Python, 20 years ago.
[+] [-] vsskanth|5 years ago|reply
Some of their AD and differential equation libs are state of the art.
Being the best at a certain niche will attract users who will eventually stay and contribute.
I use python a lot but it can't beat Julia for simulating an ODE. So I use it too
[+] [-] tsdlts|5 years ago|reply
[+] [-] dash2|5 years ago|reply
1. There's plenty of niches. I don't think anyone is pushing Julia as the new general purpose programming language.
2. Ecosystems and network effects are real, but if you conquer a niche, you can still win. R's doing fine.
3. Specialists seem to like Julia and are writing good stuff in it. I don't see why that attraction shouldn't bring more users in. Indeed, it's still rising in PYPL, as linked by another comment.
[+] [-] nromiun|5 years ago|reply
This type of thinking is so alien to me. A mainstream language like python has its appeals (like a large quantity of docs and many libraries), but TIOBE ranking? Language wars? Who cares about that? At the end of the day a language is a tool, nothing else (Matlab is a good example).
[+] [-] ruph123|5 years ago|reply
So this year I wanted to replace my default scripting language (Python) with Julia and potentially use it for my simulations or ML in the future. But every time I take a stab at Julia - last time around the release of version 1 - it never really stops feeling foreign. Everything is slightly unintuitive and weird. Also, learning Julia made me realize how amazing Rust's learning resources are. Besides the official book and the API docs (with an amazing template), there are a lot of great third party and actively maintained resources likes cheats.rs. I never felt Rust was unituitive or hard to learn. Even if some concepts are unique, the resources do a great job of introducing them to you. While Julia's learning website lists an exercism course, its manual and a bunch of video lectures.
I think selling Julia as a Python competitor raises wrong expectations. Julia may look easy or Python-like but is far more difficult to use IMHO. They may be similar in terms of applications but at least in how they feel to use, they are very different.
I still haven't given up but whereas I speak very highly and enthusiastically of Rust and recommend it everywhere (yes I am one of those people), I cannot see myself doing the same for Julia in the future.
Ps.: I wish there was a book club-like way of learning programming languages and discussing progress with friends. That would make learning even more fun.
[+] [-] stellalo|5 years ago|reply
Honestly, I cannot find such promise in the original announcement: https://julialang.org/blog/2012/02/why-we-created-julia/
Ex falso quodlibet
[+] [-] da39a3ee|5 years ago|reply
I suspect that people will eventually swing back towards statically typed languages for the development tooling. Especially as the future needs more programmers and more help for programmers to build things correctly vs the early 21st century era of hackers writing untyped python in vim.
Above comments are mainly aimed at web backend. I'm aware of Python's dominance in data science and machine learning but perhaps ultimately the same will hold true there -- that humanity will ultimately go for solutions that keep developers on the rails more. (Jupyter notebooks are a disaster when it comes to building correct solutions: no encouragement to use version control; out of control invisible global state etc.)
[+] [-] Xcelerate|5 years ago|reply
It's hard to make inroads into Python's domain because of the strong networks effects, but I think if one or two major companies onboard the language, then we might see a snowball effect.
Personally, I'd like to see a version of Julia with all static typing and Rust-like memory management. That would be pretty close to the perfect language for me.
[+] [-] ramboldio|5 years ago|reply
[+] [-] qaq|5 years ago|reply
[+] [-] stellalo|5 years ago|reply
It’s multiple dispatch, how did the almost-author-of-a-book-on-the-language not get that?
[+] [-] peey|5 years ago|reply
The article pronounces Julia's death only based on popularity relative to other languages. Yet, it's not clear what the author is comparing it to.
The comparisons I see are MATLAB and FORTRAN, to which Julia seems to stand third in TIOBE Index [2] that the author is using. The author doesn't seem to focus on this.
The author mentions
> Julia’s target user is harder to define. I have struggled with this while writing Learn Julia.
I wonder if it may not be the case that the author has developed his own notion of what Julia ought to be. And I'll agree that Julia may have failed his grand vision to displace large parts of Python, but I do not think that that vision is based in reality. Python users that want to use frameworks written in other, faster languages (like C++) will forever continue to use Python and enjoy the vast libraries that it offers which aren't centred around scientific computing.
[1]: There seems to be a list on https://juliacomputing.com/. Arguably their needs might be very different than the author's. But I can't say because the article's arguments are not based on technical shortcomings.
[2]: In the TIOBE Index (as a proxy for popularity) MATLAB gets 1.04%, Fortran 0.83%, and Julia 0.41% (GNU's Octave, the main FOSS Matlab competitor, is nowhere to be seen). I do not know what these percentages mean though https://www.tiobe.com/tiobe-index/
[+] [-] systems|5 years ago|reply
While this clearly doesn't seem to impact its adoption, or its community from creating great things
For the new comer to the language, the scoping rules just gives a bad feeling for the language, I wish they fix it in future versions
check my github issue if you want to know more what I mean by off putting scoping rules https://github.com/JuliaLang/julia/issues/37187