5 ms·

I am interested to hear if folks think a 2.0 release would make Julia more appealing.

caleb-allen 4y ago
There are of course many breaking changes that could improve the language itself, but in my opinion the attention of maintainers is best spent on improving the ecosystem--while a 2.0 release may be exciting, I've been very pleased to see the language steadily improve with 1.x releases.
bobbylarrybobby 4y ago
Yes, I'd love to see a revamp of the type system with real interfaces instead of the single inheritance with abstract types. I also think packaging and imports need a lot of work — for god's sake, there is no "import adjacent file" mechanism other than a C-style `include`, which just copies and pastes code from another file into the current file.
- contravariant 4y ago
  Not sure if interfaces work as you'd expect them to in Julia. Values don't have methods for instance, you just define functions for the types. So what would an interface look like? Best I can figure out an interface is equivalent to a requirement that a couple of methods are implemented and that a bunch of fields exist, which sort of gets taken care of by the duck-typing, the only problem is that it's not documented in code. One approach that I'd been thinking about would be defining a method IMyInterface that returns a tuple of fields and methods defined by the interface and saying a type implements that interface if there's an implementation. Technically this performs the same job, but unfortunately it doesn't seem like it'd be easy to use without hefty syntactic sugar. What do you imagine interfaces would look like in Julia?
  - bobbylarrybobby 4y ago
    Most I want to be able to write something like `f(it::Iterable{<:Number})`. The current way to do this is to simply not specify the type and then it let it fail wherever the duck typing fails (e.g., if you try to use a for loop on a non iterable argument). I'd rather it fail when calling f saying no method exists for <passed type>.
    - ChrisRackauckas 4y ago
      I tend to think that this is the one thing that would bring a v2.0. Compile time, startup time, binary building, and native code caching improvements I think take the big priority here (and I describe elsewhere in this thread how those are really all one technical issue), but when that's completed I do think formalizing a traits interface will be the next major semantic change to the language. It could be a v1.x if it does not require a breaking change to the language's semantics, but it's hard (for me at least) to see how to nicely incorporate trait definitions and required dispatches without making a single breaking change.
    - contravariant 4y ago
      I agree that that would be better, I'm just wondering what the definition of an interface would look like. Technically "all" you need is to extend the 'where' keyword a "little": Iterable{T,S} = TIter where { iterate(iter::TIter) <: Tuple{T,S}, iterate(iter::TIter, state::S) <: Tuple{T,S}}
      - bobbylarrybobby 4y ago
        I'm imagining it would look more or less like a struct definition, but with methods instead of fields. Something like interface{S,T} Iterable{T} Next = Tuple{Union{T,Nothing},S} iterate(self::Self)::Next iterate(self::Self, state::S)::Next end This means "Iterable has two type parameters, one of which (T) is named explicitly in the type and the other of which (S) is implicitly used in the definition of the interface but is otherwise not nameable.". I think the real question is how to implement structural sub typing of interfaces -- you wouldn't want to have to list the interfaces a struct implements when defining it because then you're limited to only those traits you (the struct's author) know about. Better (and more Julian) to automatically implement Iterable for any struct with those two iterate methods defined on it, but it seems like a pretty big task to keep track of that at runtime. Especially if you care about matching the return types of the interface's functions since in general those can't be type checked until they're actually called (or at the least compiled, but the whole point of Julia is to not compile the world ahead of time).
