A large part of this seems to be the old-but-very-legitimate static vs dynamic typing debate. We’re not likely to solve it once and for all here. If go is your favorite language, you will hate julia and I’m comfortable with that.
I see “metaprogramming is confusing so a language is better without it”. Ok fair point, but we can’t exactly just delete all the metaprogramming features. Putting “no metaprogramming” in your style guide is totally fine, but if you want to use a language where it doesn’t exist at all, you obviously have to use a different language. Maybe julia 2.0 should not have macros? I guess it would make my life a lot easier, but it would make a lot of users quite unhappy. It’s not even only about macros — you can do a lot of “clever, tricky” programming just with higher-order functions, so trying to enforce “pedestrian” code seems too costly to me.
Interfaces are a really common topic of discussion and I think at this point we’re determined to do something about it in julia 2.0 (if it requires breaking changes).
declarative (rather than imperative) code is generally considered more robust or at least easier to analyze and verify. In Go, you write imperative code in functions, but the overall organization (definition of packages and functions) is declarative. In Julia, this organization itself is imperative.
I agree and I’m willing to do something about this. It is very common to run code at the top level, and that is arguably useful, but that does not necessarily need to extend to include itself. I remember an issue somebody filed once essentially saying “julia is bad because the include function exists; please delete it”. Personally I don’t understand being so bothered by some functionality existing, but nor do I love include all that much.
Fair warning though, if eval still exists you can write include easily. And that’s the trouble with a lot of these design philosophy issues: it’s hard to pull on a thread without the whole sweater unraveling. E.g. as soon as you want to statically check for one kind of thing, you have to statically check basically everything to guarantee that the first kind of check is possible. Or as soon as you allow some amount of reflection and reuse of the language, you get eval and include and all that.
For many of the type-checking-related issues, the best path forward I see now is to use GitHub - aviatesk/JET.jl: An experimental code analyzer for Julia. No need for additional type annotations., and figure out how to build workflows around it. At this point this is a significant UI/UX problem. If you want type errors, ok, we can give you some type errors (
), but the challenge is how do you convey what kinds of errors you’re interested in, and how and when do we invoke the tool? I think it’s very doable but ideas, UI polish, and documentation are needed here.
We had lots of reusable internal modules and tens of thousands of lines of Julia code. Eventually we had to give it a way and move to Python
I’m sorry to hear that, and I won’t question what works best for you. I’m curious about the real-time bit though. I agree julia is not a real-time language, but how does python solve that? Is it just a matter of refcounting vs. GC, and the workload being such that interpreter overhead doesn’t matter? Or did you rewrite bits in C?