4 ms·
Yeah, that's true. I think there are three major limitations. - First, code that is intentionally (or out of neglect) opaque to the compiler. For example, some
by jakobnissen 6y ago
Yeah, that's true. I think there are three major limitations.
- First, code that is intentionally (or out of neglect) opaque to the compiler. For example, someone may simply forget to write type stable code, or someone might intentionally create a function barrier to specialize some code
- Second, Julia has no standard way of encoding constrains on types. That's good, because someone else can make up a new type you never thought about, and throw it into your functions, and if it has implemented all the right methods, it will work. But it also means you can never guarantee your code will work for any type.
- Third, Julia encodes less information in the type system - e.g. the use of result types is not common.
- dklend122 6y agoTo your second point, it will throw method errors at compile time
- jakobnissen 6y agoYes, but if you are making a library, there is no way you can statically confirm that your function will work for all types if they conform to some interface. All you can do is test it for a few concrete types that you have. A static language allows you to do that.
- dklend122 6y agoYea. Hopefully interfaces, which have been mentioned by the core team as being desired , will help.