Julia is not a typical language used in workplaces. Still, for Julia lovers, it’s something you want to write at work. So, how do you create Julia work for you?
I can think of 3 main ways.
Find rare companies that use Julia.
Take control of the software architecture and decide to incorporate Julia into the tech stack.
Write a microservice in Julia and deploy it alongside applications written in other languages.
None of the option is easy. A job using Julia, for example, might have you implementing some library/ecosystem, which requires a deeper understanding of the algorithms you’re using. Besides, those jobs can be rare to find.
Taking control of the software architecture or even a microservice means making sure your Julia module is maintainable, which can be difficult if your co-workers don’t know the language. Taking control of the software architecture also implies you have the authority to do so, which can be done in multiple ways, such as managing a project, starting your own company, and so on. However, none is easy.
I think this question is too vague to provide a meaningful answer.
Maybe if you can flesh it out with some specifics – ideally questions about you can use Julia in your own career, it would be better
also, just a general note, these super open-ended threads that all boil down to meandering meta-discussion about the adoption rate of Julia are getting pretty old, and you have started over a dozen.
Maybe go write some concrete code for yourself or your team, and stop worrying so much about what some abstract idea of “workplaces” are using
Hopefully the question is more specific this time and doesn’t become yet another unfocused thread. There have been many threads which ask questions of how Julia can become more popular. I (and many others presumably) want it to become popular so you can easily find jobs. So, instead of asking that question, which devolves into unfocused thread instead of achieving what is desired (getting jobs with Julia), I’ll ask a more specific, to the point question which is actually what people wants.
Maybe I’m not yet specific enough? I’m talking about how YOU can introduce Julia into YOUR workplace, not some unknown place, not some random people. Just YOU alone.
What should be a more specific question if you want to make a career with Julia then?
What should be a more specific question if you want to make a career with Julia then?
well for starters, “making a career” involves a lot more than just deciding to be an enjoyer of a particular language
are you asking for testimonials for how Julia is used in industry? in that case there’s a JuliaHub page for case studies Case Study - JuliaHub
are you asking how I, personally use Julia at work? the answer is I generally don’t. I occasionally make some interactive plots in Makie when I face performance problems in my python plotting tools, and I have just recently started using an ElasticNet fitter to avoid a limitation in sklearn. but besides that the answer depends severely on whom you ask. so yes, it is vague
Yep, use the best tools for your job. Sometimes that won’t be Julia. I’ve worked in many languages for many reasons — even in cases where Julia would’ve done better technically but couldn’t be used due to other reasons (like existing toolchains and codebase and inertia) — and that makes sense.
Want to work more in Julia? Target areas where Julia is undisputedly the best tool for the job. Learn ModelingToolkit and SciML. Learn Turing’s modeling syntax and how to use it in real-world contexts. Learn mathematical optimization with JuMP.
That’s how you find jobs that use Julia or convince your team (and boss) to use Julia. And if you’re having trouble convincing your boss, that’s what I do for (part of) my day job. JuliaHub is built to help reduce friction in workplaces — things like compliances, validation, inner- and open-source package management, collaboration, etc.
I work in the research group of my company, and we build proof of concepts for nascent product ideas that select customers can use on a trial basis. We use this for concrete testing whether there is a market for the new product idea. The company has specific supported languages in different areas, and Julia is not one of them, of course. However, in my role, I need to build code quickly, and I’ve used Julia on several occasions because that was the quickest way to get code working. Sometimes the code is a small, specialized bit that has actually transitioned to be deployed to production. Usually, if and when the product moves to the proper development channels, then the code must be ported to a supported language. The Julia part is nearly always a small part of the proof-of-concept code, so the porting is not too onerous.
Another issue is that, because we need to work quickly we don’t always follow sox compliance protocols. Thus, if and when the product goes to production, it may need a lot of rework for compliance. Porting from Julia is small compared to the compliance work.
Yep… the thing is… people want to use Julia because they already believe Julia is the best tool for the job. So, the question becomes how to use Julia when it is the best tool for the job. For example, maybe making a microservice with Julia is a good idea as it can run decoupled from other code.
None of those three sentences lead to the next. Don’t blindly think that Julia is the best tool for every job — it’s not. If it is the best tool, then it’ll be obvious how you should be using it. Microservices are themselves just another tool — not one that I’d say Julia would excel at — but similarly people don’t go around looking for ways to build microservices.
Julia is a great tool that I enjoy using. My Milwaukee M18 Oscillating Multi-Tool is also a great tool that I enjoy using. But I don’t go around looking for things to cut holes into because I want to use the thing. And I don’t use it to whack on nails.
Code does something and has a purpose. Find something you want to build and use the best tools to accomplish that. Sure, you could filter the “what to build” based on how much you think you’ll enjoy building it, but you don’t use tools for the sake of using tools — especially not at your day job.
I can talk from some experience of introducing and with decent success popularizing Julia within a company (or two, after a spin-off). This is within the image processing field, where Julia is an excellent tool, in particular if you are in an environment where both performance and the agility of a dynamic language matters.
To begin with, nothing of this is really particular to Julia, it would apply to any tool or language which is good but not mainstream.
For prerequisites, it helps to have a reasonably senior (technical) position, it’s probably necessary to have a company culture which focuses more on results than what tools you use (within reasonable limits), and it does help if you’re skilled at programming and algorithms, at least relative to your environment.
In my experience, the most important points are:
Show that it solves real problems better, in some way or other, than the mainstream alternative. Well, if you can’t do this, your tool probably wasn’t so good after all, for the purpose. Bonus points if you can show that it solves the problems much better.
Make the solutions really robust, so they just work, every time, for everyone.
Make the implementations as clear as you can. Sometimes this goes contradictory to performance. In that case, comment and document your code abundantly.
Point 2 was kind of challenging before Julia 1.0 but has become a real strength since, especially with the introduction of the current package manager, binary artifacts, and juliaup.
Same here. Used to use Julia for this very application (and leveraging the wonderful CUDA.jl package), in a kubernetes-based distributed environment, where all the plumbing and architecture part was done in Go.
In a word, julia for the high-performance domain-specific algorithms & solvers , Go for the efficient logistic.