Julia ranks in the top 5 most loved programming languages for 2022(logankilpatrick.medium.com)
logankilpatrick.medium.com
Julia ranks in the top 5 most loved programming languages for 2022
https://logankilpatrick.medium.com/breaking-julia-ranks-in-the-top-5-most-loved-programming-languages-for-2022-6cb7740240e1
65 comments
Even with only a bit over 1,000 total responses, yes you can make such statements. More isn’t necessarily magically better when it comes to sample sizes. In both cases, we are making inferences about what the total population thinks about the languages based on a subset of survey responses.
Now, is there reason to think that there is bias in these survey results? That is certainly a possibility.
To a degree I agree with you in that the framing of “most loved” could be approached better with niche vs widespread languages. There are a lot of people who self select into small languages, vs languages in widespread use, so perhaps noting the relative usage would be helpful in contextualizing what people think.
Now, is there reason to think that there is bias in these survey results? That is certainly a possibility.
To a degree I agree with you in that the framing of “most loved” could be approached better with niche vs widespread languages. There are a lot of people who self select into small languages, vs languages in widespread use, so perhaps noting the relative usage would be helpful in contextualizing what people think.
I believe what the parent is getting at isn't that the sample size for Julia is too small to conclude anything, it's that the differences in sample size between Python and Julia reflect differences in sizes of the total user base. That means Python is more likely to be used by people who have no other choice, whereas more Julia users are using it because they like it. If Julia grew to be as popular as Python, it might no longer be loved by as large a proportion of its users.
well - also self selection. People who respond Julia have (almost certainly) not been made to use it. Python... definitely not so much.
Disclaimer: I don't really like Python, but I don't dread it. Disclaimer 2: I quite like Julia but every time I have tried to drop Python to use it I have had to go back to Python.
Disclaimer: I don't really like Python, but I don't dread it. Disclaimer 2: I quite like Julia but every time I have tried to drop Python to use it I have had to go back to Python.
> I quite like Julia but every time I have tried to drop Python to use it I have had to go back to Python.
Is that because of library availability or something to do with the interpreter?
Is that because of library availability or something to do with the interpreter?
The issue is not with sample size but population size.
The issue isn't sample size (nor many of the other things people are pointing out).
First off we're ultimately talking about ordinal data here and even the Evan Miller post in another comment misses that ordinal data is fundamentally tricky. Everyone is talking about the p("most loved") but that makes assumptions that "most loved" has a consistent meaning.
The problem with ordinal data is that the only thing that's known about it is an ordering of the values, but the distance between values is undefined. That is the difference between a 5 star and a 4 star review is not necessarily that same a between a 2 and 1 star review. This means that you can't meaningfully average these.
However there is an even bigger problem, which is what I think parent is feeling here, and that is selection bias. It's very hard to compare the average rating of a film such as Star Wars and a film like Cannibal Holocaust. The first is a general audience film and the later is an extremely niche subset of gore horror. If you show Cannibal Holocaust to the general population it will receive wildly lower rating than Star Wars. However if you were to do a survey of all people who have a DVD of Star Wars and a DVD of Cannibal Holocaust, I wouldn't be at all surprised if Cannibal Holocaust was more loved. There are plenty of people that have Star Wars on their shelf and feel 'meh' about it, but almost no one who owns Cannibal Holocaust on DVD that doesn't feel like it is an essential horror classic.
The annoying truth is, there's really no statistical way to solve this. There are some solutions to better modeling ordinal data (you could for example, transform this problem into an ordinal regression problem). But ultimately "loved" is not really a measurable thing, so we're always looking for imperfect proxies.
First off we're ultimately talking about ordinal data here and even the Evan Miller post in another comment misses that ordinal data is fundamentally tricky. Everyone is talking about the p("most loved") but that makes assumptions that "most loved" has a consistent meaning.
The problem with ordinal data is that the only thing that's known about it is an ordering of the values, but the distance between values is undefined. That is the difference between a 5 star and a 4 star review is not necessarily that same a between a 2 and 1 star review. This means that you can't meaningfully average these.
However there is an even bigger problem, which is what I think parent is feeling here, and that is selection bias. It's very hard to compare the average rating of a film such as Star Wars and a film like Cannibal Holocaust. The first is a general audience film and the later is an extremely niche subset of gore horror. If you show Cannibal Holocaust to the general population it will receive wildly lower rating than Star Wars. However if you were to do a survey of all people who have a DVD of Star Wars and a DVD of Cannibal Holocaust, I wouldn't be at all surprised if Cannibal Holocaust was more loved. There are plenty of people that have Star Wars on their shelf and feel 'meh' about it, but almost no one who owns Cannibal Holocaust on DVD that doesn't feel like it is an essential horror classic.
The annoying truth is, there's really no statistical way to solve this. There are some solutions to better modeling ordinal data (you could for example, transform this problem into an ordinal regression problem). But ultimately "loved" is not really a measurable thing, so we're always looking for imperfect proxies.
Thanks for the thoughtful reply - I don't have a stats background, but it didn't quite sit right with me. The movie example you give here really puts it in perspective.
This article gives a handy method to account for exactly what you're asking https://www.evanmiller.org/how-not-to-sort-by-average-rating...
I find the conclusion to a really silly solution if you need to explain it to anyone. My preferred answer is a basyesian average. That is, everything gets n votes for the average score by default, and you just sort by the average rating.
That's really cool, thanks for sharing! I particularly appreciate the SQL snippet.
When YouTube still showed dislikes, some justin bieber video was simultaneously the most liked and most disliked video of all. i quite like to think of python as the justin bieber of programming languages.
I'd say that since way less people use Julia than Python, there is likely to be more people among the sample who are Julia enthusiasts. While Python on the other hand is used extensively because it is a previously established and much more popular language, there are likely to be more people that use it just for that reason. The perception is that there's no reason to use Julia if you don't like it, but you may have to use Python even if you don't like it.
Moreover, these kinds of rankings often conflate user satisfaction with hype (which isn't to say a hyped language isn't a good one, but just that "I love it" can mean "I love what I've heard about it, but I haven't used it"). I'm not sure about SO's love/dread in particular.
If 11,156 dreaded Python, but only 298 dreaded Julia, doesn't that make Julia look a whole lot better?
I'd also imagine that people using Julia in 2022 are doing so because they wanted to use Julia. They're probably senior and they have a lot of flexibility in tooling selection. Whereas I know A LOT of people using Python and JavaScript against their will.
I’m an incorrigible Julia booster, but I don’t see much real value in these statistics or rankings. Always consider the data source, bias due to self-selection, etc. Results from surveys of any kind are rarely informative.
We demand confidence intervals!!
try the following R code:
fisher.test(matrix(c(786, 298, 22999, 11156), nrow = 2))
#> Fisher's Exact Test for Count Data
#>
#>data: matrix(c(786, 298, 22999, 11156), nrow = 2)
#>p-value = 0.0003266
#>alternative hypothesis: true odds ratio is not equal to 1
#>95 percent confidence interval:
#> 1.116046 1.469612
#>sample estimates:
#>odds ratio
#> 1.279435
fisher.test(matrix(c(786, 298, 22999, 11156), nrow = 2))
#> Fisher's Exact Test for Count Data
#>
#>data: matrix(c(786, 298, 22999, 11156), nrow = 2)
#>p-value = 0.0003266
#>alternative hypothesis: true odds ratio is not equal to 1
#>95 percent confidence interval:
#> 1.116046 1.469612
#>sample estimates:
#>odds ratio
#> 1.279435
I love Julia so much and I almost exclusively do my physics research in Julia (modulo the time I need to help with C++ legacy stuff)
So I want to raise this caveat as a Julia lover: the love% is highly correlated to why people are using the language, because Julia is not so popular, it's unlikely people (students) are forced to use it, thus less Dread.
But I think Julia deserves to be loved AND widely used.
So I want to raise this caveat as a Julia lover: the love% is highly correlated to why people are using the language, because Julia is not so popular, it's unlikely people (students) are forced to use it, thus less Dread.
But I think Julia deserves to be loved AND widely used.
I think this applies to Rust as well. I like Rust and would like to use it more, but I think (because it's so good) more people have heard good things about it than have actually used it in anger, which has the potential to inflate these rankings. Similarly, I love Go, and back in the day it probably performed very well on these ratings when everyone only knew it as "the language that promises easy concurrency" (you know, 5 minutes before news broke that it had a garbage collector, no generics, and it wasn't thus a True Systems Language / No One Can Build Useful Software With It at which point everyone got out their pitchforks).
But I think Julia deserves to be loved AND wildly used.
I see what you did there
I see what you did there
> it's unlikely people (students) are forced to use it, thus less Dread.
Which also likely explains MatLab being absolute last.
Which also likely explains MatLab being absolute last.
To be fair to the students, there are a lot of extremely frustrating things about Matlab, which is okay for short bits of 2-dimensional matrix arithmetic (“matrix laboratory” is an apt name for the language), but quickly sours if your needs extend even a tiny bit into anything requiring 3+ dimensions or data structures other than numerical arrays or data types other than real/complex double-precision floats, or if you need to debug anything, or even if you just want to put more than one function in a file. (Also it is a source-unavailable black box that costs an arm and a leg.) The general unpleasantness of Matlab explains much of Julia’s popularity.
(On the flip side, Matlab was a great tool and a significant achievement when introduced in the 70s. Cleve Moler did a lot of great work that advanced the state of art in numerical analysis and applied mathematics. We can celebrate that history while still trying to avoid Matlab whenever possible in 2022.)
(On the flip side, Matlab was a great tool and a significant achievement when introduced in the 70s. Cleve Moler did a lot of great work that advanced the state of art in numerical analysis and applied mathematics. We can celebrate that history while still trying to avoid Matlab whenever possible in 2022.)
While the one function per file thing is certainly frustrating, I still find numpy to be way more annoying. I think it's api is very inconstent and it's treatment of 1d arrays leads to a huge number of bugs.
I'm not sure what your complaint is about lack of data structures. I recall using classes and structs and maps and cell arrays regularly without issue in matlab.
I'm not sure what your complaint is about lack of data structures. I recall using classes and structs and maps and cell arrays regularly without issue in matlab.
Have you ever tried to write/debug/use a nontrivial class-based Matlab library? Or one that made serious use of structs, maps, cell arrays (or heck, strings)?
There’s really no comparison to any programming language from the past 20 years. Lots of sharp API corners and inexplicable inconsistencies and limitations, gnarly performance overhead even if you know what you are doing and you’re being careful, mediocre debugging tools. It feels like every feature was just bolted on piecemeal and ad-hoc (which they probably were).
If you only need to do mix a few scattered lines of non-numerical code in the middle of a big otherwise matrix-heavy project, it’s not too bad. But I feel pretty sorry for anyone trying to use it as a general-purpose programming language.
There’s really no comparison to any programming language from the past 20 years. Lots of sharp API corners and inexplicable inconsistencies and limitations, gnarly performance overhead even if you know what you are doing and you’re being careful, mediocre debugging tools. It feels like every feature was just bolted on piecemeal and ad-hoc (which they probably were).
If you only need to do mix a few scattered lines of non-numerical code in the middle of a big otherwise matrix-heavy project, it’s not too bad. But I feel pretty sorry for anyone trying to use it as a general-purpose programming language.
Funny that you say that, one thing that always annoyed me about Julia (and I tried to like it, but ultimately never found a convincing argument to switch) is that they followed matlab conventions so much.
1. Making multiplication between arrays a matrix multiplication by default, not element wise. Not everyone is doing LA, the fact that you have to consider different operators /modifiers for multiplying scalars and elementwise vectors adds significant mental overhead if 99.99% of all your multiplication should be elementwise.
2. Why oh why the '.' as the broadcasting operator. Anything (except maybe the komma) would have been better. The '.' is just way too easy to overlook. When I was still helping students with their matlab code (I now use if you want my help as a incentive for them to learn python) the problem was in 90% of the cases a missing dot somewhere. The bad thing is that it breaks in weird ways, you just get nonsensical results without a crash. This is related to point 1, because most of what we do is elementwise so you have to put dots everywhere.
3. Indexing starting with 1. This one is actually very minor and really just a personal preference.
I understand why Julia did this, i.e. to attract the matlab users, but it makes it so much less appealing for those of us who have moved on already due to matlabs shortcomings.
1. Making multiplication between arrays a matrix multiplication by default, not element wise. Not everyone is doing LA, the fact that you have to consider different operators /modifiers for multiplying scalars and elementwise vectors adds significant mental overhead if 99.99% of all your multiplication should be elementwise.
2. Why oh why the '.' as the broadcasting operator. Anything (except maybe the komma) would have been better. The '.' is just way too easy to overlook. When I was still helping students with their matlab code (I now use if you want my help as a incentive for them to learn python) the problem was in 90% of the cases a missing dot somewhere. The bad thing is that it breaks in weird ways, you just get nonsensical results without a crash. This is related to point 1, because most of what we do is elementwise so you have to put dots everywhere.
3. Indexing starting with 1. This one is actually very minor and really just a personal preference.
I understand why Julia did this, i.e. to attract the matlab users, but it makes it so much less appealing for those of us who have moved on already due to matlabs shortcomings.
The argument for `*` being matrix multiplication is in many ways a lot more consistent (especially the way Julia does it where `exp(M)` is a matrix exponential. Julia treats matrices as objects in their own right with an algebra on them (specifically as elements of the general linear group). It does take some getting used to if you're coming from numpy, or another framework where arrays are just considered as data storage, but IMO, the result is more consistent and useful.
Good grief, I hated MatLab. I had to use that in my electrical engineering degree. What a user-hostile piece of software.
Top 10 as per [1]:
It may be just me, but both the list and the ranking are really weird. Not just apples to oranges, more like apples to toilet paper.
Rust 87%
Elixir 75%
Clojure 75%
TypeScript 73%
Julia 73%
Python 67%
Delphi 66%
Go 65%
SQL 64%
C# 63% It may be just me, but both the list and the ranking are really weird. Not just apples to oranges, more like apples to toilet paper.
Delphi vs Rust.
Delphi is a language everyone is forced to use at work, horrible legacy projects vs Rust and Elixir that basically noone is using at work and all hobby,fun projects. BUT at the same time Lisp and Haskell are also rank very low despite being mostly hobby projects type languages.
Delphi is a language everyone is forced to use at work, horrible legacy projects vs Rust and Elixir that basically noone is using at work and all hobby,fun projects. BUT at the same time Lisp and Haskell are also rank very low despite being mostly hobby projects type languages.
Whoever was ranking Delphi was probably doing that based on their past experience from 20 years ago.
Delphi evolved from TurboPascal and TP was one of most universally and genuinely adored tools in the late 80s - early 90s. And it was in fact beautifully functional and super fast. Delphi retained most of that even if it acquired some bloat in the process, and it also inherited a lot of goodwill. It sort of dwindled into near non-existence since then, but the whiff of its awesomeness lingers.
Delphi evolved from TurboPascal and TP was one of most universally and genuinely adored tools in the late 80s - early 90s. And it was in fact beautifully functional and super fast. Delphi retained most of that even if it acquired some bloat in the process, and it also inherited a lot of goodwill. It sort of dwindled into near non-existence since then, but the whiff of its awesomeness lingers.
Delphi is certainly loved as RAD tool for enterprise desktop applications on Windows, the only real alternatives are .NET and Qt.
Rust has nothing to match any of those three in 2022, maybe in a couple of years.
Rust has nothing to match any of those three in 2022, maybe in a couple of years.
Yeah, it makes no sense. Look at APL, about 50/50. Who actually knows APL who doesn’t love it? I suspect the people who “dread” APL just think it’s scary and have never programmed in it seriously.
Has there been any response to "Why I no longer recommend Julia" [1]. It has made me hesitate to dive into this language.
[1] https://yuri.is/not-julia/
[1] https://yuri.is/not-julia/
I considered making one but didn't really feel it was worth it; in fact, there's a bit of a catch-22 in that Julia folks seem to have accumulated a reputation of "not being able to take criticism", so I think most folks in the community just decided to take it this time. That said, if there's popular demand for a "rebuttal" of sorts I would be happy to come up with one after I get a few more things off my desk (among I'm sure many others who may be more qualified).
I think it's safe to say that Julia has a notable ability to polarize people -- you tend to either love it or hate it. Personally, I can hardly even imagine using anything else at this point.
I think it's safe to say that Julia has a notable ability to polarize people -- you tend to either love it or hate it. Personally, I can hardly even imagine using anything else at this point.
> I think it's safe to say that Julia has a notable ability to polarize people -- you tend to either love it or hate it. Personally, I can hardly even imagine using anything else at this point.
I think this is not true, many of us (including myself) were really intrigued by Julia and really wanted to like it, but came away a bit underwhelmed.
It certainly has some neat ideas and people do very interesting stuff with it. That said it is certainly not the panacea of "write code which is as easy as python but gets you the speed of C".
What is causing the current (small) backlash is the community being so strongly fanboyish and are still selling this uncritical view. Compared Julia fans, Rust proponents sound like they hate their language.
The advocacy is becoming quite off putting.
I think this is not true, many of us (including myself) were really intrigued by Julia and really wanted to like it, but came away a bit underwhelmed.
It certainly has some neat ideas and people do very interesting stuff with it. That said it is certainly not the panacea of "write code which is as easy as python but gets you the speed of C".
What is causing the current (small) backlash is the community being so strongly fanboyish and are still selling this uncritical view. Compared Julia fans, Rust proponents sound like they hate their language.
The advocacy is becoming quite off putting.
I think some people may expect it to be something that it's not. I'm probably a broken clock on this point but it's really a fundamentally different programming paradigm (dispatch-oriented) than most anything else, and organizing your code in a way that expects and works well with that paradigm (and what that means for how code is compiled) is, in my opinion, critical. If that works well for your problems or the way you like to think about things then great, if not then you may come away quite frustrated.
Try to fight against dispatch and squeeze Julia into OO or functional or etc. paradigms and you're Gonna Have a Bad Time, in my opinion.
Try to fight against dispatch and squeeze Julia into OO or functional or etc. paradigms and you're Gonna Have a Bad Time, in my opinion.
It generated lots of discussion on the Julia discourse: https://discourse.julialang.org/t/discussion-on-why-i-no-lon...
Well, out of the issues mentioned, the ones still open can be categorized as (1) aliasing problems with mutable vectors https://github.com/JuliaLang/julia/issues/39385 https://github.com/JuliaLang/julia/issues/39460 (2) not handling OffsetArrays correctly https://github.com/JuliaStats/StatsBase.jl/issues/646, https://github.com/JuliaStats/StatsBase.jl/issues/638, https://github.com/JuliaStats/Distributions.jl/issues/1265 https://github.com/JuliaStats/StatsBase.jl/issues/643 (3) bad interaction of buffering and I/O redirection https://github.com/JuliaLang/julia/issues/36069 (4) a type dispatch bug https://github.com/JuliaLang/julia/issues/41096
So if you avoid mutable vectors and OffsetArrays you should generally be fine.
As far as the argument "Julia is really buggy so it's unusable", I think this can be made for any language - e.g. rand is not random enough, Java's binary search algorithm had an overflow, etc. The fixed issues have tests added so they won't happen again. Maybe copying the test suites from libraries in other languages would have caught these issues earlier, but a new system will have more bugs than a mature system so some amount of bugginess is unavoidable.
So if you avoid mutable vectors and OffsetArrays you should generally be fine.
As far as the argument "Julia is really buggy so it's unusable", I think this can be made for any language - e.g. rand is not random enough, Java's binary search algorithm had an overflow, etc. The fixed issues have tests added so they won't happen again. Maybe copying the test suites from libraries in other languages would have caught these issues earlier, but a new system will have more bugs than a mature system so some amount of bugginess is unavoidable.
I would recommend Chris Rackauckas' response in the original thread.
Did you check the comments on hackernews?
https://news.ycombinator.com/item?id=31396861
https://news.ycombinator.com/item?id=31396861
Sorry I meant any response that mitigates these criticisms.
I recently found myself wishing I had the multiple dispatch I’ve heard about in Julia, and it got me curious, especially after seeing the survey results. (It was python, and I was trying to balance clean clear mypy errors with pythonic code in a particular way). Doing primarily ML, I’ll be really interested to see julia’s ecosystem evolve.
Does anyone have any commentary on how mature it is in terms of sharp edges on a typical julia newbie project? (e.g. setup, tooling, onboarding docs, library docs, error messages, etc)
Does anyone have any commentary on how mature it is in terms of sharp edges on a typical julia newbie project? (e.g. setup, tooling, onboarding docs, library docs, error messages, etc)
The compilation style of the language could be rather frustrating for first time users: The way the language works is to compile (not interpret) methods on the first time they are encountered at runtime. This can cause quite large latency on first launch (it is extremely fast after that). On the positive side, this style enables all the magic of amazingly fast code (even when using complex abstractions) and fast multiple dispatch. Basically, I am warning you that you will need to find a new style of develop-edit-run for your code, in order to avoid frustrating latency (e.g. using tools like Revise.jl).
Otherwise, I am in love with this language and with all the tools developed in it. It is the best language for "scientific" machine learning (i.e. autodiff and optimization over weird models that can hardly be represented as neural nets). It is quite a bit less mature for typical ML.
Otherwise, I am in love with this language and with all the tools developed in it. It is the best language for "scientific" machine learning (i.e. autodiff and optimization over weird models that can hardly be represented as neural nets). It is quite a bit less mature for typical ML.
Why does each language's Loved + Dreaded = 100%?
Most languages I've worked with I neither love nor dread. Clicked through to the SO survey results and even skimmed the methodology section, but I couldn't find what question they asked to get these numbers.
Most languages I've worked with I neither love nor dread. Clicked through to the SO survey results and even skimmed the methodology section, but I couldn't find what question they asked to get these numbers.
I had a similar thought as I was reading it. I remember a previous version of the survey, or of a similar survey, that was conducted differently. In that version people could indicate, in effect, that they neither loved or dreaded it, or both loved and dreaded it.
I remember in the survey reports it was discussed because there were some languages that were on both the "most loved" list and "most dreaded" lists. I want to say C and R (and maybe Haskell??) were examples of that but it's been awhile.
I'm not sure why they made them mutually exclusive, as it muddies things a bit.
I remember in the survey reports it was discussed because there were some languages that were on both the "most loved" list and "most dreaded" lists. I want to say C and R (and maybe Haskell??) were examples of that but it's been awhile.
I'm not sure why they made them mutually exclusive, as it muddies things a bit.
The survey question is included under the chart, and implies that users were only given a checkbox as input. "Loved" and "Dreaded" seem to mean, of people who currently use the language, which percentage would like to continue doing so and which would not.
A "no strong opinion" option may have provided some interesting nuance.
A "no strong opinion" option may have provided some interesting nuance.
The question they asekd is at the bottom of the table. Most loved is definited as (people who want to keep using the language) / (people who have used the language in the past year). Dreaded is 1-loved.
This is an example of cherry picking the facts for marketing at best and an extremely disingenuous blog post at worst.
Julia is no where on the map in almost every metric (no commonly used libraries, no web frameworks, etc), and even in the other metrics where Julia is listed it is WAAAAYYY down there. Below Lua. Below Haskell. It is even below MATLAB. If that's not a scathing indictment of Julia, I don't know what is.
Even in the "most loved" category, if you look at all the respondents who "want" to use Julia, it is no where near the top.
I know Logan is the community advocate for Julia, but picking just the one slice of data where Julia looks appealing and blogging about just that is very off-putting. If anything, this survey should be a call for introspection or reflection, on what and why Julia is not taking off despite people loving the language. Or a well-rounded blog post on the various metrics where Julia is listed would be much more appreciated. In fact, a blog post on what the plans are to solve static compilation, making first time to plot better, building better tooling, features planned for Julia 2.0 would be much more appreciated than this kind of shameless advertising.
Julia is no where on the map in almost every metric (no commonly used libraries, no web frameworks, etc), and even in the other metrics where Julia is listed it is WAAAAYYY down there. Below Lua. Below Haskell. It is even below MATLAB. If that's not a scathing indictment of Julia, I don't know what is.
Even in the "most loved" category, if you look at all the respondents who "want" to use Julia, it is no where near the top.
I know Logan is the community advocate for Julia, but picking just the one slice of data where Julia looks appealing and blogging about just that is very off-putting. If anything, this survey should be a call for introspection or reflection, on what and why Julia is not taking off despite people loving the language. Or a well-rounded blog post on the various metrics where Julia is listed would be much more appreciated. In fact, a blog post on what the plans are to solve static compilation, making first time to plot better, building better tooling, features planned for Julia 2.0 would be much more appreciated than this kind of shameless advertising.
Blog posts (and especially public forum posts and github issue discussions) on the topics you care about are quite common. It seems very normal and unsurprising that a community advocate would cheerlead survey results like this and let others discuss the topics you mentioned (and they do). I am also surprised by your "scathing indictment" comment. Julia released its first stable version 3 years ago. MATLAB/R/Haskell have existed for decades. Julia has 30% of the user-share of MATLAB (and same order of magnitude comparisons to R and Haskell). This seems like a pretty big achievement already, especially when you see where these other languages are on the "love" scale.
Don't get me wrong, there is plenty that needs to further be fixed with Julia, but it is pretty easy to see that there is serious progress on all these tasks when you look at their forum and github. For a language conceived 10 years ago and having its first stable release 3 years ago, this seems quite amazing to me.
Don't get me wrong, there is plenty that needs to further be fixed with Julia, but it is pretty easy to see that there is serious progress on all these tasks when you look at their forum and github. For a language conceived 10 years ago and having its first stable release 3 years ago, this seems quite amazing to me.
> It seems very normal and unsurprising that a community advocate would cheerlead survey results like this and let others discuss the topics you mentioned (and they do).
Maybe I find it a little tone deaf. As someone that has been using Julia for a long time and still seen very little growth in the language (compared to Rust for example), and sees users on a regular basis complain about basic issues in Julia (tooling being the biggest one for me), I find it off-putting and evangelizing when prominent community members blatantly disregard information counter to the narrative they want to establish. I hold Logan to a much higher standard, and the tone in the blog post rubbed me the wrong way. Even on Slack, there's a discussion of how "little" Julia is in this survey, and for the public messaging to be different from what a lot of users are voicing feels off. I do feel my comment was a stronger reaction, but it was perhaps stemming from my frustrations after seeing the survey, seeing it discussed on slack, seeing it discussed at work, and then reading this post.
> I am also surprised by your "scathing indictment" comment. Julia released its first stable version 3 years ago. MATLAB/R/Haskell have existed for decades. Julia has 30% of the user-share of MATLAB (and same order of magnitude comparisons to R and Haskell). This seems like a pretty big achievement already, especially when you see where these other languages are on the "love" scale.
Perhaps. Maybe I was too strong here. Julia has come a long way, and I absolutely love using it over MATLAB. But scientists and researchers are still picking MATLAB over Julia today, and that is extremely troubling for the future of the language. People are dreaming that Julia will eat Python's lunch when Julia seems like it is barely catching up to MATLAB.
I think Julia will get there eventually. But maybe I need to adjust my expectations. I previously was hopeful that after Julia 1.0, adoption would skyrocket. It did increase, but not to the extent that I would have liked. After Julia 1.6, I was hopeful again. But I think I just need to temper my expectations. Maybe after like 10 years it might be a popular language, but right now it feels like it is such an extremely niche language, and that personally hurts that I've sunk so much time and effort into it.
Maybe I find it a little tone deaf. As someone that has been using Julia for a long time and still seen very little growth in the language (compared to Rust for example), and sees users on a regular basis complain about basic issues in Julia (tooling being the biggest one for me), I find it off-putting and evangelizing when prominent community members blatantly disregard information counter to the narrative they want to establish. I hold Logan to a much higher standard, and the tone in the blog post rubbed me the wrong way. Even on Slack, there's a discussion of how "little" Julia is in this survey, and for the public messaging to be different from what a lot of users are voicing feels off. I do feel my comment was a stronger reaction, but it was perhaps stemming from my frustrations after seeing the survey, seeing it discussed on slack, seeing it discussed at work, and then reading this post.
> I am also surprised by your "scathing indictment" comment. Julia released its first stable version 3 years ago. MATLAB/R/Haskell have existed for decades. Julia has 30% of the user-share of MATLAB (and same order of magnitude comparisons to R and Haskell). This seems like a pretty big achievement already, especially when you see where these other languages are on the "love" scale.
Perhaps. Maybe I was too strong here. Julia has come a long way, and I absolutely love using it over MATLAB. But scientists and researchers are still picking MATLAB over Julia today, and that is extremely troubling for the future of the language. People are dreaming that Julia will eat Python's lunch when Julia seems like it is barely catching up to MATLAB.
I think Julia will get there eventually. But maybe I need to adjust my expectations. I previously was hopeful that after Julia 1.0, adoption would skyrocket. It did increase, but not to the extent that I would have liked. After Julia 1.6, I was hopeful again. But I think I just need to temper my expectations. Maybe after like 10 years it might be a popular language, but right now it feels like it is such an extremely niche language, and that personally hurts that I've sunk so much time and effort into it.
For those who use Python but still want to do differentiable programming (and don't want to learn Julia), check out Google's JAX package for Python
https://www.assemblyai.com/blog/why-you-should-or-shouldnt-b...
https://www.assemblyai.com/blog/why-you-should-or-shouldnt-b...
Tensorflow, Pytorch, and JAX are all amazing for differentiable tensor expressions in Python. Where Julia shines is differentiable programming over more complex models, e.g. differentiable programming over state of the art differential equation solvers. The Python ecosystem is a desert in comparison (the sophistication of the differential equation solvers in python is fairly low and difficult stiff problems are not easy to solve there).
I have almost no idea about differential equation solvers but isn‘t fourth order Runge-Kutta pretty state of the art and just a few lines to implement?!
RK4 is indeed trivial to implement. It is also fairly useless for anything but "easy" problems. I have done a lot of useful science with my own tensorflow implementation of simple integrators like RK4, but for serious research problems I do need much better solvers.
Things that are "better" with modern solvers: computational efficiency (appropriate adaptive choice of step size); numerical stability (detecting when things go wrong); higher precision. And other nice improvements like callbacks and root-finding and sensitivity analysis built into the solvers.
Things that are "better" with modern solvers: computational efficiency (appropriate adaptive choice of step size); numerical stability (detecting when things go wrong); higher precision. And other nice improvements like callbacks and root-finding and sensitivity analysis built into the solvers.
Julia is a great language, but the ecosystem is lacking in quite a few areas, especially for Deep Learning. I'd love if we could get something like Rllib for Julia, but right now, ReinforcementLearning.jl isn't even able to handle recurrent architectures.
Recurrent networks are pretty slow in Julia unfortunately because Flux does not use the 3D interface of CuDNN
I did a quick comparison with a python repo, and found the similar trend. Cool!
https://ossinsight.io/analyze/JuliaLang/julia?vs=python%2Fcp...
https://ossinsight.io/analyze/JuliaLang/julia?vs=python%2Fcp...
Just checking, for people who come in here and say "why does Julia have 25x the number of issues as Python" (and then point to the various discussions about the maturity and correctness of the Julia codebase), this doesn't count issues from before CPython moved to GitHub right?
I kind of agree, it may not be an apple-to-apple comparison if historical data are overlooked. Maybe another dimension to look at is to count the applications, but that can be very very hard...
The 3 most-equally-divided languages are
1. Ruby (49.99% love) 2. Scala (50.3% love) 3. C++ (48.39% love)
1. Ruby (49.99% love) 2. Scala (50.3% love) 3. C++ (48.39% love)
I didn't know Delphi was still popular.
You can come to Germany, we still have conferences.
https://entwickler-konferenz.de/
https://entwickler-konferenz.de/
Sure, taking the Julia responses alone, you could argue that a high proportion of language's users love it. But when placed alongside other languages, it leads some to conclude that Julia is loved more than Python; if 22,999 people love Python and 786 love Julia, is that really true?