dex-lang VS julia

Compare dex-lang vs julia and see what are their differences.


Research language for array processing in the Haskell/ML family (by google-research)
Our great sponsors
  • Scout APM - A developer's best friend. Try free for 14-days
  • Nanos - Run Linux Software Faster and Safer than Linux with Unikernels
  • SaaSHub - Software Alternatives and Reviews
dex-lang julia
12 125
1,118 37,368
3.6% 1.6%
9.5 9.9
6 days ago about 11 hours ago
Haskell Julia
BSD 3-clause "New" or "Revised" License MIT License
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.


Posts with mentions or reviews of dex-lang. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2021-11-09.


Posts with mentions or reviews of julia. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2021-11-30.
  • Julia v1.7 is significant downgrade in package load times from v1.6
    1 project | | 5 Dec 2021
  • Julia 1.7 release
    1 project | | 1 Dec 2021
    That's not true anymore, while it was the case initially it's been advertised as a general language for a long time now. Take a look the "Julia in a Nutshell" of the website :
  • Julia 1.7 has been released
    15 projects | | 30 Nov 2021
    I'm extremely excited about this. But there still many problems, for example a ton of tests failing. For example:
    15 projects | | 30 Nov 2021
    Mutation is tricky, because basically the only way to do it sanely is to copy all data into the residual, but since most arrays aren't actually mutated, that's extremely wasteful. I've been hoping to address this by changing mutability in the language more generally (e.g. to make immutable arrays the default at which point there wouldn't be a penalty anymore. I've had request to do the mutable copying optionally, but it's a bit tricky, because it needs rule system integration and the rule system currently doesn't reason about mutation.

    As for exceptions and recursion, shouldn't be a problem, just needs to be implemented.

  • Release v1.7.0 ยท JuliaLang/julia
    2 projects | | 30 Nov 2021
    When it isn't crashing it flies and is wonderful to use, but right now prevents (my) using Apple Silicon for production runs. (i.e. library development works ok, especially if you can stand having to restart the REPL with some frequency, but long running / demanding simulations can't be trusted to finish without crashing).
    2 projects | | 30 Nov 2021
  • julia/ at v1.7.0 ยท JuliaLang/julia
    1 project | | 30 Nov 2021
  • Does Julia support currying? (Too happy)
    4 projects | | 29 Nov 2021
    There's a very long ongoing discussion about syntax for currying:
  • PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)
    19 projects | | 26 Nov 2021
    It's acknowledged. The full redefinition of any function in any context was solved by RuntimeGeneratedFunctions and we use it extensively throughout SciML, ModelingToolkit, Pumas, etc. so it's fair to say struct redefinitions are the only thing left. That said, "struct redefinitions" are done all of the time in many contexts: if you know you may need to do this, you can just use a named tuple which acts just like an anonymous type and obeys dispatch on a named form that you can then hijack at runtime. With smart engineering then you can be redefining everything on the fly, and we do this through MTK quite regularly. That said, it would be nice to do the last feat of full redefinition of non-anonymous structs, and the latest proposal for how to do struct redefinition is So we both built and provided solutions for how to do it, showed how to do it in libraries, tutorials, videos, etc. How is that not acknowledging the point of view and doing something about it?

    You might want to try and acknowledge the other point of view where I note that, hey, we did make this work but it was a smaller deal then we thought because we legally cannot employ it in many production contexts. We're still going to work out a few details for fun and ease of debugging, but given that we have extensively looked into and thought deeply about the whole issue, we have noticed that the last little bits are less useful than we had thought (at least in the contexts and applications I have been discussing, like clinical trial analysis). That doesn't mean we won't finish the last pieces, but given how much of it you can already do and how many teaching materials show how to do work around the issues in any real-world context, and how little of a real-world application the last few bits have, it shouldn't be surprising that the last pieces haven't been a huge priority. So instead of looking narrowly at one factor, I encourage you to take a more global view.

    19 projects | | 26 Nov 2021
    I would say the almost every version of Julia 1.x has better in terms of code startup.

    as in 1.7 > 1.6 > 1.5 > 1.4 > 1.3 > etc...

    it's especially goten way better since julia 1.5, so really mostly in the last few years.

    In julia 1.8, what's interesting to me is that the julia runtime will be separated from the llvm codegen;

    the immediate effect is to allow small static binaries without a huge runtime (namely the LLVM ORC), but the side effect is probably that the interpreter will also get better in cases where you don't want JIT.

What are some alternatives?

When comparing dex-lang and julia you can also consider the following projects:

NetworkX - Network Analysis in Python

Numba - NumPy aware dynamic Python compiler using LLVM

rust-numpy - PyO3-based Rust binding of NumPy C-API

Lua - Lua is a powerful, efficient, lightweight, embeddable scripting language. It supports procedural programming, object-oriented programming, functional programming, data-driven programming, and data description.

Dagger.jl - A framework for out-of-core and parallel execution

awesome-lisp-companies - Awesome Lisp Companies

py2many - Python to CLike languages transpiler

duckdf - ๐Ÿฆ† SQL for R dataframes, with ducks

futhark - :boom::computer::boom: A data-parallel functional programming language

femtolisp - a lightweight, robust, scheme-like lisp implementation

JET.jl - scratch: experimental code analyzer for Julia, no need for additional type annotations

DFTK.jl - Density-functional toolkit