List of most desired features for Julia v1.x

I would like to share a discussion panel that has some very good points about evolving a programming language:

Many hopes stated in the video seem to be a reality nowadays in Julia like code rejuvenation, strong type system with minimum annotation, etc.

I understand that the main contributors of the language must be super busy with the first major release. I am sharing the video as a form of support in these stressful times.

6 Likes

I’m not sure how Turing completeness is relevant. If a transformation is “observable” in the sense I defined, then it is by definition not an optimization. Perhaps the confusion stems from the fact that threading can occur in different ways:

  1. Automatically as an optimization. If the compiler is sure that there’s no way to tell the difference between the implementation using one thread or many, it can choose to use a threaded implementation.

  2. Implicitly, as part of the language definition. If the language is defined to be allowed to execute certain constructs concurrently, then whether the result is observable or not is irrelevant since the language is defined to behave concurrently.

  3. Explicitly, because the user asked for it. If the user asks for threads, then they can’t complain if the resulting behavior is observably different from the non-threaded behavior.

I’m talking about 1 while you seem to be talking about 2. If we know that the operation each iteration does is pure and can be executed in any order or concurrently, then we could use threads because we know the program won’t behave differently. Whether it’s faster or not depends on the circumstances.

If it’s strictly an optimization (as I stipulated), then it is by definition not observable whether threads are used or not, which means it cannot “interact badly” with Julia libraries that use multithreading – at least not in the sense of changing their behavior. If you mean “interact badly” in the sense of different levels of threading composing poorly and causing bad performance, then that’s a different matter. That would only happen if we chose a non-composable threading model, which we’re not doing – we’re going with Cilk-style work stealing, which does compose well. So, if the compiler can determine that a comprehension or broadcast operation is pure, it is free to make it concurrent and let the task/thread scheduler decide whether to run on different threads or not. Of course, all of this is predicated on having a work-stealing scheduler that’s good enough, which remains to be proven. All I’m saying is that it’s not impossible to add threading as a pure optimization.

1 Like

I would like a version, let’s say 0.7 where we drop support from all previous versions and make sure the ecosystem is stable. For example, no more depreciation warnings or whatnot. A stable environment would require getting JuliaData, JuliaMath, JuliaStats, etc. playing well with one another for example. After that is done, 1.x can be used to polish the documentation, debuggers, etc. Personally, I would also like a way for functions to take a struct with named arguments and that way it can do the method dispatch without users having to remember the order of each argument, keyword status, etc. a general macro maybe?

You mean this?

Currently there is no method dispatch with keyword arguments.

NamedTuples just merged two days ago. They are essentially the key to implementing this though, so I wouldn’t be surprised to see this solved soon after 1.0. There’s already a prototype of what that looks like:

https://github.com/bramtayl/Keys.jl

That’s not the same as a Base implementation, but its a good proof of concept that this really is the only data structure that’s necessary to get this accomplished.

6 Likes

I secretly get super excited when someone mentions one of my packages

17 Likes

This would be a number one request for me also - I am mainly interested in discovering as many errors as possible at compile time, at least the trivial ones like misspelling a function name or passing incorrect types. I understand it is not possible to find all errors and some suspicious code might be actually correct but that is fine. For example, the “unsafe” or “advanced” code could be isolated and marked as such. The rest could be verified statically. Currently, there are too many errors which only appear when the code is run, which makes the development cycle slow. Unit tests help but not everything can be tested on small examples. I know Matlab and Python are the same in this aspect but Julia should be better, right? I am not hoping for “if it compiles, it is correct” but we should be moving towards “if it compiles, it will run”.

Yes. Debug used to work nicely but sadly no longer does.

Actually, I wish that as Julia matures, backward compatibility is given more and more importance and breaking changes become increasingly rare. As an illustration, I have recently revived my project in Julia after about a year. I upgraded from Julia 0.5 to Julia 0.6. There are so many breaking changes in Julia (e.g. Array constructor syntax) and packages (like Images) that I have spent several days fixing my code and I am no way sure to have fixed everything.

Julia is great, please carry on. Yours,

Jan

1 Like

Note that compilation per se won’t catch any runtime errors for you, the way it does in statically typed languages. Consider

f(x) = g(x) + 1

with g undefined. Now suppose you “compile” this for the signature Tuple{Float64}. It this an error? Not necessarily, because g(::Float64) could be defined before you run it, and then everything is fine.

Are we talking about

? It has some minor issues, but is usable at the moment.

1 Like

All code running on Julia 1.0 will run on all Julia 1.x versions, but until then backwards compatibility will be broken one more time for 0.7.

2 Likes

The whole point of 1.0 is to say “this is where we stop doing so many breaking changes, and any 1.x is backwards compatible with 1.0”.

I love the idea of getting most breaking changes done before 1.0. But I don’t think insisting on backwards compatibility always in the long run is very good for a language. Julia is young and should still be able to develop creatively, and tools like compat and femtocleaner really do a lot for ameliorating version issues.

4 Likes

There’s so much work to be done that isn’t breaking though that it will be nice to have those prioritized for a bit.

3 Likes

I’d imagine the Python 3 developers said something along these lines at some point.

I’d really like to agree with you, but I think we need to be much more careful after 1.0. Granted, macros do give us a big advantage over python when it comes to compatibility.

2 Likes

for sure!

I don’t see why julia or other software projects would by necessity suffer the same fate. You don’t hear about developers who’ve refused to give up on Python 1. The problem IMHO was that there was a too big existing codebase in Python 2 that noone was touching actively, and that the advantages of Python 3 weren’t that great.

1 Like

39 posts were split to a new topic: Package naming guidelines

  1. Cilk like multithreading.
  2. calling julia from another thread.
1 Like

A post was merged into an existing topic: Package naming guidelines

This topic has gone off-topic many times, and I would urge everyone to continue the conversations in their own topics. Keep in mind that each reply on such a big topic, potentially notifies everyone else.

16 Likes