array VS julia

Compare array vs julia and see what are their differences.


Simple array language written in kotlin (by lokedhs)
Our great sponsors
  • Appwrite - The Open Source Firebase alternative introduces iOS support
  • Scout APM - Less time debugging, more time building
  • SonarLint - Deliver Cleaner and Safer Code - Right in Your IDE of Choice!
array julia
6 213
34 39,199
- 1.2%
9.4 9.9
16 days ago 6 days ago
Kotlin Julia
MIT 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 array. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-05-12.
  • Ngn/k (free K implementation)
    17 projects | | 12 May 2022
    In some of the example programs written in KAP (my APL derivative), I tried to write it in a style that makes people unfamiliar with the array style more comfortable.

    This code could of course have been written in a style similar to some of the more extreme examples, and they would have been significantly shorter in that case.

  • Why would a Java prime sieve run at only half its speed _some_ of the times?
    9 projects | | 5 Feb 2022
    This issue isn't directly related to BitSet. I have observed the same thing in my programming language interpreter that runs on the JVM (well, it's written in Kotlin multiplatform so it runs on JS and Natively as well).

    I start the interpreter and measue the time it takes to all all then numbers below 1000000000.

    The first time I run it after starting the interpreter it always takes 1.4 seconds (within 0.1 second precision). The second time I measure the time it takes 1.7, and for every invocation following that it takes 2 seconds.

    If I stop the interpreter and try again, I get exactly the same result.

    I have not been able to explain this behaviour. This is on OpenJDK 11 by the way.

    If anyone wants to test this, just run the interpreter from here:

    To run the benchmark, type the following command in the UI:

        time:measureTime { +/⍳1000000000 }
  • Is APL Dead?
    7 projects | | 20 Oct 2021
  • Symbolic Programming
    3 projects | | 8 Aug 2021
  • Try APL
    7 projects | | 10 Jun 2021
    I'm the opportunity to mention my project that implements a language that is inspired by, and is mostly compatible with APL. It has some major differences, such as being lazy evaluated and providing support for first-class functions.

    It also supports defining syntax extensions which is used by the standard library to provide imperative syntax, which means you can mix traditional APL together with your familiar if/else statements, etc.

    At this point there isn't much documentation, and the implementation isn't complete, so I'm not actually suggesting that people run out to try it unless they are really interested in APL. I just took this opportunity since APL is mentioned so rarely here.

    There is an example of a graphical mandelbrot implementation in the demo directory, that may be interesting.

  • Why am I wasting time on EndBASIC?
    3 projects | | 23 Jan 2021
    This post mirrors my feeling on this topic as well. Just like the author, I'm also working on a programming language which will not be used by a lot of people.

    In fact, having a lot of users would make things complicated as I would have to stop making incompatible changes if I want to try something new.

    Designing your own programming language is such a nice hobby, and something I believe a lot of programmers do. In fact, I would like to see links to other people's programming languages, just to see what people are playing around with at the moment.

    Here is my project:


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 2022-05-16.
  • A bit unjust but ok
    1 project | | 20 May 2022
  • In my experience, Julia and its packages have the highest rate of serious correctness bugs of any programming system I’ve used, and I started programming with Visual Basic 6 in the mid-2000s.
    2 projects | | 16 May 2022
  • The Julia language has a number of correctness flaws
    19 projects | | 16 May 2022
    Everything has correctness issues somewhere. Julia ships an entire patched version of LLVM to fix correctness bugs in numerical methods. It has its own implementations of things like software-side FMA because the FMA implementation of Windows is incorrect: . Core Julia devs are now the maintainers of things like libuv because of how much had to be fixed there. So from those three points, that clearly points out tons of cases where Python, R, etc. code is all incorrect where Julia isn't.

    I think what's interesting about Julia is that because the code is all Julia, it's really easy to dig in there and find potential bugs. The standard library functions can be accessed with @edit sum(1:5) and there you go, hack away. The easier it is to look at the code, the easier it is to find issues with it. This is why Julia has such a higher developer to user ratio. That has its pros and cons of course. It democratizes the development process, but it means that people who don't have a ton of development experience (plus Fortran or C knowledge) are not excluded from contributing. Is that good or bad? Personally I believe it's good in the long run, but can have its bumps.

    The author highlights "for i in 1:length(A)". I agree, code should never do that. It should be `eachindex(A)`. In general things should use iterators which are designed for arbitrary indexing based on iterators. This is true in any language, though you'll always have some newcomers write code (and documentation) with this. Someone should just run a bot that opens a PR for every occurrence of this (especially in Base).

    19 projects | | 16 May 2022
    FWIW, I posted the other month that I'm looking for any devs who can help with building a multi-package documentation for SciML, since I don't think the "separate docs for all packages" ends up helpful when the usage is intertwined. SciML is looking for anyone looking to help out there. In the meantime, we're having a big push for more comprehensive docstrings, and will be planning a Cambridge area hackathon around this (follow for anyone who is curious in joining in).

    As for high level changes, there's a few not too difficult things I think that can be done: and are two I feel strongly about.

    19 projects | | 16 May 2022
    I feel this post is a bit unfair and quite outdated (seems like it's written 9-12 months ago), and I interpret his issue as a prioritization issue, not a language one. If your priorities mandate a more mature ecosystem, you should use one. The Julia ecosystem is much smaller - both in terms of people and development invested, than Python, Java or JavaScript, and still overperforms in many aspects of computing. If those aspects, where Julia is first-of-class, are not your priorities, and your fault tolerance is very low, maybe another tool is better for you.

    Also, as every ecosystem, the Julia Ecosystem will naturally see some packages come and go. JSON3 is the third approach to reading JSON (and it's terrific). HTTP.jl is the reference HTTP implementation - Julia hasn't had it's `` moment. Web frameworks have also been immature, python has had `Django`, `pyramid`, `flask` and so many others before `FastAPI` (along with new, language features) came and dominated. Some people need to put effort in attempts that will naturally hit a dead end before we have a super polished and neat FastAPI.jl, and the same goes for everything.

    Also, is referenced with a wrong name that involves the issue's author's misunderstanding, can you update please and, if possible, add a note about the edit?

    19 projects | | 16 May 2022
    So this one is a tough one for me, because Yuri has certainly spent significant time with Julia and I think he's a very competent programmer, so his criticism is certainly to be taken seriously and I'm sad to hear he ended up with a sour opinion.

    There's a lot of different issues mentioned in the post, so I'm not really sure what angle to best go at it from, but let me give it a shot anyway. I think there's a couple of different threads of complaints here. There's certainly one category of issues that are "just bugs" (I'm thinking of things like the HTTP, JSON, etc. issues mentioned). I guess the claim is that this happens more in Julia than in other systems. I don't really know how to judge this. Not that I think that the julia ecosystem has few bugs, just that in my experience, I basically see 2-3 critical issues whenever I try a new piece of software independent of what language it's written in.

    I think the other thread is "It's hard to know what's expected to work". I think that's a fair criticism and I agree with Yuri that there's some fundamental design decisions that are contributing here. Basically, Julia tries very hard to make composability work, even if the authors of the packages that you're composing don't know anything about each other. That's a critical feature that makes Julia as powerful as it is, but of course you can easily end up with situations where one or the other package is making implicit assumptions that are not documented (because the author didn't think the assumptions were important in the context of their own package) and you end up with correctness issues. This one is a bit of a tricky design problem. Certainly adding more language support for interfaces and verification thereof could be helpful, but not all implicit assumptions are easily capturable in interfaces. Perhaps there needs to be more explicit documentation around what combinations of packages are "supported". Usually the best way to tell right now is to see what downstream tests are done on CI and if there are any integration tests for the two packages. If there are, they're probably supposed to work together.

    To be honest, I'm a bit pained by the list of issues in the blog post. I think the bugs linked here will get fixed relatively quickly by the broader community (posts like this tend to have that effect), but as I said I do agree with Yuri that we should be thinking about some more fundamental improvements to the language to help out. Unfortunately, I can't really say that that is high priority at the moment. The way that most Julia development has worked for the two-ish years is that there are a number of "flagship" applications that are really pushing the boundary of what Julia can do, but at the same time also need a disproportionate amount of attention. I think it's overall a good development, because these applications are justifying many people's full time attention on improving Julia, but at the same time, the issues that these applications face (e.g. - "LLVM is too slow", better observability tooling, GC latency issues) are quite different from the issues that your average open source julia developer encounters. Pre 1.0 (i.e. in 2018) there was a good 1-2 year period where all we did was think through and overhaul the generic interfaces in the language. I think we could use another one of those efforts now, but at least that this precise moment, I don't think we have the bandwidth for it. Hopefully in the future, once things settle down a bit, we'll be able to do that, which would presumably be what becomes Julia 2.0.

    Lastly, some nitpicking on the HN editorialization of the title. Only of the issues linked ( is actually a bug in the language - the rest are various ecosystem issues. Now, I don't want to disclaim responsibility there, because a lot of those packages are also co-maintained by core julia developers and we certainly feel responsibility to make those work well, but if you're gonna call my baby ugly, at least point at the right baby ;)

    19 projects | | 16 May 2022
  • Upcomming language to try?
    4 projects | | 15 May 2022
  • Beginner at programming.
    2 projects | | 12 May 2022
    Its design and attitude is flawed. It was good 12 years ago, but has been made obsolete by languages like Julia.
  • Minimal extension to make trig work with a custom type
    1 project | | 12 May 2022
    I found it in the source code for Base. You were definitely right. The sin function, for instance, is written there as sin(x::T) where T

What are some alternatives?

When comparing array and julia you can also consider the following projects:

jax - Composable transformations of Python+NumPy programs: differentiate, vectorize, JIT to GPU/TPU, and more

NetworkX - Network Analysis in Python

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.

rust-numpy - PyO3-based Rust bindings of the NumPy C-API

Numba - NumPy aware dynamic Python compiler using LLVM

StaticCompiler.jl - Compiles Julia code to a standalone library (experimental)

F# - Please file issues or pull requests here:

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

JLD2.jl - HDF5-compatible file format in pure Julia

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

awesome-lisp-companies - Awesome Lisp Companies

duckdf - 🦆 SQL for R dataframes, with ducks