I think the author addresses this. It’s a Catch-22. If you restrict use to a small subset of types you’re undermining one of Julia’s best features.
As someone who has been writing a lot of numerical analysis code recently, I would absolutely love a type system that could describe and enforce numerical stability traits.
I learnt the hard way that you can architect Julia apps the wrong way. I think my biggest frustration is how easy it is to make mistakes that cause type unstable code.
I appreciate your view but seeing as how most Julia projects work this way I sometimes wonder if it's just a problem with the language itself. Not trying to be a troll with impossible expectations, but genuinely the code is unstable, and yes they have been working on it for a long time.
Not getting something so basic correct tells me to avoid the whole thing for fear of getting subtly screwed by some other oversight.
No one denies that this is a problem, and it will be fixed. But I disagree that it represents a fundamental flaw. For iterative development, it is a minor inconvenience, so other priorities have taken precedence. If you are redefining functions in this way in tested code, there may be bigger problems to worry about.
The Julia developers have paid fastidious attention to correctness (to the point of making a pilgrimage to visit Kahan early on). The type system is well thought-out and nice to use. Spurious crashes are almost nonexistent (and fixed within hours, without fail). The foundation is solid, but it's still a work in progress, and it will take some time to shake these sorts of features out.
Julia is weird.. it's like someone saw all of TypeScript's or F#'s opaque type errors and then thought "wouldn't it be better if all of these could happen... at run time?"
In seriousness I have been enjoying it a lot over Python, but I'd kill for static typing.
It's highly expressive (comprehensions, functional-style all-statements-are-expressions, anonymous named tuples, and heaps more) and these features seem to be usable without sacrificing performance, in a way that I've not yet seen in any other language.
I've been getting a lot of mileage out of Julia recently, and would counter that plenty of fans of statically typed languages just haven't learned to use an effectively-typed dynamic language.
Julia’s type system is not particularly user-friendly. For example, it has both a “String” and a “SubString” type which cannot always be interchanged. Their language design seem to be much more concerned with execution speed than programmer productivity — Python has the balance in the opposite direction, but they’ve been gradually improving performance for years, and this is much easier to improve after the language design is set in stone, especially as more and more people add typing info to their programs.
I love Julia's type system. I just wish the whole thing was static (I've never had a case where the Any type worked better than explicitly specifying a type).
Personally I would like to see Julia go full static typing. The dynamicness of its current type system seems to offer me no advantages and is constantly causing me problems with performance. My code ends up covered in type declarations because I'm never sure when types are concrete or not,which kind of defeats the point of implicit typing. A lot of the time a seamingly innocuous change will result in Array{Float64,1} getting changed to Array{Any,1} which then gets propagated automatically though the whole program, since functions can't have return types.
Julia claims to be the future of numerical computing, but they seem to put more effort into coming up with fancy abstractions that no engineer or scientist will ever understand than working on basic numerics. For example, the array implementation is very hit or miss and much much slower than and has much more complicated semantics than arrays in Fortran. I think this is due to the fact that arrays are not first class objects in the language, and probably because the authors don't do much multidimensional high performance work.
Only thing "interesting" to me there would be the automatic differentiation bugs ...but is there any argument as to them being the fault of the language, instead of just poor engineering from the library developers' part?
I mean, one can't expect all algorithms to work correctly with all datatypes just because the compiler allows that code to run ...you write tests and guarantee numerical stability for a small subset of types you can actually do it for, and then it's the code's consumers' job to ensure it work with types it's not documented to work and such, no? ...Julia is quite a dynamic language, JITed or what not, its semantics are closer to Python and Lisp than to Rust or Haskell ...maybe don't expect guarantees that aren't there and just code more defensively when making libraries others depends on?
Probably the Python + C(++) ecosystems works better bc their devs know they are working in loose, dynamic and weekly typed shoot-your-foot-off type languages and just take action and code defensively and test things properly, whereas Julia devs expect the language to give them guarantees that aren't there.
Every time Julia pops up I can't help but get disappointed all over again. I was so intrigued by multiple aspects of the language, and even the type system seemed promising at first. However the inability to subtype concrete types is a total dealbreaker for me.
Everything else - even much of the type system - is extremely interesting. However the inability to subtype concrete types means you are essentially stuck with the unfortunately common inability to trivially specify how the heck your program is modeling your problem.
I just want the ability to specify an Apple_Count is not an Orange_Count without having to define my own damn operators. Why do so many languages make this so hard?
And Julia was so close, until one little sentence moved it so far away.
I think it's fair to point out that Julia makes it really hard to write robust, correct code.
There are a lot of different interacting reasons for this (it deserves a blogpost on its own), but here are a few:
* There are no interfaces
* Existing abstract types are mostly undocumented: It's unknowable and certainly untestable what constitutes an IO or a Number or even an AbstractArray (yes, even AbstractArray leaves important edgecases unspecified).
I've written 100 methods that takes `::IO`, yet I don't actually know what it can take. Much of the issues with unsupported package interactions come down to this: One package doesn't know what it promises, and the other one doesn't know whether the promise is upheld. E.g. it's still unclear to me whether `OffsetArrays` actually fulfill the contract of an AbstractArray. If not, it's a bug that it's an AbstractArray. If so, Base is insufficiently tested, as it ought to test its AbstractArray code with an AbstractArray with offset axes.
* Base Julia have several functions that are simply not tested. CodeCov of Base is far from 100%
* Iterators are assumed by Base and Iterators to be immutable - a buggy assumption in many contexts
* It's not even clear what is public and private in a package. E.g. are fields of exported struct private? Where is that documented? And it's way too easy to rely on unexported symbols.
* Speaking of which, you can export stuff that does not exist.
* Projects does not have compat entries by default
* Generic functions are rarely tested generically - i.e. not with any minimal abstract type.
* Promotion rules of non-numbers are unclear and underspecified, and accidentally changed recently on master because it's not documented nor tested anywhere
* There is a lot of "Yeah, X isn't really semantically correct, but I can exploit its weird behaviour in my own code, so we shouldn't fix it, it's actually a feature" hacker attitude among Julians.
There are like, 100 more small things that make Julia more bug-prone. I think this is a serious issue about the language that we should take note of and try to work on. You'll notice several of these issues can be resolved. But we need to take it seriously.
One interesting thing is that if julia can prove what types a function will be called with at compile time, it doesn't have to do dynamic dispatch, so it has no overhead. It's what the julia folks call type-stable code
Yes but Julia is (yet another) dynamic language, presumably for "ease of use". A language with static types would have made it easier to build correct software (scientific code in e.g. OCaml and F# can look pretty good). Julia chose a path to maximize adoption at the expense of building a reliable ecosystem. Not all languages choose to make this trade-off.
reply