I for example always answer this with “Sure, if most your legacy code I Python, consider staying with Python, because starting anew in Julia might not be feasible – e.g. during your PhD”. But I have a few colleagues that try their new ideas./ projects in Julia and that is the thing I usually hope for.
In thinking about next steps, we have to determine what our time scale is. For the short time time frame, like the next few years, academia is definitely not the focus. Being in the news, blog posts etc. are the way to go.
However for the long term, academia is definitely a good place to be. MIT and similar institutions should be the focus. These will then in turn train the people that will be professors at other universities and take Julia with them. They will then in turn train the undergraduates that will then go into industry or be teaching at community colleges or high school. If the undergraduates need to do a modestly complex calculation, they will turn to Julia instead of a spreadsheet. The teachers will expose many to Julia.
This is the focus of Matlab, they provide their tools for academia at little or no cost to introduce undergraduates to them so they will specify those tools when in the work world. With Julia you don’t need to convince your boss to buy a Matlab license, you have Julia at your fingertips.
To demonstrate the power of this, just ask yourself what are some of the fundamental things that you believe, and then compare those with what your grandparents believe. Now try and determine why your beliefs are the same or why they differ from your grandparents. Where they differ there is a high probability that what you believe was introduced to universities as fringe concepts a few generations ago, and migrated to the mainstream following this path. They are just assumed by teachers and the media.
Yeah - like: “you can have Matlab and a hand-me-down computer … or … you can have Julia and the supercomputer that could be bought for the per-seat license fee of Matlab.”
Also - I think Windows is so popular because it is the thing that was installed on their computer when they got it. I remember years ago, when Windows 3.11 came on my computer. I turned it on, didn’t like it, and deleted it. I have not changed my ways since …
I agree with this point.
Learning Python is popular because using Python is popular. My commercial simulation software has a Python interface. My stock trading platform has a Python interface. If I Google “web backend code” or “snake game code” or “machine learning code” or “data science code” there are tons of Python applications and tutorials. It would practically make sense for me to learn Python before I reach for something like Julia. (I did actually start learning Python first and promptly ran like hell from that syntax to Julia.)
However, I would add one caveat to your statement:
“… and then make it easy for others to follow in your footsteps.”
Without that last point, people are likely to try Julia and give up which is somewhat worse than having never tried it at all (since then they may spread negative feeling about Julia). That’s why I think improving the VSCode extension and documentation of the fundamentals are the obvious next steps.
I think the Julia language is really great as it is. It just needs more time for useful tools, bug fixes, and tutorials to proliferate so that other people also find it useful.
I think one of the most valuable aspects of using Julia over the past 4.5 years has been that, at least to a small extent, I’ve been able to bridge the gap between scientific/numeric computing and just “regular” coding that solves day-to-day problems. I work in government and I strictly adhere to a very simple principle: never make decisions based on models/code that I don’t fully and completely understand. What that means is that, if I’m going to do simple time series forecasting, for example, and then make decisions based on the results, I have to completely understand how the time series model works. If I’m using a clustering algorithm or solving an optimization problem, I need to know exactly how it works. Julia has allowed me to do that. The fact that I can read & understand the vast majority of package code (because it’s written in Julia) contributes to that and also, Julia is just a fantastic medium for learning topics like linear algebra and calculus, which is something I’ve spent a ton of time on over the past few years.
I think there are many, many “regular” use cases that get overlooked. I recently was able to formulate a recruiting/interviewing problem that involved 50+ locations across the US as a graph node coloring problem with Graphs.jl, which allowed me to provide quick solutions to some problems that had been driving HR folks mad for the better part of two weeks. Bridging graph theory with a seemingly completely unrelated HR problem was pretty straightforward with Julia and, again, I can dig into the code and see exactly what it does and how it works. Can folks using Python for similar purposes say the same?
I think convincing others that these kinds of things are possible could go a long way to taking Julia to the next level of popularity. But, because the scientific/numeric aspects are so heavily touted, and because the community is full of scientists and academics, it can definitely be intimidating for your average user who is just looking to move away from Tableau or Excel and learn a programming language to be able to solve bigger/more complicated problems. I don’t think Python really has that problem but I also don’t think most of the Python users I interact with could even begin to explain what most of their code does under the hood. Most of them could certainly not tell you what singular value decomposition is, how it relates to PCA, or what a Kalman filter is and how it’s used in their time series analysis (and they are doing these things!).
I realize that a lot of users probably don’t actually care what their code is doing and many would prefer not to learn the math behind it, but I think that’s just because people are too intimidated by it. If you can show people a very attainable example, I think their attitudes would change. A really wonderful example is in the computational thinking course where you get to build a language recognition tool that works by computing transition frequencies from very short texts. That’s something that just about anyone can understand and when you build it and see it in action in a reactive notebook, it’s really cool and awe-inspiring. It’s way more satisfying than just loading some library and passing a text to a function.
I think we need to figure out how to attract more of the people who don’t care, but also to really aggressively target those who do care how things work under the hood.
Personally I love the “arewexxxyet” sites popularized by the rust community - they provide a ecosystem-level summarization of progress and perceived gaps made by community curators for specific niches as well as a long term vision for those niches as a guiding framework. I think they have helped community formation by establishing targets that could naturally emerge over time. The Julia github groups are a nice starting point, but there are also a lot of cross cutting concerns between groups that are not currently well categorized, and there also tends to be less information about current status and gaps that could be filled by contributors.
A niche Julia could do well in is in fun & “technical art”, e.g. computation photography, (I made binding for Home · LibRaw.jl but if there was e.g. a good free denoiser people would install Julia for it), generative art à la processing (230616a - OpenProcessing), audio stuff, small games, etc.
Julia developed plugins for Audacity anyone?
Another thing that might help Julia adaption in the field of modeling and simulation would be better export of FMU models. For example, if this would be implemented: Support export of FMUs for cosimulation · Issue #10 · ThummeTo/FMIExport.jl · GitHub it would be much easier to export ModelingToolkit (and other Julia) models in a standard format and use them in Simulink or Python or any other commercial simulation software.
In wind energy and aerospace people nowadays use Fortran models and embed them in Simulink to design controllers… It would be so great if that would be easy with Julia models…
I just created a wind turbine model in Julia which is 100 to 1000 times faster than the exact same Simulink model… It would just be great if both worlds would be easier to integrate…
And an FMU (Functional Mockup Unit) is something like an end user software… Just a zip file (which contains a dll and an XML interface description), you import it in Simulink as a standard block, and it behaves like a kite, a plane, a ship or a wind turbine… Just configure some parameters… No need to understand what a differential equation or a Jacobian is…
TL;DR: industry adoption!
This. For Julia to make a “big leap”, my belief is it needs to keep up the great momenum in Academia and advanced research labs for sure (call them Developers), but it also needs a big increase in industry adoption by everyday analyst solving mundane everyday problems, this is the large mass of Users that far out-number the Developers.
We need to get everyday commercial profit-seeking organizations (think Banks, Retailing, Telcos, Insurance, e-Commerce,…) to want to hire Julia Users to create value for their business. Julia needs to be mentioned in the same sentence as Python or R, and then supersede them in good time.
Industry Business management and IT management are not interested in Scientific Computing, they don’t even know what it is (unless it’s their core business). They’ve only heard of Python, R, and hey, no one ever gets fired for adopting them, right? A strong business case needs to be written on “Why Julia?” for business leaders and IT management – people who hold the paycheque and control IT environments – as well as to the mass User community (the BSc, MSc crowd working for a regular paycheque).
As an ordinary Julia User (not a Developer), another thought I keep having is the nature of JuliaCon. It is geared towards language advancements and very advanced use cases (ahem, Developers or people at the bleeding edge), it is not for the User let alone business or IT management. Contrast it with industry conferences, e.g., SAS Global Forum (now SAS Explore), thousands of attendees every year, business use cases for business managers, super techie tracks for the tech nerds (Developers), plenty of useful tracks for the User to get their everyday job done, birds-of-a-feather sessions, networking sessions…, the list goes on. They cover all bases to ensure adoption, business leaders, IT management, marketing, sales & service, credit risk, fraud control,… it’s a full court press on all fronts. This is what it takes to serious move up in commercial enterprises. If Julia grows roots in industry, demand will drive talent supply, and nothing drives demand like Success Stories in Industry (as well as Scientific Computing) and adoption by industry competitors (FOMO).
That’s my $0.02 for you Julia Gods to consider
We seem to agree on where we want Julia to be in the near future, but for this to happen we need to agree on what steps Julia community needs to take in the next 6/12/18 months.
I like this idea because it shows the current situation, sets short-term goals, and avoids duplication of libraries.
Seems like a good time to link to this post:
Essentially, it’s a bit tricky to barge into an open source community and ask for things to get done. In my view, the best way forward is to start an initiative, and let others follow if they want.
A recent success story is the monthly julia newsletter, so I have no doubt that such initiatives can succeed
I get that you’re advocating that Julia expands its horizons, but the point of niches is that different people are suited to solving different problems. Instead of dismissing niches Julia is present in or accusing the developers of focusing too much on them, we should encourage people in other niches to adopt Julia. A big part of that is letting the developer community show off Julia’s strengths and versatility, for example I think EasyModelAnalysis.jl demonstrates an accessibility layer for relative newcomers that a developer in any other niche would emulate. I think discouraging inputs from established developers could actually discourage new developers from joining the community; why would they stay if the more they develop Julia in their niche, the less relevant they are deemed in conversations about developers adopting Julia in more niches?
Other ideas for encouraging new developers that some have said already: establishing sets of general purpose programming tools, improving the pain points in those tools, documenting these in timestamped tutorials so people don’t pick them up one at a time on forums, being transparent about weaknesses compared to other languages and ways to address them (JIT latency - PrecompileTools).
Fair enough - what I’m critizising is acting as if the docs of MTK are what need improving to get people that aren’t going to use MTK either way to use Julia. I should have worded that better, mea culpa.
You’re right, I should have worded that better - what I meant was that I personally think it’s high time to shift focus a bit away from “DiffEq is the poster child of Julia” and that we ought to start thinking about pushing other stuff as well. That of course also means being accomodating to those other workflows/users in terms of core language development & ecosystem tooling, which may require a shift in priorities In no way was I intending to discourage people to voice their opinions, I was specifically picking a bone with the (perceived) attitude that MTK (and the surrounding ecosystem) is the sole matter of importance to further Julia as a whole. I guess that point translates to newer niches as well - no single one should be the “sole importance” when it comes to developing the language. It should always be a balanced discussion.
I don’t think anybody brought such an attitude or opinion to this conversation, and that argument seems completely unrelated to someone offering 1 example package designed to adapt other packages for newcomers to their niche. I think that instead of shutting down 1 niche you either aren’t familiar with or don’t care for, which ironically made the conversation focus too much on that 1 niche, it would’ve been more helpful to bring up more niches you hope will have similarly newcomer-friendly packages.
As much as I mostly play with base Julia out of casual interest, there actually is one niche that I hope Julia can get more into: realtime audio processing and playback. A couple years ago I played around with it, and ended up writing Python with the PortAudio wrapper PyAudio. There is a PortAudio.jl but it doesn’t wrap the nonblocking asynchronous callback feature of PortAudio. That’s actually quite important for realtime because the callback is called when PortAudio needs a buffer to be refilled as the other buffers are still being played as sound. There is a write
method you can call in a loop, but it’s hard to time it properly without the callback’s timing. If too late, you simply get silent gaps distorting the audio. If too soon, you block the program waiting for the buffers to open up, but the audio data you processed has increasingly outdated input and can cause further backlogs. I’ll have to test again to be sure, but PyAudio says that write
blocks until all the written data is played, too, so you can’t start processing until you reach that silent gap. I was reminded of this all yesterday because someone else started a discourse thread on realtime audio processing with PortAudio, and people are speculating on if we can move the callback feature to multithreaded Julia.
TLDR: Julia is great for complex problems but lacks practical applications. This limits its growth. To fix this, we need to support developers creating such content.
…
Being primarily an engineer (not CS) and having worked solely in industry, as well as regularly programming for the past 3 years (and using Julia for almost one year), I believe that Julia has been successful in being considered a serious alternative for solving the world’s most complex problems, mainly backed by academia.
However, unlike Python, Julia has built its pyramid from the top down, creating a sort of black box for more mundane problems (the base of the pyramid). For many programmers, this could be a red flag when delving into the language and/or seriously adopting it, given that they don’t really want to implement a new optimization algorithm, but rather want to know how to:
- Automate email sending
- Build an e-commerce site
- Create a chatbot or video game
I get the impression that the lack of such content may be slowing down Julia’s growth. This, coupled with certain perceptions that Julia is not good for building large-scale software, quashes the desire to use the language.
One solution to improve this issue is to see who are the developers, hobbyists, and software engineers who are currently venturing with the language for these purposes and support them (through funding, promotion, etc.), so they can continue generating more content, like for example the content from doggo.jl (note that I’m a member of the channel, but I have no other relationship with the person itself). In my opinion, these types of channels are essential for the success of Julia.
Becoming a popular general programming language like Python is very difficult, which is why most programming languages become popular in some specific domains like R.
Does Julia want to be a good alternative to Python or just to the Numpy ecosystem?
I feel the whole SciML not new user friendly yet argument to heart ig, I have tried couple of times to find what it might be useful for me and contribute. But then there is a lot of jargon to go through first before you get to the good stuff I guess. I never did a GSOC in SciML where the person involved just has to go through with the hard part, Chris is amazing, so much work being put in there by contributors with good intentions. I work 6 days a week ;-;(bit busy i mean) and whenever I try to learn something to do with SciML in evenings, I just get frustrated and have to let it be. It feels like it’s something I’ll pick up in masters where I might have more time.
I mean we need more documentation and not academics documentation, some documentation that makes me go “this might be something I can pick up”. It’s lot different than the instructor-student or mentor-mentee when you are learning from documentation and asking questions in #helpdesk or #sciml-bridged. Also it was starting point problem for me that Chris had already pointed out in this discussion.
[Edit 1] : It might be just that a proper use case to learn it for me hasn’t arisen yet
R and Python at one time were fairly competitive in the same domains. The article “How Python Became the Popular Choice” by Jun Wu highlights the big packages and applications of Python as it rose to meet big and often overlapping demands, like finance, data science, machine learning, web development.
Strictly speaking, the question is meaningless, because the subject (“Julia”) is a computer language, and as such it is not a conscious actor: it “wants” nothing.
I recognize that this is a figure of speech, meant to represent a group of people (“the community”, “the core devs”, “package authors” etc). But most of the groups you can plug into that sentence are a very diverse bunch, with nothing close to a single unified goal.
Discussions like this topic are pretty pointless, since no consensus will be reached, and in any case very few people will write FOSS code for anything unless they need it in the first place, and then they do it anyway.
Good luck with that. But, with respect, I hope you realize that whatever you agree on, you have more or less zero effect on what people will work on in the package ecosystem. Which is as it should be — it would be weird if a central committee allocated effort to FOSS projects.
It is as if my neighbors got together and voted on what I should plant in my garden. I would shrug and plant what I want.
For the curious
It will be Lonicera japonica, with flowers that smell very nice around dusk.
To end on a positive note: everyone here has the potential to steer the Julia package ecosystem with contributions. Report issues, write docs, make PRs, or fill in niches of missing functionality with new packages.