jarbus 4y ago
It's been very exciting to follow progress on Julia, it's quite a wonderful language. Thank you for all the fantastic work. While I understand 2.0 making sense in terms of breaking changes, I think a 2.0 release would need a major improvement in one area to be worthy of the title, and get more users interested. For example, if there was an update that made compilation significantly faster, or an update that empowered users to never have to restart the REPL with Revise, I think that would be a "defining" thing that would interest a lot of people, more so than breaking changes.
wnoise 4y ago
Well, yes, because there are several breaking changes that should happen, but can't before then, because of the adherence to semver.
blindseer 4y ago
I'd like to see a way to specify interfaces / traits, in the base package itself. I would also like to see a better test suite, with the ability to run a single test if I want to. Test Driven Development on a large project is a nightmare (although it's gotten a little better recently). I still can't believe how people contribute to Base Julia, because running the tests takes forever. Lastly, better support for debugging in Neovim, Vim, Emacs etc. Better linting tools too. There's a push in other languages to write core language tooling in Rust or Zig, I think Julia would benefit from that approach (there's `juliaup` but I'd like to see more official tools similar to this). Personally I'd like to see SetField.jl or Accessors.jl in Base. I'd also like to see improvements in the ergonomics of using immutable structs. In Julia, users should want to use immutable structs all the time, and ONLY if they need reference semantics they should want to reach for mutable structs. I think the naming and the sematics here is REALLLYY confusing when trying to get a team to write performant code. I can't tell you how many times I've had this kind of conversation with various members in my team. Me: Create a struct for holding all that related data together F: Okay, let me create a struct. - Refactors code base for a day - Realizes the data is being updated - Uses mutable structs Me: Don't use mutable structs unless you want reference semantics F: What even is reference semantics? - Tries to refactor by removing the `mutable` keyword, code breaks when doing `a.b += 1`, writes messy code like `a = A(B(a.b + 1, a.b.c, a.b.d, ...), a.c, a.d, ...)`. Me: Ugh, why didn't you use `SetField` instead? F: No unnecessary extra dependencies to reduce complexity. Project Manager: Where are we with this task? Just use mutable struct and move on. Me: Sigh. Fine. On a non-language side of things, 1) it would be nice to have a bigger focus on teaching how to write performant Julia code. Currently, most if not all the material is geared toward someone who already knows how to write performance code (in C++ for example) and showing them the "Julian" way to do it. 2) I'd like to see a usability survey done from Julia users to see what features should be tackled next.
- ChrisRackauckas 4y ago
  > Personally I'd like to see SetField.jl or Accessors.jl in Base. I'd also like to see improvements in the ergonomics of using immutable structs. In Julia, users should want to use immutable structs all the time, and ONLY if they need reference semantics they should want to reach for mutable structs. I think the naming and the sematics here is REALLLYY confusing when trying to get a team to write performant code. I can't tell you how many times I've had this kind of conversation with various members in my team. I agree that one of these should be standardized to be a Base functionality. But that won't need a v2.0 for that to happen: it can happen in a v1.x. > it would be nice to have a bigger focus on teaching how to write performant Julia code. Currently, most if not all the material is geared toward someone who already knows how to write performance code (in C++ for example) and showing them the "Julian" way to do it. The issue is that many of these tricks are actively being addressed, for example with escape analysis to reduce allocations. So what really needs to be taught is how to profile and understand what the code is doing, and how to effect it to do what one wants for performance. That then increases the barrier to entry. I think we shouldn't be teaching people "how to write performant Julia code" much more than is already out there though: since most of the tricks are really just workarounds for missing optimizations, those compiler optimizations should just get added (and there's some work showing it is possible).

There are of course many breaking changes that could improve the language itself, but in my opinion the attention of maintainers is best spent on improving the ecosystem--while a 2.0 release may be exciting, I've been very pleased to see the language steadily improve with 1.x releases.

bobbylarrybobby 4y ago

Yes, I'd love to see a revamp of the type system with real interfaces instead of the single inheritance with abstract types. I also think packaging and imports need a lot of work — for god's sake, there is no "import adjacent file" mechanism other than a C-style `include`, which just copies and pastes code from another file into the current file.

contravariant 4y ago
Not sure if interfaces work as you'd expect them to in Julia. Values don't have methods for instance, you just define functions for the types. So what would an interface look like? Best I can figure out an interface is equivalent to a requirement that a couple of methods are implemented and that a bunch of fields exist, which sort of gets taken care of by the duck-typing, the only problem is that it's not documented in code. One approach that I'd been thinking about would be defining a method IMyInterface that returns a tuple of fields and methods defined by the interface and saying a type implements that interface if there's an implementation. Technically this performs the same job, but unfortunately it doesn't seem like it'd be easy to use without hefty syntactic sugar. What do you imagine interfaces would look like in Julia?
- bobbylarrybobby 4y ago
  Most I want to be able to write something like `f(it::Iterable{<:Number})`. The current way to do this is to simply not specify the type and then it let it fail wherever the duck typing fails (e.g., if you try to use a for loop on a non iterable argument). I'd rather it fail when calling f saying no method exists for <passed type>.
  - ChrisRackauckas 4y ago
    I tend to think that this is the one thing that would bring a v2.0. Compile time, startup time, binary building, and native code caching improvements I think take the big priority here (and I describe elsewhere in this thread how those are really all one technical issue), but when that's completed I do think formalizing a traits interface will be the next major semantic change to the language. It could be a v1.x if it does not require a breaking change to the language's semantics, but it's hard (for me at least) to see how to nicely incorporate trait definitions and required dispatches without making a single breaking change.
  - contravariant 4y ago
    I agree that that would be better, I'm just wondering what the definition of an interface would look like. Technically "all" you need is to extend the 'where' keyword a "little": Iterable{T,S} = TIter where { iterate(iter::TIter) <: Tuple{T,S}, iterate(iter::TIter, state::S) <: Tuple{T,S}}
    - bobbylarrybobby 4y ago
      I'm imagining it would look more or less like a struct definition, but with methods instead of fields. Something like interface{S,T} Iterable{T} Next = Tuple{Union{T,Nothing},S} iterate(self::Self)::Next iterate(self::Self, state::S)::Next end This means "Iterable has two type parameters, one of which (T) is named explicitly in the type and the other of which (S) is implicitly used in the definition of the interface but is otherwise not nameable.". I think the real question is how to implement structural sub typing of interfaces -- you wouldn't want to have to list the interfaces a struct implements when defining it because then you're limited to only those traits you (the struct's author) know about. Better (and more Julian) to automatically implement Iterable for any struct with those two iterate methods defined on it, but it seems like a pretty big task to keep track of that at runtime. Especially if you care about matching the return types of the interface's functions since in general those can't be type checked until they're actually called (or at the least compiled, but the whole point of Julia is to not compile the world ahead of time).

