I’m surprised that no one has mentioned the first thing I wanted to do: typing functions after argument and return value type…
My only wish:
- Calling a Julia function from a non-Julia thread (https://github.com/JuliaLang/julia/issues/17573).
Well, the second:
- Faster loading of Plots.jl
2 Likes
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.
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?
I am looking forward to the threading re-write mentioned in the following pull request:
https://github.com/JuliaLang/julia/pull/18278#issuecomment-279021388
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.
Exactly. See also this comment and the subsequent discussion:
@innerlee, I was looking for that issue but was unable to find it.
I absolutely wish that.
my wish: a debugger
7 Likes
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
2 Likes
+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)
4 Likes
If I could call Julia functions reliably from Matlab, than it could really replace Fortran as language for implementing aerodynamic models. 
2 Likes
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”
2 Likes
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.
2 Likes
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.
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.
That’s a fantastic idea. Is there an issue for it?
2 Likes
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.
2 Likes
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. 
10 Likes
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.
1 Like
This is very unfortunate, yes.
But note that any new changes should (usually) start from the master branch.
3 Likes
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.
3 Likes