# Discussion on "Why I no longer recommend Julia" by Yuri Vishnevsky
**URL:** https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151
**Category:** Community
**Tags:** discussion
**Created:** [May 16, 2022, 2:33pm UTC](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151 "2022-05-16T14:33:38Z")
**Posts on this page:** 20
**Page:** 4
### Author:  [@mkitti](https://discourse.julialang.org/u/mkitti)
#### Post date: [May 17, 2022, 5:15pm UTC](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151/62 "2022-05-17T17:15:38Z")
> [@tobydriscoll](#):
>
> This is a great point about the “sticks” or barriers to contributing. But the “carrots” are just as big a problem. Maybe bigger, when you consider what obstacles people endure to publish papers.
I have been fortunate to have recently moved to a Software Engineer role from being a research academic while being employed at an institution willing to invest in open source infrastructure. We recently launched an Open Science Software Initiative:
> **[Open Science Software Initiative (OSSI)](https://www.janelia.org/open-science/overview/open-science-software-initiative-ossi)**
>
> Summary Open-source code and software are immensely important to progress in all areas of science. Sharing code allows the same analyses to be performed across labs, facilitates wide-spread use of
We have a ways to go to raise the standards for academic open source software, but I do think we are starting to some funding for this purpose. That said Julia’s package and Github architecture make this a lot easier. We just need to expand the tooling as we gain collective experience with Julia.
---
### Author:  [@martin.d.maas](https://discourse.julialang.org/u/martin.d.maas)
#### Post date: [May 17, 2022, 5:31pm UTC](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151/63 "2022-05-17T17:31:32Z")
> As such, when iterating over an entire array, it’s much better to iterate over [`eachindex(A)`](https://docs.julialang.org/en/v1/base/arrays/#Base.eachindex)instead of `1:length(A)` . Not only will the former be much faster in cases where `A` is `IndexCartesian` , but it will also support **OffsetArrays** , too.
Ok, I guess if that was a part of the official documentation, then that’s the solution – we should consider `1:length(A)` as bad practice, or at least highlight `eachindex(A)` as the best practice, especially in conjunction with `@inbounds`.
I’ve just summited PRs to change this to “notes” and “warnings” in the docs (this info was not visible enough imho). Maybe the docstrings in `@inbounds` could be edited as well…
---
### Author:  [@suavesito](https://discourse.julialang.org/u/suavesito)
#### Post date: [May 17, 2022, 5:49pm UTC](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151/64 "2022-05-17T17:49:38Z")
> [@Palli](#):
>
> it wasn’t very dangerous (more so than no checking in e.g. C/C++)
I mean, it technically was always as dangerous as `unsafe_load`, obvious under the assumption that `--check-bound=no`, but that is the default.
I just [filled an issue](https://github.com/JuliaLang/julia/issues/45342) to deprecate it and change it to `@unsafe_inbounds`.
---
### Author:  [@mkitti](https://discourse.julialang.org/u/mkitti)
#### Post date: [May 17, 2022, 6:06pm UTC](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151/65 "2022-05-17T18:06:03Z")
> [@suavesito](#):
>
> I mean, it technically was always as dangerous as `unsafe_load` , obvious under the assumption that `--check-bound=no` , but that is the default.
>
> I just [filled an issue](https://github.com/JuliaLang/julia/issues/45342) to deprecate it and change it to `@unsafe_inbounds` .
This would be breaking. It would probably need to be a Julia 2.0 feature if implemented.
---
### Author:  [@suavesito](https://discourse.julialang.org/u/suavesito)
#### Post date: [May 17, 2022, 6:07pm UTC](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151/66 "2022-05-17T18:07:48Z")
Sorry, I forgot to mention that it would be deprecated, still usable but with a warning about using the new name. 😅
---
### Author:  [@jules](https://discourse.julialang.org/u/jules)
#### Post date: [May 17, 2022, 6:08pm UTC](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151/67 "2022-05-17T18:08:08Z")
What exactly should an interface promise? One level could be that of type signatures that have to be available for certain functions. So for example an AbstractArray would have to show that you can call `size()` on it and receive let’s say a tuple of integers. But type signatures of functions, while already quite useful if they’re being automatically checked, don’t save you from the OffsetArrays issue mentioned here, which is more about the logical interface. And this seems much harder to pin down, and test automatically in generic fashion.
I for one would already like a type-signature-checking interface option. Maybe just implemented via macros so you can say `@declare_interface_compatible SomeInterface MyType` and then it’s checked that a bunch of previously declared function signatures can be correctly inferred when using `MyType`. And if not it would error and say “MyType doesn’t fulfill SomeInterface because of …”.
And where you use interface functions they could check that the types being used have been compile-time checked for interface compatibility. Maybe with Tricks.jl or something like that.
---
### Author:  [@ImreSamu](https://discourse.julialang.org/u/ImreSamu)
#### Post date: [May 17, 2022, 7:23pm UTC](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151/68 "2022-05-17T19:23:39Z")
> [@non-Jedi](#):
>
> `1:length(v)`
ouch …
checking the public github repos with the new (beta) [“GitHub code search”](https://github.blog/2021-12-08-improving-github-code-search/)
[https://cs.github.com/](https://cs.github.com/) AND with:
- `language:julia "=1:length("`
- `language:julia "1:length("`
- `language:julia "for i=1:length("`
- `language:julia "@inbounds for i=1:length("`
there are many hits…
---
### Author:  [@lostella](https://discourse.julialang.org/u/lostella)
#### Post date: [May 17, 2022, 7:35pm UTC](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151/69 "2022-05-17T19:35:54Z")
It will be interesting to check how many are left in a couple weeks. Thousands of bugs solved all at once!
---
### Author:  [@pjentsch0](https://discourse.julialang.org/u/pjentsch0)
#### Post date: [May 17, 2022, 7:43pm UTC](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151/70 "2022-05-17T19:43:27Z")
I mean, it depends on the code.
I have used that pattern in a lot of my research code, but that code does the data analysis for my papers, and it isn’t meant to be used with any types other than what I have written and therefore tested (usually just `Array`).
I would imagine a lot of the hits you see are in the same boat. The issue here is that `StatsBase` is an extremely popular package that can be reasonably assumed to be called with any `AbstractArray`.
---
### Author:  [@DNF](https://discourse.julialang.org/u/DNF)
#### Post date: [May 17, 2022, 8:15pm UTC](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151/71 "2022-05-17T20:15:38Z")
> [@ImreSamu](#):
>
> language:julia “=1:length(”
I would assume variations of `in 1:length` is more common than `=1:length`. There’s also `= 1:length,`, `= 1 : length`, etc.
---
### Author:  [@Kia\_Kia](https://discourse.julialang.org/u/Kia_Kia)
#### Post date: [May 17, 2022, 8:41pm UTC](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151/72 "2022-05-17T20:41:05Z")
This post was temporarily hidden by the community for possibly being off-topic, unfocused, inappropriate, or spammy.
---
### Author:  [@JohnnyChen94](https://discourse.julialang.org/u/JohnnyChen94)
#### Post date: [May 17, 2022, 8:44pm UTC](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151/73 "2022-05-17T20:44:20Z")
Since almost everyone starts to know the danger of `@inbounds for i = 1:length(v)` and OffsetArrays. Here’s some additional advice based on my JuliaImages experience:
[https://github.com/JuliaArrays/OffsetArrays.jl/pull/281](https://github.com/JuliaArrays/OffsetArrays.jl/pull/281)
* * *
But try to think broadly, Yuri doesn’t mean to blame the particular OffsetArrays or Zygote packages – he tries to point out that the Julia ecosystem/community don’t yet have a good tooling/mechanisim to allow non-experts build large but reliable Julia package – that’s all I understand.
---
### Author:  [@ImreSamu](https://discourse.julialang.org/u/ImreSamu)
#### Post date: [May 17, 2022, 8:44pm UTC](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151/74 "2022-05-17T20:44:38Z")
thanks for the tips!
limiting the search:
`org:julialang`
- `org:julialang language:julia "1 : length"`
- `org:julialang language:julia "1:length"`
`org:JuliaComputing` :
- `org:JuliaComputing language:julia "1:length"`
---
### Author:  [@jlapeyre](https://discourse.julialang.org/u/jlapeyre)
#### Post date: [May 17, 2022, 8:49pm UTC](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151/75 "2022-05-17T20:49:02Z")
I believe that some people find lots of bugs in Base and the ecosystem. I must use Julia in a different way because I very rarely run into bugs. I don’t recall ever finding one in Base, but I might have forgotten something. So whether Julia is usable might depend on the kind of user. Julia has generally been very reliable for me. But, if it isn’t for important segments of users, that’s a big problem.
These past few days I could have really used “zero based” Array indexing. But, I knew it would probably be more trouble than its worth. I kinda thought it was general knowledge that , while Julia has some support for this, it’s nothing you can rely on in general. I mean this is a feature, not a core feature, that is not really well supported (in practice; the tools are there). There are issues of broader import like interfaces.
Poorly defined and enforced or tested interfaces is a big problem. It hasn’t been a pain point in my work. But, it clearly needs a big shift in culture/tools.
I started using JET and Aqua. They found bugs . This is great. My goal is to use them in all my packages. Everyone should use tools like these. Almost no one does.The registrator complains about all kinds of things, but not that I haven’t passed some analysis requirements (eg JET)
---
### Author:  [@Mason](https://discourse.julialang.org/u/Mason)
#### Post date: [May 17, 2022, 8:55pm UTC](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151/76 "2022-05-17T20:55:58Z")
> [@Kia\_Kia](#):
>
> If users of Julia have been spending time on real use of the existing packages instead of sparing time on forums, the bugs and issues of those packages could have been identified and solved much faster. 😉 😉 😉
First of all, please don’t do this here. Trolling and flamebaiting are not welcome
Secondly, most of issues in the blog-post were identified and fixed long before the blogpost was ever posted. The community takes fixing bugs pretty seriously, and the forum is a big part of how they coordinate and approach that work.
---
### Author:  [@pjentsch0](https://discourse.julialang.org/u/pjentsch0)
#### Post date: [May 17, 2022, 9:17pm UTC](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151/77 "2022-05-17T21:17:38Z")
I think this brings up some other good points.
Yuri, and others who report similar issues, ran into these problems at least partially because they were developers of packages that try to innovate within the ecosystem. Such package development will naturally find the corner cases.
---
### Author:  [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)
#### Post date: [May 17, 2022, 9:36pm UTC](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151/78 "2022-05-17T21:36:01Z")
There are reasons I don’t recommend Julia to some people but bugs are not one. There’s a lot of software I use that is difficult to even get working on windows let alone design novel packaging on top of without creating many bugs
---
### Author:  [@martin.d.maas](https://discourse.julialang.org/u/martin.d.maas)
#### Post date: [May 17, 2022, 10:30pm UTC](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151/79 "2022-05-17T22:30:17Z")
> [@JohnnyChen94](#):
>
> But try to think broadly, Yuri doesn’t mean to blame the particular OffsetArrays or Zygote packages – he tries to point out that the Julia ecosystem/community don’t yet have a good tooling/mechanisim to allow non-experts build large but reliable Julia package – that’s all I understand.
I tend to disagree with the OA on this – I don’t want to blame the entire language/ecosystem because of silent bugs involving OffsetArrays and @inbounds.
I still think OffsetArrays are a bad idea, though, and I don’t see the point for them.
In my own code, I usually need to iterate over a matrix, and I normally do things like:
```julia
for i ∈ 1:size(A,1), j ∈ 1:size(A,2)
A[i,j] = sin(x[i]) * cos(y[j])
end
```
which is very succinct and easy to understand… and if I want to traverse the diagonal of `A`, this is simply:
```julia
for i ∈ 1:size(A,1)
A[i,i] = A[i,i] + 1
end
```
To support OffsetArrays, I should do:
```julia
for I ∈ CartesianIndices(A)
A[I[1],I[2]] = sin(x[I[1]]) * cos(y[I[2]])
end
```
Which is ok. But right now, I don’t know how to traverse the diagonal of a matrix in a way that supports OffsetArrays.
There seems to be an explanation in the OffsetArrays.jl home page about how to use `Diagonal` from the LinearAlgebra package (which looks like it’s converting the OffsetArray to a standard array), but what really caught my eyes was:
> Certain libraries, such as LinearAlgebra, require arrays to be indexed from 1
```julia
ERROR: ArgumentError: offset arrays are not supported but got an array with index other than 1
```
I believe that would be the quickest/wisest solution, just make more base libraries incompatible with OffsetArrays.
Unless, of course, somebody kindly illustrates what is the **real need** for OffsetArrays, I think that should be the best solution for most packages.
---
### Author:  [@jling](https://discourse.julialang.org/u/jling)
#### Post date: [May 17, 2022, 10:42pm UTC](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151/80 "2022-05-17T22:42:47Z")
> [@martin.d.maas](#):
>
> I still think OffsetArrays are a bad idea
it’s just a package, there’s no “bad idea”, if you don’t like handle it in your package, don’t. You don’t even have to make a warning, because Julia never made the promise that because the multi dispatch would allow you to run generic code on previously unknown types, it would work correctly logically speaking. One just have to know what they’re using / doing – like in any language
---
### Author:  [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [May 17, 2022, 10:47pm UTC](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151/81 "2022-05-17T22:47:46Z")
I’m sympathetic to Yuri’s larger point: Julia as a language and ecosystem is permissive by default. You can easily combine packages in ways that are unlikely to work and get mired in the weeds. For example, I can easily imagine attempting to differentiate a distributed SVD of a BlockedArray filled with Unitful Quaternions. Sure, that’s an absurd example and it’s unlikely to work, but I can imagine how it _might_ work and may even be able to construct the problem statement in a few lines of code. And heck, if I’m intrepid, I think I _could_ make it work.
That’s also the promise of Julia: you can (sometimes) take two unrelated packages that know nothing about each other and the combination suddenly provides powerful new functionality. Often with no code changes. And it’s amazing.
But sometimes a package doesn’t quite do what the other expects. It’ll typically just error, but OffsetArrays are a very obvious and salient example where it can result in silent corruption due to `@inbounds`.
[Previous page](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151.md?page=3)
[Next page](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151.md?page=5)