Hello,
Some programming languages like Rust-Lang are secure. How about Julia?
Thank you.
1 Like
Julia is not “safe” or secure in the way that Rust is. If you need that level of safety, Julia is not a suitable language for you.
But maybe you can elaborate on your use case, and Julia might be “safe enough”
5 Likes
Rust isn’t “secure”, it’s memory-safe, in contrast to languages like C/C++ which are inherently not memory-safe. In C/C++ You can do whatever you want in memory. For example: Many security flaws in C/C++ programs are due to things like pointer arithmetic, re-pointing variables, deleting the variable the pointer is pointing to while still using the pointer (null pointers for example…etc). In Rust, you can’t do those things by design (You still can by writing “unsafe Rust” though it’s frowned upon, even though many Rust packages use it). This is important because many if not most security vulnerabilities in the past were due to bad things with memory.
Julia is Garbage Collected, which while providing “near” Rust safety most of the time, it can’t guarantee the safety.
In the end it depends on your use case, if I were writing some HPC simulation code I would go with Julia. If I were writing a database I would go with Rust (Personally I would go with Zig which offers most of Rust’s safety but without all the hopping around lifetimes or ludicrous async).
9 Likes
Related:
3 Likes
To slightly elaborate on this, julia should also be memory safe (apart from bugs in the implementation of internal functions), but doesn’t guarantee safety in the presence of data-races, for which the developer is responsible.
8 Likes
Zig doesn’t offer any of Rust’s memory safety. It has the same unsafe design as C, other than having slightly better paradigms to avoid some of the worser C code patterns. By contrast, Julia is memory-safe, due to the GC, and even in the presence of most data races, similar to Rust. The exception is if you can write unsafe code in Julia (such as calling memcpy or @inbounds something that has been mutated incorrectly). Unlike Rust, there are not strict guardrails against unsafe mutation, but it is generally discouraged style-wise, similar to writing unsafe blocks in Rust.
15 Likes
I don’t think that there is any such tool for Julia. On the other hand it is mostly - but not only - needed for memory unsafe languages like C/C++. I mean, there are tools to statically analyze Julia code, but they do not have the focus on security.
3 Likes
An elaborated explanation of this would be very helpful for the community to have. The information may get more circulation written as a Julia blog entry.
I am not sufficiently conversant with
the details to contribute the entry.
5 Likes
I think that isn’t true. It seems semgrep is for that, a tool I didn’t know of until the other day (see JuliaCon video on it), and that it added support for Julia in 2023:
Likely should be added here (where you can see other static-analysis tools [including for Julia]): GitHub - analysis-tools-dev/static-analysis: ⚙️ A curated list of static analysis (SAST) tools and linters for all programming languages, config files, build tools, and more. The focus is on tools which improve code quality.
2 Likes
WIP here:
1 Like
Hello,
Thank you so much for your reply.
The problem of garbage collection is the slow execution time. Is Python more secure or Julia?
Not true, common misconception.
2 Likes
Should be about even. There are also security vulnerabilities that don’t involve the language’s memory (un)safety, and some of those really are just up to the developer to handle. If the program asks remote users to provide arbitrary code to be executed on your server, I don’t think anything can make that safe.
In practice it’s usually unfeasibly difficult to safely accomplish GC’s long-term performance with manual memory management. The “slowness” of GC is usually one of latency; in applications that run in a cycle ideally fitting within a given time frame, say 1/60th of a second, then the GC makes some cycles go too long. Those applications would rather sacrifice overall performance if every cycle runs on time. There are actually some GC schemes designed for this, but Julia doesn’t have one. Real-time applications would usually also use alternative memory management strategies tailored to the context, and Julia doesn’t have much of that either.
Also worth mentioning that GC uses more memory; it wouldn’t save time if it runs so often that it frees every object right after it becomes garbage. So, automatic memory management strategies like Rust’s that don’t let garbage build up have a grateful user base. No matter the management strategy, more heap allocations have more overhead, but the memory load is usually worse for GCed languages. Unlike the more popular GCed languages that most comparisons are based on, Julia has strong support for reduced allocations in number-crunching and reusing allocated objects.
6 Likes