jarbus 4y ago

It's been very exciting to follow progress on Julia, it's quite a wonderful language. Thank you for all the fantastic work. While I understand 2.0 making sense in terms of breaking changes, I think a 2.0 release would need a major improvement in one area to be worthy of the title, and get more users interested. For example, if there was an update that made compilation significantly faster, or an update that empowered users to never have to restart the REPL with Revise, I think that would be a "defining" thing that would interest a lot of people, more so than breaking changes.

wnoise 4y ago

Well, yes, because there are several breaking changes that should happen, but can't before then, because of the adherence to semver.

blindseer 4y ago

I'd like to see a way to specify interfaces / traits, in the base package itself. I would also like to see a better test suite, with the ability to run a single test if I want to. Test Driven Development on a large project is a nightmare (although it's gotten a little better recently). I still can't believe how people contribute to Base Julia, because running the tests takes forever. Lastly, better support for debugging in Neovim, Vim, Emacs etc. Better linting tools too. There's a push in other languages to write core language tooling in Rust or Zig, I think Julia would benefit from that approach (there's `juliaup` but I'd like to see more official tools similar to this). Personally I'd like to see SetField.jl or Accessors.jl in Base. I'd also like to see improvements in the ergonomics of using immutable structs. In Julia, users should want to use immutable structs all the time, and ONLY if they need reference semantics they should want to reach for mutable structs. I think the naming and the sematics here is REALLLYY confusing when trying to get a team to write performant code. I can't tell you how many times I've had this kind of conversation with various members in my team. Me: Create a struct for holding all that related data together F: Okay, let me create a struct. - Refactors code base for a day - Realizes the data is being updated - Uses mutable structs Me: Don't use mutable structs unless you want reference semantics F: What even is reference semantics? - Tries to refactor by removing the `mutable` keyword, code breaks when doing `a.b += 1`, writes messy code like `a = A(B(a.b + 1, a.b.c, a.b.d, ...), a.c, a.d, ...)`. Me: Ugh, why didn't you use `SetField` instead? F: No unnecessary extra dependencies to reduce complexity. Project Manager: Where are we with this task? Just use mutable struct and move on. Me: Sigh. Fine. On a non-language side of things, 1) it would be nice to have a bigger focus on teaching how to write performant Julia code. Currently, most if not all the material is geared toward someone who already knows how to write performance code (in C++ for example) and showing them the "Julian" way to do it. 2) I'd like to see a usability survey done from Julia users to see what features should be tackled next.

ChrisRackauckas 4y ago
> Personally I'd like to see SetField.jl or Accessors.jl in Base. I'd also like to see improvements in the ergonomics of using immutable structs. In Julia, users should want to use immutable structs all the time, and ONLY if they need reference semantics they should want to reach for mutable structs. I think the naming and the sematics here is REALLLYY confusing when trying to get a team to write performant code. I can't tell you how many times I've had this kind of conversation with various members in my team. I agree that one of these should be standardized to be a Base functionality. But that won't need a v2.0 for that to happen: it can happen in a v1.x. > it would be nice to have a bigger focus on teaching how to write performant Julia code. Currently, most if not all the material is geared toward someone who already knows how to write performance code (in C++ for example) and showing them the "Julian" way to do it. The issue is that many of these tricks are actively being addressed, for example with escape analysis to reduce allocations. So what really needs to be taught is how to profile and understand what the code is doing, and how to effect it to do what one wants for performance. That then increases the barrier to entry. I think we shouldn't be teaching people "how to write performant Julia code" much more than is already out there though: since most of the tricks are really just workarounds for missing optimizations, those compiler optimizations should just get added (and there's some work showing it is possible).