# Should closures be avoided?

**URL:** <https://discourse.julialang.org/t/should-closures-be-avoided/96073>\
**Category:** General Usage\
**Tags:** question, closure\
**Created:** [March 14, 2023, 5:51pm UTC](https://discourse.julialang.org/t/should-closures-be-avoided/96073 "2023-03-14T17:51:29Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![prittjam](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/prittjam/32/21267_2.png) [@prittjam](https://discourse.julialang.org/u/prittjam)\
**Post date:** [March 15, 2023, 1:55pm UTC](https://discourse.julialang.org/t/should-closures-be-avoided/96073/8 "2023-03-15T13:55:20Z")

</div>

I would say at this point I’m focused on mathematical correctness but I have noticed the type instabilities proliferating with the use of closures and when I put functions into structure members (even when parameterized). I don’t really understand why, and I don’t really have a big time budget to dig into the more subtle issues, unfortunately. I guess there are two packages meant to deal with this: FastClosures and FunctionWrappers. I will need to fix it eventually to achieve state-of-the-art runtime. I’m worried that despite using fairly idiomatic code that I will have to tear it apart to get the speed needed.

I am competing against C++ frameworks which are hand-tuned. While we will have an algorithmic win, it won’t matter if I can’t close the performance gap in wall clock time. (We are trying to use Julia to publish). I’ve done static polymorphism (compiile-time) in C++ (expression templates) Eigen, etc… and there you know when you write your code it will be fast. I would say that if you stick to the design patterns; it is also elegant. The drawback with C++ is you lose a reasonable REPL. But I wonder what the time tradeoff will be between chasing down type instabilities and slower development time in C++.

---

_[View the full topic](https://discourse.julialang.org/t/should-closures-be-avoided/96073)._