# 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:** 3
### Author:  [@abulak](https://discourse.julialang.org/u/abulak)
#### Post date: [June 27, 2017, 3:57pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/43 "2017-06-27T15:57:32Z")
I’m surprised that no one has mentioned the first thing I wanted to do: typing functions after argument and return value type…
---
### Author:  [@innerlee](https://discourse.julialang.org/u/innerlee)
#### Post date: [June 27, 2017, 3:58pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/44 "2017-06-27T15:58:12Z")
My only wish:
- Calling a Julia function from a non-Julia thread ([https://github.com/JuliaLang/julia/issues/17573](https://github.com/JuliaLang/julia/issues/17573)).
Well, the second:
- Faster loading of Plots.jl
---
### Author:  [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)
#### Post date: [June 27, 2017, 4:00pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/45 "2017-06-27T16:00:35Z")
> [@abulak](#):
>
> I’m surprised that no one has mentioned the first thing I wanted to do: typing functions after argument and return value type…
What does that even mean? Functions don’t have arguments or return value types. Methods do. But the methods list is mutable, so making it part of the function’s type seems like it would cause a lot of problems.
---
### Author:  [@abulak](https://discourse.julialang.org/u/abulak)
#### Post date: [June 27, 2017, 4:07pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/46 "2017-06-27T16:07:18Z")
Every function has its own type;
If You want a type `MyType` which has fieldname `myfunc::Function` You have to parametrise the type after type of `myfunc` (i.e. `MyType{T<:Function}` and `myfunc::T`);
It would be much more natural to do that after the type of return value
Or doesn’t that make sense and I’m awfully missing something?
---
### Author:  [@samtkaplan](https://discourse.julialang.org/u/samtkaplan)
#### Post date: [June 27, 2017, 4:26pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/47 "2017-06-27T16:26:04Z")
I am looking forward to the threading re-write mentioned in the following pull request:
[https://github.com/JuliaLang/julia/pull/18278#issuecomment-279021388](https://github.com/JuliaLang/julia/pull/18278#issuecomment-279021388)
---
### Author:  [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)
#### Post date: [June 27, 2017, 4:30pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/48 "2017-06-27T16:30:15Z")
> [@abulak](#):
>
> If You want a type MyType which has fieldname myfunc::Function You have to parametrise the type after type of myfunc (i.e. MyType{T\<:Function} and myfunc::T);
>
> It would be much more natural to do that after the type of return value
But functions don’t necessarily have return value types. Methods don’t necessarily have return value types: they can depend on the input types.
In a restricted case, this will work. In that restricted case, you can use FunctionWrappers.jl, which would be nice to have in Base in the future.
---
### Author:  [@ihnorton](https://discourse.julialang.org/u/ihnorton)
#### Post date: [June 27, 2017, 4:32pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/49 "2017-06-27T16:32:14Z")
> [@ChrisRackauckas](#):
>
> But functions don’t necessarily have return value types. Methods don’t necessarily have return value types: they can depend on the input types.
Exactly. See also this comment and the subsequent discussion:
>
>
> 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).
---
### Author:  [@cdsousa](https://discourse.julialang.org/u/cdsousa)
#### Post date: [June 27, 2017, 5:05pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/50 "2017-06-27T17:05:18Z")
> [@innerlee](#):
>
> My only wish:
>
> Calling a Julia function from a non-Julia thread ([Calling a Julia function from a non-Julia thread · Issue #17573 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/17573)).
@innerlee, I was looking for that issue but was unable to find it.
I absolutely wish that.
---
### Author:  [@Paul\_Soderlind](https://discourse.julialang.org/u/Paul_Soderlind)
#### Post date: [June 27, 2017, 7:38pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/51 "2017-06-27T19:38:30Z")
my wish: a debugger
---
### Author:  [@Nectarineimp](https://discourse.julialang.org/u/Nectarineimp)
#### Post date: [June 27, 2017, 7:58pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/52 "2017-06-27T19:58:06Z")
That is exactly what I do. I use the time for establishing zen like focus.
> “Be with just this.”
Why is the code broken? Will my fix be the final fix? How can I overcome the poorly written and obscure error message I have been handed? It seems to me that finding a practical answer to these questions is very important if Zen training is to meet people in their stuck and disconnected inner places and bring them to greater wholeness. That is the entire point of Julia. Restarting Julia is like clearing your mind, and it is actually clearing the computer’s memory of all of that broken code, and allowing you to replace it with pure, righteous code.
😑
May your bugs be ichi-go, ichi-e
---
### Author:  [@essenciary](https://discourse.julialang.org/u/essenciary)
#### Post date: [June 27, 2017, 8:04pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/53 "2017-06-27T20:04:02Z")
+1 for debugger.
And in general, I’d like to see a list of core packages that are upgraded _with_ Julia as part of a `x.y` release.
I can’t upgrade my codebase to v0.6 because it depends on so many packages that are not yet v0.6 compatible. Some are minor, I get that (weird that the `PostgreSQL` package is in that bucket and it’s completely dead in v0.6, but it is what it is…), but some, like `Gallium` or `AbstractTrees` should have already working versions when a Julia version is released.
I think a dependency graph might help to understand what packages have the most impact on other packages and give these a privileged status (and support and/or funding under the Julia core umbrella) - we don’t want to have a Julia variation of the Nodejs ecosystem meltdown from last year ([How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript • The Register](https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/))
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [June 27, 2017, 8:30pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/54 "2017-06-27T20:30:39Z")
If I could call Julia functions reliably from Matlab, than it could really replace Fortran as language for implementing aerodynamic models. 🙂
---
### Author:  [@TsurHerman](https://discourse.julialang.org/u/TsurHerman)
#### Post date: [June 27, 2017, 8:56pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/55 "2017-06-27T20:56:57Z")
My most desired feature would be:
The ability to save the state of a Repl’d Julia session , and to resume it in a later date.
This feature in my opinion , coupled with the “Reloadable Modules” feature, and the cycler mode in Juno
will save copious amounts of “the first call is slow” time.
So much time is wasted on parsing and compilation to LLVM , well “precompilation” should take care of that.
But so much more time is wasted on compilation to binary …
The real killer feature for the language would be the ability to save and load functions in binary form, while still tracking
the source code for changes.
And compiling function only when necessary.
This would turn Julia from “slow the first time but then its awesome” to just “awesome”
---
### Author:  [@musm](https://discourse.julialang.org/u/musm)
#### Post date: [June 27, 2017, 9:29pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/56 "2017-06-27T21:29:08Z")
IMO this would be huge for several reasons.
Imagine writing a great static blog engine like the `hugo` engine. What’s so great about it is that it’s one compact exe download and bam you’re up and running. The situation would be more challenging with Julia since it would require new users to first install Julia and then set everything up and then add the package. The time to first launch of the program is very large: for the exe it is “download and click” vs “download julia and add the package and then precompile the package and run it”
This crops up in my use case. 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. With matlab this isn’t a problem since matlab has stable and mature package, so regardless of the version they have installed the script will run (note I am not including the installation time of matlab since my group all have it installed). And as you mention we can also just package the matlab app using the matlab c codegen compiler.
These are my opinions on why having executable would be highly desirable.
---
### Author:  [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)
#### Post date: [June 27, 2017, 10:28pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/57 "2017-06-27T22:28:21Z")
> [@essenciary](#):
>
> I think a dependency graph might help to understand what packages have the most impact on other packages and give these a privileged status (and support and/or funding under the Julia core umbrella) - we don’t want to have a Julia variation of the Nodejs ecosystem meltdown from last year ([How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript • The Register](https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/))
Well to be fair: the fact that packages cannot be outright deleted is what prevents the Nodejs meltdown situations. But that same setup is what also makes deprecated packages “stay alive” on METADATA. There really isn’t a good solution to this other than “the main packages are mature enough”, which just takes time.
> [@ufechner7](#):
>
> If I could call Julia functions reliably from Matlab, than it could really replace Fortran as language for implementing aerodynamic models. 🙂
MATLAB seems almost purposely difficult to work like this. I have spent enough time with MATLAB.jl and mexjulia.jl to have the opinion that, while these are great and very useful projects, they likely won’t be something I’d ever rely on given the pain that MATLAB puts the authors through to make it work. Calling MATLAB from Julia is much easier than the reverse.
> [@TsurHerman](#):
>
> The ability to save the state of a Repl’d Julia session , and to resume it in a later date.
>
> This feature in my opinion , coupled with the “Reloadable Modules” feature, and the cycler mode in Juno
> will save copious amounts of “the first call is slow” time.
That’s a fantastic idea. Is there an issue for it?
---
### Author:  [@essenciary](https://discourse.julialang.org/u/essenciary)
#### Post date: [June 27, 2017, 10:37pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/58 "2017-06-27T22:37:05Z")
> [@ChrisRackauckas](#):
>
> Well to be fair: the fact that packages cannot be outright deleted is what prevents the Nodejs meltdown situations. But that same setup is what also makes deprecated packages “stay alive” on METADATA. There really isn’t a good solution to this other than “the main packages are mature enough”, which just takes time.
Sure. My point was that certain packages are too important to be left to the effort of a single contributor. For Node, it was a delete. For us, it’s the fact that they don’t get updated in time. A debugger is such an example - it’s just too important to be left outside the core.
I’ve seen that some packages (or features) were added to the default Julia distribution in time (stacktrace, ohmyrepl, etc). I’d like to see the list extended to more of them.
---
### Author:  [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)
#### Post date: [June 27, 2017, 10:56pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/59 "2017-06-27T22:56:52Z")
I do think it needs to be mentioned that most of the desired features are actually package ecosystem issues. Slow first-time-to-plot, debugger, and everyone’s favorite package missing a few things. I think it’s important to note that these issues are not about Julia’s Base. Even building an executable isn’t: the core features have already been added and documented (though via blog post) for both static compilation and regular “dynamic language compilation” (with the runtime baked in a la BuildExecutable.jl). If someone came along and stuck a GUI on the already existing workflow, I think people would consider it fixed. To me, this thread makes it look like the average user doesn’t have issues with Julia’s core at all, but instead we the package developers need to catch up 🙂.
I think it should be noted that the Julia coredevs (or at least Stefan) mentioned this situation in the JuliaCon Julia roadmap talk, so this situation is well known. The criteria for 1.x features is “non-breaking”, and it seems that almost every suggestion in this thread is either a package update or a possibility for 1.x. So other than the name “1.0” having an unruly amount of significance, none of this seems 1.0 in that sense. I am actually very excited now 😊
I should probably put a mention in that the best way to push the packages along is to help out. Even if you are too scared to do much, you can at least help review and revise the documentation/tutorials, which is something that takes a lot of developer time away from developing the package itself. The plotting packages can definitely use some help in these areas.
Side note: grievances threads are always a lot of fun. 🍿
---
### Author:  [@essenciary](https://discourse.julialang.org/u/essenciary)
#### Post date: [June 27, 2017, 11:10pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/60 "2017-06-27T23:10:29Z")
> [@ChrisRackauckas](#):
>
> I should probably put a mention in that the best way to push the packages along is to help out
I feel that at some level there is a small problem here. Yesterday I made a PR bringing AbstractTrees to 0.6. Only to then see that the changes were already applied to master, but were not tagged and released. And this is a recurring scenario, for me at least.
Somebody else made a PR to update Genie to 0.6. But I already had that in a 0.6 branch waiting for other packages.
This workflow is not entirely efficient and it leads to wasted efforts.
---
### Author:  [@dpsanders](https://discourse.julialang.org/u/dpsanders)
#### Post date: [June 27, 2017, 11:19pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/61 "2017-06-27T23:19:56Z")
This is very unfortunate, yes.
But note that any new changes should (usually) start from the master branch.
---
### Author:  [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)
#### Post date: [June 27, 2017, 11:26pm UTC](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481/62 "2017-06-27T23:26:27Z")
> [@essenciary](#):
>
> This workflow is not entirely efficient and it leads to wasted efforts.
I think that’s a very valid complaint. People should tag (a lot) more often. In fact, I wish I was allowed to help with package maintenance more so I could just go tag releases for people (though Attobot makes this easy enough).
My take on it these days is that, if you fix a user’s bug (and close the issue), you should probably do a release. The only exception is if you plan on tackling a few more user bugs in the next few days. Of course, everyone is free to have their own opinion and this is on the “radically agile” side, but I think that with the ease of Attobot and the youth of the package ecosystem this steady flow of releases is quite necessary. Besides, other packages have to use release, and the big differences between release and master ends up causing friction when large releases suddenly occur. Of course that’s unavoidable in many cases, but I think it could be helped with more incremental changes and releasing patches separately from features.
[Previous page](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481.md?page=2)
[Next page](https://discourse.julialang.org/t/list-of-most-desired-features-for-julia-v1-x/4481.md?page=4)