Cthulhu.jl – show type-inferred Julia code(github.com)
github.com
Cthulhu.jl – show type-inferred Julia code
https://github.com/JuliaDebug/Cthulhu.jl
35 comments
These tools are a great improvement, but honestly I find working with this aspect of Julia to be super frustrating. External tools feels like a poor substitute for a type system where this kind of information was obvious from the code.
Are you talking about static typing? If so, that sounds fundamentally incompatible with the basic worldview behind Julia — that you want to delay binding/dispatch till runtime, and leverage multiple dispatch, for high composability & code reuse.
I wonder how capable the ahead-of-time compiler would be, if you have not just the library, but can also provide the “inputs” in your “script” (that it can specialize on).
I wonder how capable the ahead-of-time compiler would be, if you have not just the library, but can also provide the “inputs” in your “script” (that it can specialize on).
Playing advocatus deii for Julia, I guess you could write code, where all function signatures only contain concrete types. Then the ahead-of-time compiler would work the same as for a C++ program without templates and dynamic polymorphism through subtyping. That's a totally valid programming model, that noone uses.
Of course you don't have to go that far in practice and you still could have static types with less restrictions, as long as the types are inferable
The question I have is whether Julia-style multiple dispatch would be practical in a statically typed language?
Multiple dispatch is a kind of runtime type resolution. Static/compile-time function overloading based on types is a thing, but is fairly banal... common in C++, but mostly forbidden in Rust, but it doesn't resolve on vtables, so doesn't give you the same kind of polymorphism as what you'd get in Dylan/Julia/CLOS/Cecil, etc.
This looks like a good series of blog posts on this topic: https://eli.thegreenplace.net/tag/multiple-dispatch
Myself, I was excited to work in a language with multiple dispatch at first, but once I spent some time working full-time in Julia the sheen wore off. It could be Julia's take on it, but I really don't like the kind of ... semantic overloading ... and duck typing that can happen all over the place.
Programs can become very hard to reason about.
This looks like a good series of blog posts on this topic: https://eli.thegreenplace.net/tag/multiple-dispatch
Myself, I was excited to work in a language with multiple dispatch at first, but once I spent some time working full-time in Julia the sheen wore off. It could be Julia's take on it, but I really don't like the kind of ... semantic overloading ... and duck typing that can happen all over the place.
Programs can become very hard to reason about.
I've worked quite extensively for Julia as my primary language for quite some time at this point. I've gone from being absolutely in love with the language to extremely disillusioned over the last couple of years.
It is incredibly hard to reason about this language if every developer is not willing to commit to understanding and writing Julia code the right way (e.g. type stable, dispatch via the type system, actually defining interfaces). Given the target demographic of academics, the proportion of people interested in grokking Julia is vastly smaller than the number of academics who hear "walks like Python runs like C" and decide this is their new, free, hip MATLAB/SciPy replacement.
And it's extremely good for that! The SciML ecosystem is top of the class, I would never recommend someone solve a differential equation any other way. If you can build a system that is just a thin wrapper on top of SciML, absolutely go for it. I would recommend anyone wanting to build new systems from scratch to look elsewhere.
But, the tooling is subpar and overfit to the VS Code extension, and even there I found so many false positives with the linter that I just started ignoring all but the most basic of warnings. It's not entirely the fault of the developers, Julia is dynamically typed and there's only so much you can do. But if you have to type things rigidly enough that it's inferrable while developing that Cthulhu.jl or JET.jl can infer the types, why not just work with a static type system where you get that for free?
I have also found the obsession with reducing time to first plot incredibly aggravating. It is finally down to a pretty good level, which is a nice quality of life improvement. However, it has done absolutely nothing for my ability to write code that doesn't crash because someone passed in a type that doesn't obey the implicit interface I expect.
It is incredibly hard to reason about this language if every developer is not willing to commit to understanding and writing Julia code the right way (e.g. type stable, dispatch via the type system, actually defining interfaces). Given the target demographic of academics, the proportion of people interested in grokking Julia is vastly smaller than the number of academics who hear "walks like Python runs like C" and decide this is their new, free, hip MATLAB/SciPy replacement.
And it's extremely good for that! The SciML ecosystem is top of the class, I would never recommend someone solve a differential equation any other way. If you can build a system that is just a thin wrapper on top of SciML, absolutely go for it. I would recommend anyone wanting to build new systems from scratch to look elsewhere.
But, the tooling is subpar and overfit to the VS Code extension, and even there I found so many false positives with the linter that I just started ignoring all but the most basic of warnings. It's not entirely the fault of the developers, Julia is dynamically typed and there's only so much you can do. But if you have to type things rigidly enough that it's inferrable while developing that Cthulhu.jl or JET.jl can infer the types, why not just work with a static type system where you get that for free?
I have also found the obsession with reducing time to first plot incredibly aggravating. It is finally down to a pretty good level, which is a nice quality of life improvement. However, it has done absolutely nothing for my ability to write code that doesn't crash because someone passed in a type that doesn't obey the implicit interface I expect.
> I have also found the obsession with reducing time to first plot incredibly aggravating. It is finally down to a pretty good level, which is a nice quality of life improvement
For the target users of Julia, which are academics that are currently using Matlab or Python, time to first plot is one of the primary reasons that they are not willing to switch to Julia. Especially if their current workflow is writing a script then pressing run button in Matlab or calling python my_script.py, then they do julia my_script.jl and they expect it to work the same way as Python or Matlab do. This is why in all the user & developer survey TTFP is consistently ranked highest.
As a research software engineer, I've seen PhDs and postdocs that are downright scared of programming and any kind of low level technical work in general, even if their problem domain requires high performance languages. They just want their project or thesis to finish within their probably unrealistic deadlines. You throw them to a language with strict type checking or traits and interfaces and they will just give up. Unfortunately if the language users are filled with these kind of user then it results to this kind of problems, which you did mentioned in your second paragraph.
> It is incredibly hard to reason about this language if every developer is not willing to commit to understanding and writing Julia code the right way (e.g. type stable, dispatch via the type system, actually defining interfaces). Given the target demographic of academics, the proportion of people interested in grokking Julia is vastly smaller than the number of academics who hear "walks like Python runs like C" and decide this is their new, free, hip MATLAB/SciPy replacement.
Thinking about it, to solve this Julia problem we need to solve academics scared of programming problem. I don't have a solution to this either, I've been trying to think about it after seeing several people keep asking me for help in programming
For the target users of Julia, which are academics that are currently using Matlab or Python, time to first plot is one of the primary reasons that they are not willing to switch to Julia. Especially if their current workflow is writing a script then pressing run button in Matlab or calling python my_script.py, then they do julia my_script.jl and they expect it to work the same way as Python or Matlab do. This is why in all the user & developer survey TTFP is consistently ranked highest.
As a research software engineer, I've seen PhDs and postdocs that are downright scared of programming and any kind of low level technical work in general, even if their problem domain requires high performance languages. They just want their project or thesis to finish within their probably unrealistic deadlines. You throw them to a language with strict type checking or traits and interfaces and they will just give up. Unfortunately if the language users are filled with these kind of user then it results to this kind of problems, which you did mentioned in your second paragraph.
> It is incredibly hard to reason about this language if every developer is not willing to commit to understanding and writing Julia code the right way (e.g. type stable, dispatch via the type system, actually defining interfaces). Given the target demographic of academics, the proportion of people interested in grokking Julia is vastly smaller than the number of academics who hear "walks like Python runs like C" and decide this is their new, free, hip MATLAB/SciPy replacement.
Thinking about it, to solve this Julia problem we need to solve academics scared of programming problem. I don't have a solution to this either, I've been trying to think about it after seeing several people keep asking me for help in programming
I was working in a non-numerics/non-scientific code base and the quality of the code was good to very good. And I could see the value Julia was bringing to the table on some aspects of the higher levels of their stack. But it utterly fails at being any kind of "systems language", and it was being coraled into that role in spots. Tossing some optional somewhat-static (but not really) type declarations and a JIT into the language doesn't make it a performant language for areas where something like C++, Rust, etc. would be more suited.
And yes, like any late-bound language, it's going to be prone to crashing at runtime in unexpected ways. Julia has some okayish tools for doing some static analysis, but it's never going to be at the level of what you can get out of an actual modern static type system. I was fortunate to work with some very smart people who had written some very high quality code in Julia, and some aspects of the language I found very nice and expressive (and even sometimes miss), but I was happy to go back to writing Rust after I switched jobs.
And yeah, not being a VSCode user (JetBrains addict), I found tooling lacking as well. The emacs mode was okayish. Also found I kept having to use the Repl in ways I found non-intuitive.
I would reach for Julia as an alternative to Python, maybe, for certain types of things. It's certainly prettier to look at.
And yes, like any late-bound language, it's going to be prone to crashing at runtime in unexpected ways. Julia has some okayish tools for doing some static analysis, but it's never going to be at the level of what you can get out of an actual modern static type system. I was fortunate to work with some very smart people who had written some very high quality code in Julia, and some aspects of the language I found very nice and expressive (and even sometimes miss), but I was happy to go back to writing Rust after I switched jobs.
And yeah, not being a VSCode user (JetBrains addict), I found tooling lacking as well. The emacs mode was okayish. Also found I kept having to use the Repl in ways I found non-intuitive.
I would reach for Julia as an alternative to Python, maybe, for certain types of things. It's certainly prettier to look at.
Using Julia as non-numerics/non-scientific systems language is not a good fit. So, not surprising you are not finding it as useful as Rust. JIT performance notwithstanding. As for Python, it is getting defaulted to any and every programming niche with predictably bad results.
The problem is that the language is in part pitched this way, as a "best of both worlds" language where you can get "C-like" performance while still living in a dynamic world, at least in part. But it's not true.
It's certainly faster than Python, and a more elegant language. So I'd be in a much happier world if people were using it for some of the places where they're using Python. But its slow startup time makes it unsuitable for many scripting type tasks. And its module system and deployment thereof is... complicated.
It's certainly faster than Python, and a more elegant language. So I'd be in a much happier world if people were using it for some of the places where they're using Python. But its slow startup time makes it unsuitable for many scripting type tasks. And its module system and deployment thereof is... complicated.
I have not yet fallen out of love with the language, but I can absolutely sympathize with the desire for better ways to define and enforce interfaces. In my opinion it is the #2 issue for me right behind having a non-kludgy import/module system
[deleted]
Haskell's type classes work fine, similar enough to multiple dispatch.
I think it would be great for Julia to have a mechanism to formalise/enforce interfaces.
I thought a bit about it lately and came to the conclusion, that something like C++ concepts (minus the clunky syntax) would be a better fit for Julia than Haskell's typeclasses or Rust traits. The main difference for me is, that typeclasses are a whitelist of allowed types, while concepts are a set of type constraints, that blacklist types, when the constraints are not fulfilled. Otherwise they are quite similar.
As a result, you don't have to explicitly create a instance with concepts like you would need to do for type classes and packages can happily interoperate without knowing of each other.
I thought a bit about it lately and came to the conclusion, that something like C++ concepts (minus the clunky syntax) would be a better fit for Julia than Haskell's typeclasses or Rust traits. The main difference for me is, that typeclasses are a whitelist of allowed types, while concepts are a set of type constraints, that blacklist types, when the constraints are not fulfilled. Otherwise they are quite similar.
As a result, you don't have to explicitly create a instance with concepts like you would need to do for type classes and packages can happily interoperate without knowing of each other.
I think type classes and packages can happily interoperate without knowing of each other, just like abstract types and packages do currently...well I guess the concepts idea would make it so you'd need even less coordination. But yeah, would be nice if Julia had formal interfaces.
Yeah in the end this the difference between dynamical and static typing.
I enjoy https://tratt.net/laurie/research/pubs/html/tratt__dynamical... as a discussion of dynamic typing.
I enjoy https://tratt.net/laurie/research/pubs/html/tratt__dynamical... as a discussion of dynamic typing.
One of the authors here, happy to answer questions.
Ph'nglui mwgl'nafh Cthulhu R'lyeh wgah'nagl fhtagn?
You had a perfectly good opportunity to call a function madness and then descend into it, why didn't you?
This could be a feature request.
Ah but what defines madness? For me it's innocuous functions that have surprising/wild behavior due to type inference disagreeing with me.
Most of the time I am the one wrong.
Most of the time I am the one wrong.
Changing the `function foo()` in the "Usage: descend" section to `function madness()` sounds like a pretty good/funny idea.
Positive: it would also let people know at a glance that things like `rand() > 0.5 ? Int64 : Float64` are indeed madness.
Potential negative: some people may not consider it super DEI-friendly? As a neurodivergent person, I'd just find it to be just a lovely reference though.
@descend madness()
Positive: it would also let people know at a glance that things like `rand() > 0.5 ? Int64 : Float64` are indeed madness.
Potential negative: some people may not consider it super DEI-friendly? As a neurodivergent person, I'd just find it to be just a lovely reference though.
Latest release adds integrate with VSCode that shows inferred types inline.
What does this show that @code_warntype doesn't?
A few things. For me the most important is that it lets you easily explore the whole compile time call graph. (i.e if `h(x)=x*x` and `f(x)=h(x)`, Cthulhu will let you easily switch from looking at `f` to looking at `h` (think of it like compile time debugging). Cthulhu also has the equivalent of @code_llvm and @code_native.
This is extremely helpful when hunting for type instabilities.
`@code_warntype` and `Cthulhu.@descend` can both show `SomePackage.foo` was inferred as `Any`. But why? Cthulhu lets you immediately descend, and see that it's because it calls `SomeOtherPackage.bar`, so you descend, and see...
Five or ten calls in, you finally see a problem you can fix that can motivate a PR. This is fast to do with with `Cthulhu`. Descending is as easy as pressing `[enter]`, instead of requiring you to construct all the arguments and descend.
Exploring the call graph while doing this gives you some overview of what the code is doing, and you can always look for the initial cause of propagating instabilities, instead of wading through a ton of JET output (but JET is also great).
`@code_warntype` and `Cthulhu.@descend` can both show `SomePackage.foo` was inferred as `Any`. But why? Cthulhu lets you immediately descend, and see that it's because it calls `SomeOtherPackage.bar`, so you descend, and see...
Five or ten calls in, you finally see a problem you can fix that can motivate a PR. This is fast to do with with `Cthulhu`. Descending is as easy as pressing `[enter]`, instead of requiring you to construct all the arguments and descend.
Exploring the call graph while doing this gives you some overview of what the code is doing, and you can always look for the initial cause of propagating instabilities, instead of wading through a ton of JET output (but JET is also great).
It tries to show you the type information on the source itself, instead of on the IR.
This sounds great!
Is this built into the existing VSCode extension, or as another extension you need to install?
Is this built into the existing VSCode extension, or as another extension you need to install?
Just update to latest julia extension and use Cthulhu inside the extension started REPL.
Love this tool. Invaluable for figuring out what code actually got called after complicated dispatch.
It looks handy to help you debug type inference problems by recursively displaying the type inference code until you find the exact location where the inference failed, went wrong, or had an accident. This feature is very useful for my current development, thanks to the author!
Hoping this doesn't reopen "Julia is dependent typed" debate