Now we are in position 42 (0.210% of the total usage)
Thereâs a ton of noise in the Tiobe rankings. It goes up, it goes down. Itâs an upwardly trending random walk.
To add to that, note that 0.210% is likely indicative of a sample size thatâs prone to huge statistical fluctuations.
Itâs funny, recently Iâve had some conversations with people who had less positive experiences than I have with getting involved in open source projects. Some questioning revealed that much of their frustration was likely due to the enormous popularity of the projects to which they wanted to contribute. There are definitely certain advantages to not being super popular. I personally would be perfectly content if Julia were a top 30 to 50 language indefinitely (though I suspect eventually it will be a top 10 to 30 language).
Yes, I totally agree. Popularity is completely irrelevant in my opinion, as long as Julia enables all the things I want to do. It doesnât matter to me if my neighbor uses it, the community is thriving.
The ranking is interesting to watch, but I donât think it matters and it shouldnât be the end goal.
To me, unfortunately, it does make a significant difference. Since none of my colleagues use it, and none of our customers have even heard about it, I cannot use it for work, except for very experimental or personal toy projects. Iâve only once in the past 3 years met anyone IRL who knew about Julia who hadnât heard about it from me.
More popularity would make a very big difference. I donât mean to complain, though, itâs without doubt my favourite language.
Thatâs a good point; however, a technically competent colleauge wouldnât base a decision on rankings.
The rankings donât matter, itâs the name recognition and the lack of use among customers and peers. So itâs only indirectly related.
The problem is not the colleague, but the company that calls the shots!
Same problem here: Julia is still too new to use it in most projects. Itâs a matter of time though before it becomes enough popular imo.
personally, i use julia because it has killer apps (ForwardDiff, DiferencialEquations.jl, JuMP, Flux), the more killer apps, the better, i think
there is this ranking too, and it directly mentions julia:
- Julia : For a language that isnât even in the Top 30, Julia continues to attract questions about its performance and future. Its growth has been more tortoise than hare, but itâs up another two spots to place #34. While there is no technical basis for comparison, it is worth noting that three years ago in our Q1 rankings TypeScript made a similar modest jump from #33 to #31. That is not to say that Julia is destined to follow in TypeScriptâs footprints, of course, but rather to serve as a reminder that while itâs uncommon languages can transition quickly from periods of slow, barely measurable growth to high, sustained growth quarter after quarter.
I also find myself in an environment where a lot of people wouldnât even consider using Julia because of its relative obscurity. However, I nevertheless find that the modern concept of âmicroservicesâ is the primary thing that allows me to use Julia for work. Since nobody is likely to use the code I produce as a proper API, it doesnât really affect me that it might be difficult to do that in the languages others are using (primarily Python and Go). What I really need is for the serialized IO of Julia to be good. Thanks to packages such as ProtoBuf, FlatBuffers (which I canât get anyone to use), JSON (which everyone insists on using), HTTP and LibPQ the fact that I use Julia doesnât much affect my colleauges who would likely find it extremely annoying otherwise. The biggest problem I have with using Julia at work is the lack of an equivalent to JDBC or SQLAlchemy (for which I use JDBC). I have toyed with the idea of writing a halfway-decent database package interface for Julia at least, but those efforts have fizzled out because it doesnât solve the core problem (i.e. having a nice Julia-native alternative to JDBC).
Most of my actual work involves mixed integer linear programming and some graph theory, and it just so happens that the alternatives for doing what I do in other languages are abysmal at the moment. There is another group that does some of the linear programming in python and itâs absolutely awful. So, if someone asked me not to use Julia, theyâd get a pretty lengthy lecture on why moving to something else would be a terrible idea.
Iâm just starting to learn Julia, and the reason why my colleagues and my donât use it yet is because we depend on packages available on other platforms and not in Julia. For example it doesnât have any package to do multiple imputation nor metanalysis.
Depending on the language those Packages are written in, you can still use them from Julia via Py-, R-, CCall.
We use FlatBuffers.jl a lot in a large-scale learning.
Is the code open source?
Somewhat surprisingly (or maybe obviously in retrospect?), the biggest hurdle for people who cooperate with me (ie mostly coauthors on various papers) has been not Julia per se, but the fact that I developed a habit of using version control and CI for everything.
Eg when we build code for estimating a structural economic model, I first write a quick & dirty version with extensive tests, then benchmark and optimize, using quite granular PRs for this. They see the benefits very quickly, but the entry cost of learning a new language and the associated tooling can be daunting. The best solution so far is that they share the screen and I help with commits, PRs, Julia and IDE glitches, etc.
What I learned from this is that if you want people to learn Julia to work with you, you have to be available for troubleshooting and guidance on a short notice. Then it is a rather smooth process.
You horrible, horrible person
Most parts of it yes.
I can completely relate to that. The âwhy Julia? how do I use Julia?â discussion often turns into âwhy Julia, version control and tests? how do I use Julia, git and GitHub?â which can degenerate in âversion control doesnât make sense for my field of researchâ type of arguments. This is not an easy discussion, Iâm afraid several researchers use a very different style (large scripts, not version controlled or tested, which are copy-pasted and changed as needed with a heavy use of the debugger: set breakpoint at line 457, see how things look there, edit a bit, advance to line 503 and so on). This approach may sound a bit unorthodox from a software engineer point of view but can be quite effective in the short term.
Besides doing a âguided versionâ the first few times (e.g. sitting down with a colleague and doing say a PR on their computer showing all the steps) I found it helpful to show how to use the Atom text editor, because, other than of course the Julia integration, it also has very good git / GitHub integration and may be more intuitive then the command-line interface of git for new users.
Since benchmarking and optimization meshes best with small functions in Julia, the first thing to convince people is to write small, clean functions that do one thing. This is good to learn and idiomatic Julia style anyway.
The next thing is to have unit tests, which is more natural for small functions where the invariants are usually clear. Then, after about the first 10 critical errors are caught in <100 LOC, most people understand why they are useful.
I think that the biggest selling point of version control is the ability to review and comment each otherâs code on Github/Gitlab/⌠.