# List of most desired features for Julia v1.x

**URL:** <https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481>\
**Category:** Community\
**Tags:** gripes, suggestions\
**Created:** [June 27, 2017, 3:27am UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481 "2017-06-27T03:27:19Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![dlfivefifty](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dlfivefifty/32/1959_2.png) [@dlfivefifty](https://discourse.julialang.org/u/dlfivefifty)\
**Post date:** [June 27, 2017, 10:15am UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/22 "2017-06-27T10:15:42Z")

</div>

GLVisualize.jl has 2D and 3D plotting directly on the GPU, so is lightening fast (or at least as fast as copying data to the GPU).

I believe future versions will interact with GPUArrays.jl

---

<div class="post-metadata">

**Author:** ![Diego\_Javier\_Zea](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/diego_javier_zea/32/1858_2.png) [@Diego\_Javier\_Zea](https://discourse.julialang.org/u/Diego_Javier_Zea)\
**Post date:** [June 27, 2017, 10:16am UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/23 "2017-06-27T10:16:25Z")

</div>

I’m in favor of compiling Julia v1.0 code to executables. Executables and web-servers are useful for sharing methods with scientists who do not have programming skills.

---

<div class="post-metadata">

**Author:** ![lobingera](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lobingera/32/211_2.png) [@lobingera](https://discourse.julialang.org/u/lobingera)\
**Post date:** [June 27, 2017, 10:22am UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/24 "2017-06-27T10:22:34Z")

</div>

a few random points:

- debugger
- Usability issues like proxy setting for git/libgit2
- correct line number report for syntax or similar issues
- consolidation of package environment
- spend some effort on infrastructure services like WinRPM/BinDeps/Clang/Cxx/Cxxwrap
- (i don’t know how to formulate this correctly) native datatype/syntax for AST.
- solving the ‘name is already exported’ problem
- multi module packages (?)
- patching packages externally (overwriting/patching Module.X = function newY(a::Int64) etc.
- more testing

---

<div class="post-metadata">

**Author:** ![slowbrain](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/slowbrain/32/2224_2.png) [@slowbrain](https://discourse.julialang.org/u/slowbrain)\
**Post date:** [June 27, 2017, 10:26am UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/25 "2017-06-27T10:26:17Z")

</div>

Indeed I fully agree that for reproducible research to have the source code is the most important thing. I’ve never said otherwise. 😉 As mentioned before by @oxinabox there is always a need for source code and I second that.

Please let me explain what I meant under _relevancy_ though.  
My workflow is very simple and straight forward:  
`raw experimental data processing -> data to work with`

Once all work is done on code I’m able to apply same “black box” (version controlled) on any data from my experiment.  
That “black box” contains all possible outside packages dependencies at the time the source code was properly tested and finalized. This will assure that if there is some breaking update on any package it will not break the workflow.  
Executable is a snapshot of the code that can be indeed further deployed and distributed to other colleagues that are not as skilled in compiling the code.

Definitely not a blocking 1.0 feature.

---

<div class="post-metadata">

**Author:** ![kristoffer.carlsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kristoffer.carlsson/32/22_2.png) [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)\
**Post date:** [June 27, 2017, 10:34am UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/26 "2017-06-27T10:34:27Z")

</div>

String concatenation with `+`.

---

<div class="post-metadata">

**Author:** ![Steven\_Sagaert](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/steven_sagaert/32/29578_2.png) [@Steven\_Sagaert](https://discourse.julialang.org/u/Steven_Sagaert)\
**Post date:** [June 27, 2017, 10:36am UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/27 "2017-06-27T10:36:05Z")

</div>

- ahead of time static compilation. Meaning: not just building an executable (that can be done by embedding a julia interpreter in an exec) but having the compiler use the type information and getting the type errors at compile time instead of runtime.
- multithreading sorted out
- working debugger (not just prototypes)
- stable fast IDE
- having a true public/private visibility mechanism in packages that is enforeced by the compiler.
- hierarchical namespaces for packages. Having all packages in a long linear list on package sites gets unwieldy quite quickly. But also in the source code itself I’d like to have hierarchical organization of packages into groups and have the editor/IDE code completion work with that for showing suggestions. All modern general purpose programming languages have this (including Python of course). It just seems that older data science specific languages “sin” against this, e.g. R & matlab. I’d rather not have julia make the same mistake.
- some more curation in the package ecosystem. I know there is already some and that’s great but I also would like to see old abandoned packages removed from the “official” list and I 'd like see some metrics (either automatic or manually maintained) around popularity, quality, age, stability, …

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [June 27, 2017, 11:05am UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/28 "2017-06-27T11:05:12Z")

</div>

> [@DNF](#):
>
> My list has only three items:

Thought of one more: easier to reload (or possibly auto-reload) code when I modify it. I’m struggling quite a bit with this. `ClobberingReload` or the Junolab workflow are supposed to solve this, but I find them difficult to use or error-prone.

So I pretty much end up restarting Julia _all the time._

---

<div class="post-metadata">

**Author:** ![oxinabox](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oxinabox/32/206603_2.png) [@oxinabox](https://discourse.julialang.org/u/oxinabox)\
**Post date:** [June 27, 2017, 11:08am UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/29 "2017-06-27T11:08:42Z")

</div>

> [@Steven\_Sagaert](#):
>
> ahead of time static compilation. Meaning: … having the compiler use the type information and getting the type errors at compile time instead of runtime.

Doing this comprehensively in julia can be reduced to the halting problem.  
And is thus impossible.  
It can also be trivially shown that the type of a variably is not nesc deterministicly known at compile time.  
Eg `x=ones(now > 2018 ? Int32, Float64)`  
Doing this partially, where it is possible is either, an optimisation, or part of linting.  
Since it can’t be done with certainty you can’t base behavior or errors off of it.  
(Julia, unlike static languages, does not require all types to be inferable)

---

<div class="post-metadata">

**Author:** ![Steven\_Sagaert](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/steven_sagaert/32/29578_2.png) [@Steven\_Sagaert](https://discourse.julialang.org/u/Steven_Sagaert)\
**Post date:** [June 27, 2017, 12:23pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/30 "2017-06-27T12:23:12Z")

</div>

But when the types are given by the programmer (for example in all function arguments) then I’d like to know about violations against the given types at compile time rather than runtime (if possible. Maybe it’s not possible due to multiple dispatch…).

Also languages like Scala (& I think Haskell) let the compiler issue an error when it cannot resolve the type via inference. This error basically says that the user should add a type annotation. That system works in practice.

---

<div class="post-metadata">

**Author:** ![mauro3](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mauro3/32/292_2.png) [@mauro3](https://discourse.julialang.org/u/mauro3)\
**Post date:** [June 27, 2017, 1:07pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/31 "2017-06-27T13:07:44Z")

</div>

@Steven_Sagaert: see this issue:

> <https://github.com/JuliaLang/julia/issues/10980>
>
> Given the importance of type stability, I would like to propose a new language c…onstruct that would allow semi-static checking of type stable blocks. In the module I am developing, I am frequently using this type of construct
> 
> \`\`\` julia
> function f(a)
> # Type stability
> @stabilize m::Matrix{Float64} = a.m
> 
> # Compute things with m
> 
> end
> ...
> \`\`\`
> 
> I know there are:
> 1. The possibility to use a function - but this can be cumbersome when there are many types, and in makes the code harder to read (at least for me)
> 2. Tools like Lint or TypeCheck, and the macro \`@code\_warntype\` that are useful to see/check whether the written code is type stable
> 
> but I would really like to have something that prevents code from being instable, e.g. using a "stable block" (I check and this gives a syntax error with julia 0.\[34\]):
> 
> \`\`\` julia
> function f(a)
> # Type stability
> @stabilize m::Matrix{Float64} = a.m
> 
> stable begin
> # Compute things - compilation error (or warning) if there is some type instability within the code
> end
> 
> end
> ...
> \`\`\`
> 
> Another syntactic possibility would be to use pragmas #7449 (if they make it in the language).

---

<div class="post-metadata">

**Author:** ![oatlzzvztd](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oatlzzvztd/32/3285_2.png) [@oatlzzvztd](https://discourse.julialang.org/u/oatlzzvztd)\
**Post date:** [June 27, 2017, 1:09pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/32 "2017-06-27T13:09:00Z")

</div>

- Compilation to executables. Not sure why so many people seem allergic to it.
- An actual debugger.
- Better reloading, being able to develop from the REPL without constantly rebooting it (no other REPL requires this much restarting to get work done).
- A no-kidding replacement for PyPlot.jl that doesn’t crash half the time.

---

<div class="post-metadata">

**Author:** ![lobingera](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lobingera/32/211_2.png) [@lobingera](https://discourse.julialang.org/u/lobingera)\
**Post date:** [June 27, 2017, 1:26pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/33 "2017-06-27T13:26:11Z")

</div>

I wondered now for some time: Why didn’t Julia have return type definition from the beginning? What is the benefit of type-unstable code?

---

<div class="post-metadata">

**Author:** ![lobingera](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lobingera/32/211_2.png) [@lobingera](https://discourse.julialang.org/u/lobingera)\
**Post date:** [June 27, 2017, 1:27pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/34 "2017-06-27T13:27:02Z")

</div>

> [@oxinabox](#):
>
> Eg x=ones(now \> 2018 ? Int32, Float64)

Please show me a use-case for this.

---

<div class="post-metadata">

**Author:** ![ExpandingMan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/expandingman/32/866_2.png) [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)\
**Post date:** [June 27, 2017, 1:48pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/35 "2017-06-27T13:48:24Z")

</div>

Lots of good points, +1 from me on most of what’s listed here.

One thing I would really like to see moved into `Base` is [MacroTools.jl](https://github.com/MikeInnes/MacroTools.jl). It seems important to make everyone aware of it and to guarantee its maintenance, and it would be nice if most of the macro code sitting around in the ecosystem used it, because frankly macro code that doesn’t use it can sometimes be absolutely horrendous (and oddly “non-Julian”).

The _ **only** _ thing I miss about python is the **debugging** , so having a good debugger is something I very badly want. The debugger seems to have been completely abandoned, is that the case?

I’m not sure I understand why compiled binaries are so important to people.

> [@slowbrain](#):
>
> I find executables quite relevant in reproducible research…

I emphatically agree with @Tamas_Papp, if one can’t reproduce somebody’s results using their source code and data only one should be suspicious of the result. If in the course of my research a collaborator told me that I had to use a particular compiled binary it would make me very uncomfortable and I would not be willing to conduct research that way. I would even go as far as to say that I would only trust a result if I could make changes to the source code and see that the result depends on those changes in a reasonable way.

The only use I can think of for compiled binaries (other than obfuscation) is for guaranteeing no “run-time compilation”, possibly incorporating more extensive compile-time optimizations. While this seems absolutely necessary for, for example, video games, it some how seems less imperative for scientific and numerical purposes. That said, I think we all agree it’s a feature we’d like to have eventually.

---

<div class="post-metadata">

**Author:** ![cortner](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cortner/32/204_2.png) [@cortner](https://discourse.julialang.org/u/cortner)\
**Post date:** [June 27, 2017, 2:13pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/36 "2017-06-27T14:13:43Z")

</div>

- debugging
- copy-on-write slicing

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [June 27, 2017, 2:18pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/37 "2017-06-27T14:18:17Z")

</div>

> [@oatlzzvztd](#):
>
> Compilation to executables. Not sure why so many people seem allergic to it.

Can you quote a single person who is against it? I can’t. It’s just understandably not high on most people’s priority list, since it doesn’t actually effect language usage and most people aren’t compiling code from dynamic languages. Sure, it will be more useful from Julia than other languages, but the ability to use an interactive language non-interactively just doesn’t affect most people.

> [@lobingera](#):
>
> solving the ‘name is already exported’ problem

Jeff mentioned something about automatically binding functions which would fix this. I am not sure if this would actually be breaking though (?), so it might be fine for a minor release instead of 1.0.

> [@slowbrain](#):
>
> That “black box” contains all possible outside packages dependencies at the time the source code was properly tested and finalized. This will assure that if there is some breaking update on any package it will not break the workflow.

Docker? Not sure why people are suggesting that executables are the answer to this when we have much more modern tools for handling scientific reproduciblility issues than “smash it all into a binary that humans can’t read”. @ExpandingMan sums it up pretty nicely.

> [@lobingera](#):
>
> quite ironic as some people have been given the advice to move away from Gadfly (the ‘slow’ plotting solution) to Plots (the ‘fast’ plotting solution). Looks like, the underlying problem - in pre- oder partial-pre compilation - is the same for complex data handling and transformation issues.
> 
> Is there something readable about how and where the time is spend in Plots.jl ?

Plots.jl doesn’t precompile and it lazy loads backends, so it’s not the same at all. These became big issues with some of the changes due to v0.6. There are fixes in the works, like [https://github.com/JuliaPlots/Plots.jl/pull/916](https://github.com/JuliaPlots/Plots.jl/pull/916).

> [@antoine-levitt](#):
>
> - an error printing that differentiates between errors in my code and in Base, so I can quickly see where my bug is

Differentiation between Base and user code was brought up in conversations at JuliaCon and is an interesting topic. Julia is written in Julia, so it uniquely has this problem. A mode to make the debugger ignore Base would be helpful in many cases.

> [@lobingera](#):
>
> spend some effort on infrastructure services like WinRPM/BinDeps/Clang/Cxx/Cxxwrap

Yes. BinDeps2 was brought up as a Julia 1.x goal in Stefan’s talk.

> [@DNF](#):
>
> Thought of one more: easier to reload (or possibly auto-reload) code when I modify it. I’m struggling quite a bit with this. ClobberingReload or the Junolab workflow are supposed to solve this, but I find them difficult to use or error-prone.

Did the 265 fix not do this?

> [@ExpandingMan](#):
>
> The only thing I miss about python is the debugging, so having a good debugger is something I very badly want. The debugger seems to have been completely abandoned, is that the case?

@Keno knows about the debugger issues. I think lately he was pretty busy making Julia enter the list of languages which have achieved petascale (what else has? C, C++, Fortran, and Assembler? @dpsanders made a good point that it’s probably a short list).

> [@lobingera](#):
>
> I wondered now for some time: Why didn’t Julia have return type definition from the beginning? What is the benefit of type-unstable code?

> [@lobingera](#):
>
> Please show me a use-case for this.

Again? [Why type instability? - #8 by ChrisRackauckas](https://discourse.julialang.org/t/why-type-instability/4013/8)

Notice that @oxinabox’s example is very close to how `factorize` works, except branching off of the matrix type. It’s a feature, though the ability to turn on additional checks would be nice.

---

<div class="post-metadata">

**Author:** ![oatlzzvztd](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oatlzzvztd/32/3285_2.png) [@oatlzzvztd](https://discourse.julialang.org/u/oatlzzvztd)\
**Post date:** [June 27, 2017, 2:30pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/38 "2017-06-27T14:30:44Z")

</div>

> [@ChrisRackauckas](#):
>
> Can you quote a single person who is against it?

Every time anyone brings it up, the response is “it shouldn’t be necessary” or “there’s no use case for it”, despite people in the community asking for it about twice a month. That’s what I mean by “allergic”, which doesn’t necessarily mean “against it”.

After all, I quite enjoy ice cream, but the day after not so much.

---

<div class="post-metadata">

**Author:** ![juliohm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juliohm/32/215266_2.png) [@juliohm](https://discourse.julialang.org/u/juliohm)\
**Post date:** [June 27, 2017, 2:32pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/39 "2017-06-27T14:32:16Z")

</div>

Let’s stop the discussion around executables and move on to other more interesting features?

It is a **well known fact** that:

- Research should be **open source**
- Executables are good for **commercial** products

To all of you that stayed on-topic, a big thanks! Really good list of features, I am bookmarking all of them.

---

<div class="post-metadata">

**Author:** ![juliohm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juliohm/32/215266_2.png) [@juliohm](https://discourse.julialang.org/u/juliohm)\
**Post date:** [June 27, 2017, 3:00pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/41 "2017-06-27T15:00:28Z")

</div>

> [@Tamas\_Papp](#):
>
> DataFrames/DataTables/DataUtils/IterableTables/IndexedTables/DataIKEA needs to work itself out (see compiler optimizations for small unions). I am honestly lost here.
> 
> 💯

The whole data stack deserves attention. 👍 I am delaying my use of DataFrames as much as I can because everything is constantly changing. From JuliaCon 2017, I saw at least 3 presentations on DataFrames, Queries, Databases, etc. We need a comprehensive framework for manipulating/storing/plotting data in Julia.

---

<div class="post-metadata">

**Author:** ![malmaud](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/malmaud/32/29_2.png) [@malmaud](https://discourse.julialang.org/u/malmaud)\
**Post date:** [June 27, 2017, 3:38pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/42 "2017-06-27T15:38:15Z")

</div>

The debugger isn’t abandoned - it’s maintained by Keno, who has been busy on Celeste.jl recently. It’s going to be updated for 0.6.

I don’t know for certain, but it seems likely that the new financing Julia Computing obtained will partially be used to support the debugger as well.

[Previous page](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481.md?page=1)

[Next page](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481.md?page=3)