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.
4 Likes
Julia developed plugins for Audacity anyone?
5 Likes
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…
3 Likes
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 
8 Likes
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.
2 Likes
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 
12 Likes
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).
3 Likes
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.
3 Likes
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.
7 Likes
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?
1 Like
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
2 Likes
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.
3 Likes
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.
22 Likes
As a long time user of R, and occasional user of Python, Fortran, etc., my perspective is that one uses the tools that work for you. Julia has passed a threshold in utility where not only are cutting edge developers doing their thing (which is what you want in terms of creativity, in the long term) but also base level utility for the every-day stuff has stabilized to the point of being able to do what needs to be done in compact and elegant ways. So aesthetics had some influence in my transition. However, that was not enough. I was held back initially because many tasks were already implemented in one language or another. Why recreate the wheel? The incentive to transition the mundane stuff was low.
The critical factor was access to cutting edge approaches that are rapidly and easily deployed in Julia. This is where incentive comes in for me. Brute speed and the new methods that this makes possible.
So, all in all, I would say, keep doing what you are doing to the devs. I am happy. (Hat’s off)
However, to make the initial transition easier for others once the use case becomes clear, perhaps make a concerted effort to remove outdated tutorials and documentation. Amalgamate best practices with working examples in one central area. And did I mention, documentation, with many examples as use cases are so varied, especially where in XX language it is done this way, here it is in Julia … and so much faster, clearer, etc,
Thank to all the tireless devs.
Jae
13 Likes
Agreed. The more relevant question is: assuming that broader adoption is the goal, what action can each person take individually to move towards that goal? And the answer probably is to contribute in areas that are likely to be useful to most. That may or may not intersect with one’s area of expertise for instance.
My area of (relative) expertise is quantitative finance, where there are few users of open source solutions (not a dig at them, especially as I contributed some C++ code to the project over 10 years ago, but QuantLib doesn’t have a high level of adoption in banks or hedge funds).
Where I think Julia could attract more users? As stated before, in the area of small glue scripts (where Perl, now Python, are pretty good at).
So my area of expertise doesn’t really intersect with the area where I think Julia could gain broad acceptance. If I was involved in Julia internals though, I would work on static compilation and tooling. If I was a package developer, on system stuff. In the meantime, I can only use Julia where it makes sense for me, hoping that the above happens (as I would stand to benefit from it, from the point of view of a more mature language and ecosystem).
Back to the original question, I would suggest we take a look at areas suffering from 2(+) languages problems. Game development could be one aspect. There could be many more. Other than that, make Julia a top-choice programming language for newer projects.
4 Likes
IMHO Julia is already the top choice for programming technical/scientific computing (TSC) packages (by far).
Yet it is not dominant in this specific area.
I am more interested in Julia keeping on growing in the TSC community (TSCC) than reaching other domains (games…).
Hence the reasons that are slowing down the adoption in the TSCC tend to be more relevant to my eyes.
-
In my personal experience, the inability to produce .so/.dll from Julia functions is one of the major problem because it prohibits a progressive introduction of Julia in large scientific projects. I know that this issue is already known by all the people able to improve this point.
-
Another reason is the difference of maturity of GPU programming for non NVidia vendors. Being able to easily program for all GPU vendors would be a strong and unique feature. Don’t get me wrong : I am a super fan of CUDA.jl and brothers. I just point out an opportunity for Julia to propose something really unique.
-
A more opinionated way for package creation and development (e.g. via a button click in vs-code) would also help beginners coming from Matlab and FORTRAN.
A lot of new TSC projects continues to be launched in FORTRAN or Python/C++ and this makes me sad because of my strong opinion that it is a vast loss of time. For Matlab, it is less clear because for now, I think that Julia still requires more CS skills than Matlab and that some scientists will never invest enough in CS to enjoy the power of Julia.
11 Likes
“FORTRAN or Python/C++ and this makes me sad because of my strong opinion that it is a vast loss of time.”
Why? Keep in mind, workstyle, experience with established tools, quality mindset and test coverage has (still) way more impact on productivity than the implementation language. If the F77 math kernel written by experienced programmers is well documented and tested, moving it to e.g. a julia implementation is a simple job. And ccalling a lib from julia is a managable problem (as it seems, my recent experience is missing on that).
The (ongoing) problem in TSC is reuse of working code. Because a lot of developments do not try to establish stable infrastructure (platform-independent-GUI?), but solving a local problem.
1 Like
I guess your experience is very different from mine. I have seen ton of super large Python/C++ or FORTRAN projects that could have been implemented with at least 10 times less lines of code and a much higher maintainability in Julia. Code dedicated to language interfaces just disappear in Julia, package management, scientist who make tremendous effort to adopt OO style where it is totally irrelevant for their needs… Too many reasons. I was paid to write C++ code called from R package and we have shown to the clients that their library could be written in no time and a few line of codes in Julia (they were shocked).
For Legacy code, it is OK to call FORTRAN code from Julia but I can’t see no good reason to start a new project with this language.
Last time I checked this was experimental. If I recall correctly, this issue was the main topic of the last JuliaCon Keynote by J. Howard. A very good news indeed if this can be easily done.
9 Likes