Hacker News Reader

Comment by mgkuhn | Hacker News Reader

Julia is a very powerful and flexible language. With very powerful tools you can get a lot done quickly, including shooting yourself into the foot. Julia's type-system allows you to easily compose different elements of Julia's vast package ecosystem in ways that possibly were never tested or even intended or foreseen by the authors of these packages to be used that way. If you don't do that, you may have a much better experience than the author. My own Julia code generally does not feed the custom type of one package into the algorithms of another package.

View on HN

One can hardly call using the canonical autograd library and getting incorrect gradients or using arrays whose indices aren't 1:len and getting OOB errors “shooting oneself in the foot” — these things are supposed to Just Work, but they don't. Interfaces would go a long way towards codifying interoperability expectations (although wouldn't help with plain old correctness bugs).

With regard to power and flexibility, homoiconicity and getting to hook into compiler passes does make Julia powerful and flexible in a way that most other languages aren't. But I'm not sure if that power is what results in bugs — more likely it's the function overloading/genericness, whose power and flexibility I think is a bit overstated.

Zygote hasn’t been the “canonical” autodiff library for some time now, the community recognized its problems long ago. Enzyme and Mooncake are the major efforts and both have a serious focus on correctness

In this debate there seems to be a pervasive impulse to point out "that specific problem doesn't exist anymore," and to their credit the developers are generally good at responding to serious problems.

However, the spirit of the original post was about the lack of safeguards and cohesive direction by the community to find ways to preempt such errors. It's not an easy problem to solve since Julia's composability and flexibility adds complexity not encountered in other languages. The current solution is, 'users beware', while there are a few people working on ways to enforce correct composability. I think it's best to acknowledge that this is an ongoing issue and that it's not a problem anymore because the specific ones pointed out are fixed.

One of the basic marketing claims of the language developers is that one author's algorithm can be composed with another author's custom data type. If that's not really true in general, even for some of the most popular libraries and data types, maybe the claims should be moderated a bit.

> one author's algorithm can be composed with another author's custom data type

This is true, and it's a powerful part of the language - but you can implement it incorrectly when you compose elements together that expect some attributes from the custom data type. There is no way to formally enforce that, so you can end up with correctness bugs.

My experience is that it is true, if you throughly implement the interfaces that your types are supposed to respect. If you dont, well, thats not the languages fault.

Reply on news.ycombinator.com