# 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:** 8

<div class="post-metadata">

**Author:** ![jlperla](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlperla/32/34332_2.png) [@jlperla](https://discourse.julialang.org/u/jlperla)\
**Post date:** [October 2, 2017, 7:58pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/144 "2017-10-02T19:58:18Z")

</div>

@mauro3 For sure.

Hopefully this gets integrated into the default Juno setup prior to 1.0, so that users evaluating Julia get a good impression right out of the box. There doesn’t need to be a long-term solution to this issue. I am pretty sure that casual users evaluating Julia would find their way to documentation describing how to tweak performance at the point they need it, but I doubt that people would get far enough to setup and properly use `Revise.jl` on their own.

---

<div class="post-metadata">

**Author:** ![tim.holy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tim.holy/32/52_2.png) [@tim.holy](https://discourse.julialang.org/u/tim.holy)\
**Post date:** [October 3, 2017, 2:12am UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/145 "2017-10-03T02:12:55Z")

</div>

I’d definitely like to make Revise “default” for most people; the worry would be causing some kind of regression. I think there are a few things that need to improve before that can be possible, but [https://github.com/JuliaLang/julia/pull/23898](https://github.com/JuliaLang/julia/pull/23898) goes most of the way. I may add [https://github.com/JuliaLang/julia/issues/23448](https://github.com/JuliaLang/julia/issues/23448) because one negative of Revise is that it increases load time since it has to re-parse the source code for all that packages you use.

The other concern is that for a few people, file polling seems flaky. [https://github.com/timholy/Revise.jl/issues/42](https://github.com/timholy/Revise.jl/issues/42). Not sure what to do about that.

By and large, though, if the things on my list get done I think we should just make it part of the default experience.

---

<div class="post-metadata">

**Author:** ![e3c6](https://avatars.discourse-cdn.com/v4/letter/e/e79b87/32.png) [@e3c6](https://discourse.julialang.org/u/e3c6)\
**Post date:** [October 8, 2017, 9:54am UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/146 "2017-10-08T09:54:26Z")

</div>

A **graphical debugger** , please.

I was a previous Windows user, then switched to Linux and never looked back. But I really miss debugging programs in Visual Studio. If we ever got a debugging experience like that with Julia, in Linux …

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [October 13, 2017, 11:06am UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/147 "2017-10-13T11:06:35Z")

</div>

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

I disagree on this for science, as in your code as a [Windows] .exe (machine code).

EDIT: I see now (having read the whole thread…phew), the rest of my post is mostly redundant with what others have said.\*

a) It may not be enough, in theory you would need to know e.g. OS/Windows version. Every detail and down to exact CPU version (see e.g. famous [old] Intel Pentium FDIV bug) can affect results (and e.g. environment variables for threading, I believe also in the .exe scenario).

For “reproachable research” I think it’s not just needed to have the same exact data and same source code, you need to know also exact version number of Julia runtime (and dependencies used, unless statically linked in) and the version/type of OS.

Having the source code of your research, not just a binary, helps in validating if there are bugs in your code, and possibly in the Julia runtime, and if you only get an .exe made with a specific Julia runtime, then you force your user to use a possible say 0.6 bug and the user can’t just upgrade to 1.0 and compare.

I’m not saying a .exe can’t be simpler and useful, just less so for science. I just find it very much needed that science users can see the source code. Maybe a compromise solution is possible, where the .exe is a self-extracting archive of the source code and a specific version of the Julia runtime, and it runs your code, but you could with a switch just get the source code.

b) a problem with a .exe is also it forces your users to use Windows…

> [@musm](#):
>
> so great about […] one compact exe download and bam you’re up and running. […] I can’t just send a julia script to a prof or lab member since they are not Julia users. And I know the professor is going to bother downloading and getting the Julia environment setup just to test or play around with my script."

Possibly a Freudian slip for: “I know the professor is NOT going to bother downloading” Julia. 🙂

* * *

\*Seems Docker is the “compromise” solution I mentioned above, ideal over regular .exe?:

> [@ChrisRackauckas](#):
>
> 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.

> [@oxinabox](#):
>
> Because if you are given an executable, how do you know it follows the description in the paper?

> [@Tamas\_Papp](#):
>
> I think that executables are probably the worst thing for reproducible research.

---

<div class="post-metadata">

**Author:** ![Daneel](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/daneel/32/175_2.png) [@Daneel](https://discourse.julialang.org/u/Daneel)\
**Post date:** [October 13, 2017, 12:04pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/148 "2017-10-13T12:04:27Z")

</div>

This is a topic I’ve been thinking about for some time but haven’t yet started a module for. It’s probably deserving of its own discussion separate from this so I’ll keep it short.

My idea has been to embed Julia version information, package versions, and possibly even code in images created in my plots. JPG images allow additional metadata and this could be a good place to store all of the data I mentioned. At some point I’ll get around to testing.

---

<div class="post-metadata">

**Author:** ![Ward9250](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ward9250/32/42768_2.png) [@Ward9250](https://discourse.julialang.org/u/Ward9250)\
**Post date:** [October 13, 2017, 2:43pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/149 "2017-10-13T14:43:12Z")

</div>

My big 2 are:

1. Self contained julia projects (Pkg3 I gather will do this).
2. More mature and user friendly shared memory threaded parallelism.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [October 13, 2017, 3:07pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/150 "2017-10-13T15:07:06Z")

</div>

> [@andyferris](#):
>
> When I read the title of this thread, I’m asking myself “what do I want to break?”

Yes, I noticed the title changed after your post from “… v1.0”, I think.

I tried pressing “Summarize This Topic”, but it seems not working, maybe a permission issue for me? If anyone can, explaining 1.0 (for breaking changes) vs. 1.x, meaning 1.1+ (for most ideas in the thread, that are not needed and _need_ not strictly make it for 1.0) might be in order.

And possibly list some non-breaking/package examples that people still want to get into 1.0, e.g. debugger…

* * *

Listing some examples (not that I want them in the summary…):

> [@Steven\_Sagaert](#):
>
> having a true public/private visibility mechanism in packages that is enforeced by the compiler.

Did you mean for 1.0, can this be non-breaking?

> [@Steven\_Sagaert](#):
>
> 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.

> [@oxinabox](#):
>
> 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)

```julia
0-dimensional Array{Float64,0}:
1.0

```

For some relevant types or these ones as an example, you would want Array{Union{Float64,Int32},0}. That would keep type-stability (just not sure the compiler could (as an optimization) or should give it for that exact code).

[Note it’s not really useful here to get a Union as every `Int32` (but not `Int64`) is a subset of Float64, just discussion the general principle to avoiding type-instability (that can be useful to have). Also let’s say you go with Unions, it might be a problem to get ever bigger Unions… if you do similar to this on Union values…]

The Union infrastructure (made for Nulls), would also allow you to give you Union{Int32, Float64} ? Since for Nulls at least, it’s implemented by an array of your values first, and then an array indicating Nullness, I’m not sure this would work for scalars; or would give two trivial arrays of one value each… I guess both the values values from each “array” could be optimized into two CPU registers, but not sure; can an array be “bitstype”?

This works:

```julia
julia> x=now > 2018 ? Union{Int32, Float64} : Float64
Union{Float64,Int32}

```

so I guess this is just an error that could be gotten around:

```julia
julia> x=ones(now > 2018 ? Union{Int32, Float64} : Float64)
ERROR: MethodError: Cannot `convert` an object of type Int64 to an object of type Union{Float64,Int32}
This may have arisen from a call to the constructor Union{Float64,Int32}(...),
since type constructors fall back to convert methods.
 in one(::Type{Union{Float64,Int32}}) at ./number.jl:64
 in ones(::Type{T}) at ./array.jl:169

```

---

<div class="post-metadata">

**Author:** ![chakravala](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chakravala/32/6832_2.png) [@chakravala](https://discourse.julialang.org/u/chakravala)\
**Post date:** [October 13, 2017, 4:58pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/151 "2017-10-13T16:58:05Z")

</div>

> [@Daneel](#):
>
> My idea has been to embed Julia version information, package versions, and possibly even code in images created in my plots. JPG images allow additional metadata and this could be a good place to store all of the data I mentioned. At some point I’ll get around to testing.

This sounds like something you could make a package for, it’s not something specific to the Julia base.

---

<div class="post-metadata">

**Author:** ![tuckermcclure](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tuckermcclure/32/1187_2.png) [@tuckermcclure](https://discourse.julialang.org/u/tuckermcclure)\
**Post date:** [October 20, 2017, 1:36am UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/152 "2017-10-20T01:36:44Z")

</div>

A simple desire: line continuation syntax. Sometimes, I just want to say, “I’m not done yet. Please continue to the next line, even though this line taken by itself appears to be a syntactically correct expression.” Maybe something like ↵?

```julia
the_first_transformation_matrix, a_vector_of_singular_values, the_second_transformation_matrix ↵
    = svd(the_original_matrix)

```

(Yes, I can just move the `=` up for this particular example, but I’m going for the general case here.)

---

<div class="post-metadata">

**Author:** ![xiaodai](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/xiaodai/32/15937_2.png) [@xiaodai](https://discourse.julialang.org/u/xiaodai)\
**Post date:** [October 20, 2017, 1:52am UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/153 "2017-10-20T01:52:19Z")

</div>

|\> to work with broadcasting

so I can do

x |\> fn1. |\> fn2. |\> fn3.  
instead of

fn3(fn2(fn1(x)))

---

<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:** [October 20, 2017, 2:06am UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/154 "2017-10-20T02:06:23Z")

</div>

> [@xiaodai](#):
>
> x |\> fn1. |\> fn2. |\> fn3.

`x .|> fn1 .|> fn2 .|> fn3`? It works like any other operator like `*`.

---

<div class="post-metadata">

**Author:** ![xiaodai](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/xiaodai/32/15937_2.png) [@xiaodai](https://discourse.julialang.org/u/xiaodai)\
**Post date:** [October 20, 2017, 2:32am UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/155 "2017-10-20T02:32:37Z")

</div>

ah… of course!!!

---

<div class="post-metadata">

**Author:** ![Per](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/per/32/10387_2.png) [@Per](https://discourse.julialang.org/u/Per)\
**Post date:** [October 20, 2017, 6:17am UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/156 "2017-10-20T06:17:12Z")

</div>

> [@tuckermcclure](#):
>
> line continuation syntax

Even better if it’s also allowed to put the continuation symbol at the beginning of the second line instead of at the end of the first. This saves a character on the line that is too long anyway. Or multiple characters if using a longer continuation symbol. A three-character symbol and a space could replace four spaces of indentation. (Advanced editors could render the continuation symbol nearly the same color as the background, so that it resembles indentation.)

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [October 20, 2017, 7:29am UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/157 "2017-10-20T07:29:03Z")

</div>

> [@tuckermcclure](#):
>
> (Yes, I can just move the = up for this particular example, but I’m going for the general case here.)

For the general case: if you end the line with an unfinished expression, Julia will read the next one to complete the expression. Eg

```julia
1 +
    2

function lotsofargs(arg1,
                     arg2)
end

```

---

<div class="post-metadata">

**Author:** ![yakir12](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yakir12/32/297_2.png) [@yakir12](https://discourse.julialang.org/u/yakir12)\
**Post date:** [October 20, 2017, 7:47am UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/158 "2017-10-20T07:47:19Z")

</div>

If only that metadata carried through to the publication. It won’t. So the only point where it would be useful is when you use the original files. You, or someone you sent it to, or if you host it on a server you have explicit control over.  
But I looooove this idea…

---

<div class="post-metadata">

**Author:** ![Daneel](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/daneel/32/175_2.png) [@Daneel](https://discourse.julialang.org/u/Daneel)\
**Post date:** [October 20, 2017, 8:15am UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/159 "2017-10-20T08:15:37Z")

</div>

Of course, but often I find an old plot and have no idea of the context or I want one specific plot from a folder of countless plots that all look relatively similar. Images can be extracted from PDFs so the metadata _might_ still survive even in digital publication.

I have already done a little bit of work testing how to read it which turned out to be quite simple. It relies on `exiftool` which I see you have [experience with](https://discourse.julialang.org/t/bindeps-for-an-executable/3161).

This is off the main topic though so let’s move further conversation to a new thread. I’ll post something at some point today once I’ve built a full example. I’m still a bit uncertain of how much is possible or the best approach.

> [@Programmatic Image Tagging](https://discourse.julialang.org/t/programmatic-image-tagging/6581):
>
> Here is my quick test of programmatic image tagging. My approach uses [exiftool](https://sno.phy.queensu.ca/~phil/exiftool). The end goal is to be able to save useful metadata pertaining to plots into the saved images themselves. Definite Includes Specific keywords, plot specific versioninfo() Pkg.status() Executing code header comments Executing code path Other Possible Includes Executing script in its entirety, anything more is impractical Author DOI/publication reference, when image will be published Executing script hash/commit n…

Edit: Added link to the new thread

---

<div class="post-metadata">

**Author:** ![foobar\_lv](https://avatars.discourse-cdn.com/v4/letter/f/35a633/32.png) [@foobar\_lv](https://discourse.julialang.org/u/foobar_lv)\
**Post date:** [October 20, 2017, 9:15am UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/160 "2017-10-20T09:15:36Z")

</div>

Some way to get guaranteed allocation-free immutable types containing references (especially arrays of such eltype must not be pointer-arrays). I don’t need a pretty syntax for such type-definitions, but I need a way of specifying, unambiguously, the resulting data layout.

In other words I want a guaranteed (not sometimes maybe optimized) zero-cost abstraction to bundle reference-types together. Currently, the only available zero-cost abstractions for bundling values together into a type are for bitstype.

This would solve, e.g., allocating array views, or the token/semitoken API for trees in datastructures.jl.

Such zero-cost types need to be available and the resulting data layout needs to be well-defined, but it does not need to be syntactically pretty (e.g. new keyword: bitstype\_like / leaftype, requiring users to specify explicitly, for every member field, whether it is supposed to be inplace or as reference, and the partial order of “bitstype\_like contains inplace member” must be non-circular, else compile-time error).

Cf [https://github.com/JuliaLang/julia/pull/18632](https://github.com/JuliaLang/julia/pull/18632) .

---

<div class="post-metadata">

**Author:** ![Christian\_Rorvik](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/christian_rorvik/32/965_2.png) [@Christian\_Rorvik](https://discourse.julialang.org/u/Christian_Rorvik)\
**Post date:** [October 20, 2017, 1:46pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/161 "2017-10-20T13:46:41Z")

</div>

Maybe this is a no-go, or discussed elsewhere, but if my understanding is correct all memory allocated in Julia is implicitly pinned, to make interfacing with external code easier and less error prone I think. For any future performance work on allocation and GC this imposes some pretty significant constraints on the implementation. Is there any willingness to reconsider this? It feels like the sort of semantics you don’t want to break after a 1.0 release.

---

<div class="post-metadata">

**Author:** ![jlapeyre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlapeyre/32/4514_2.png) [@jlapeyre](https://discourse.julialang.org/u/jlapeyre)\
**Post date:** [October 20, 2017, 3:02pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/162 "2017-10-20T15:02:52Z")

</div>

I’m not sure I understand what you mean by ‘observable’. In general, settling design and syntax issues for 1.0 that will be hard to change later seems most important. Multi-threading may not have much to do with this. But, convenient, stable multi-threading is an essential for many projects. I’d have a hard time selling Julia as “reasonably mature” if it can’t do multi-threading. (Of course, I’m not offering to try to fix it right now. And it won’t kill Julia if it is not there.)

Multi-threading by default, please no. At least, not MATLAB style. I repeatedly see things like users unwittingly starting thread-pools in a loop to invert 10x10 matrices. They move the code to a server and half the CPU time is in system calls. It’s hard to explain; someone has to be an enforcer, because people ignore you if they can, etc. Happens with numpy, too.

---

<div class="post-metadata">

**Author:** ![tuckermcclure](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tuckermcclure/32/1187_2.png) [@tuckermcclure](https://discourse.julialang.org/u/tuckermcclure)\
**Post date:** [October 20, 2017, 3:18pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/163 "2017-10-20T15:18:05Z")

</div>

Thanks @Tamas_Papp. I know, but I still mess this up all the time. I use whitespace liberally to convey meaning, and I don’t always want to reformat my lines. For instance, we write math like:

```julia
  a
+ b
----
= c

```

so I like to write out operations like:

```julia
result = ↵
  this ↵
+ that

```

or nested with operations lined up, like:

```julia
result = ↵
    thing ↵
  * this ↵
+ that

```

Plus, I think the ↵ symbol seems like an unclaimed and elegant solution. Ok, this isn’t the highest thing on my wishlist, but it seemed easy and helpful in addressing one of the common mistakes.

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

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