Hello,
First Julia post. I’m an engineer and I have been using Julia for a couple of years and I enjoy how it allows me to express myself, I find Julia empowers me to write decent code faster than I can in other languages.
I have created some engineering tools using Julia with the notable deps: SciML.jl & optimization.jl. The system works great, it is fast, scales to our problems, and deploys multiple dispatch to deal with different problems.
Now the issue, I am now hitting roadblocks from I.T. in my organization, and have been instructed not to use Julia. They do not want another programming language over Python and Matlab. They are concerned about security and that more languages will cause compatibility issues between bodies of work, this is actually not an issue as there is almost no python code being used in the company anyway.
They don’t seem to be responsive to some of our arguments regarding speed, and they argue that it would have been as fast using Python/Numba (I don’t know if this is correct). I here lots of things about compatibility issues of getting Numba working and I would need it to work with a large optimization system which I have not found one close to the functionality of SciML. I certainly don’t think patched up python will be as readable and cohesive as using Julia.
Aside from the speed I’m trying to sell the usability of Julia, things like the strength of the package manager, Julia-up for Julia version, workspace virtual environment, the way the all user dependency can be controlled through instantiation, and the readability of Julia, especially when most engineers have Matlab experience but not python.
I store all components of my systems in nested structs, Julia is fantastic at allowing me to interrogate this data and python is frankly terrible, I’ve not found this difference documented anywhere.
Any feedback of how others overcame issues like these, links to useful docs, comparison tables, any other strong points that may help this cause.
The biggest issue I don’t know how to respond to is regarding malicious attacks on the network that could be related to Julia, so any help at all on that front.
Thank you
This sounds like an IT team which has been burned by Python’s mess - I’ve run multiple times into problems with python where a new python install or adding a new package made other packages break… It’s much harder to run into something like this with Julia - but maybe it’s hard to convince an IT team of this, without them really giving Julia a chance.
The biggest issue I don’t know how to respond to is regarding malicious attacks on the network that could be related to Julia
I’m no security expert, but as long as you don’t expose a Julia app to the internet or to malicious users, I’d be surprised if it added any new security risks.
They are most likely afraid that they will end up with tools in many different languages and will have issues recruiting maintainers. If every engineer starts a project in a new language the company will struggle to maintain the code in the long run.
You probably need to convince them that Julia can be a long term way of reducing the number of programming languages and reducing the complexity of maintenance. It is best if more than 1 engineer in the company is interested in working with Julia. It is also good if you can convince them that a skilled python or matlab programmer is able to contribute to the project with a low amount of onboarding.
I am not a security expert so don’t trust to much in what I say. I would start with comparing the security aspects with the alternatives that you are using or that they are presenting. There is a good chance that the current system and the alternatives are’nt perfect either. If you need high security a package mirror with reviewed and whitelist packages might be needed. I think ASML is doing something like this. Building a Scalable Inner-Source Ecosystem For Collaborative Development
The “inner-source” concept can be at odds with IT security people who want to restrict all access by default.
That seems to be about not trusting developers with access to the company’s code… But at least it’s language agnostic, and maybe easier to handle with Julia(?).
About recruiting maintainers of Julia code, people who know e.g. Python shouldn’t find it hard to get up-to-speed on Julia, but that said, some people are reluctant to switch languages/learn a new one, and it will be easier to hire e.g. Python people for the foreseeable future.
Python has great security support it seems, i.e. they release updated versions for security, for many past versions. You are trusting that Julia will do it (or for the LTS, that people shouldn’t really be using… until possibly when 1.10 becomes the new LTS), and I do not think it happens too infrequently, but depending on what you do with Julia might be an issue. I’m not at all convinced that Julia is worse than many mainstream languages like C and C++…
SciML is state-of-the art. I don’t know exactly about similar in Python, it’s likely you would be using Python’s SciML from Python (it’s at least possible), so then it’s hardly a reason to abandon Julia.
It’s famously hard to compile Python, i.e. make it fast, in general, with some important exceptions. Julia’s docs mention it e.g. not possible to simply compile Python to Julia for speed, but the reverse may not be false… It could be hypothetically possible to compile to Python (I know it is possible to compile Python to Julia, for a limited subset), and then it would work, maybe slower, or not if compiled to Python/Numba/NumPy…
On this front, I would definitely point out (and show examples!) of PythonCall.jl, JuliaCall.jl, and MATLAB.jl for interoperability if, for example, a Python programmer wanted to incorporate one of your Julia tools into their workflow.
I wouldn’t go this route too early as it could cause some friction, but if IT is being truly unreasonable, then go over their heads. Make some slick presentations designed for folks higher up the management chain and convince them its a good idea. Then they can push on IT from a position of power. But first, you need have to answers to all the questions the IT people raise, so you can have counterpoints.
Yeah, this is a common story, and it can be frustrating. Exactly how to navigate it can depend upon what their actual objections are. You mention:
Yet another programming language — some good resources here include things on the 2-language or 2-culture problems. Matthijs Cox in particular has put together some wonderful thoughts on this; see, e.g., How to solve the two language problem? and My Target Audience. I suspect, though, that the root issue here is their own bandwidth in maintaining multiple systems and package managers.
Security — this can mean any number of things, but if they already support Matlab and packages from the PyPI, Julia is not categorically different. It’s often good to investigate this point a little closer — what specifically is their objection? Is it outbound network security? “Supply chain” issues? Open source package code auditing or allow/disallowing? A local (potentially air gapped?) registry and package server? Often I’ve found that Python is just assumed to be ok and is simply grandfathered along, but new tools are scary.
Arguments regarding speed — I suspect they don’t particularly care here, but are just trying to get you to use tools that don’t require extra upstart efforts from their side. If your use-case is well-covered by Python’s existing packages then yes, there shouldn’t be a performance difference. The folks working on Python and its libraries aren’t inept — they’re also trying to make things as fast as possible, just like us. But the trouble is if your use case isn’t well-covered… and SciML is exactly one of those cases.
I try to not throw sales pitches around here, but this is literally what I do for my day job . JuliaHub exists to help allay many of these concerns and foster commercial uses — and the platform itself strives to make IT teams’ jobs significantly easier. See trust.juliahub.com for many more details about how we take security and compliances seriously.
. JuliaHub exists to help allay many of these concerns and foster commercial uses — and the platform itself strives to make IT teams’ jobs significantly easier. See