This article hits on something I've been wrestling with in our codebase. The absence of static typing in Clojure makes refactoring feel like walking a tightrope without a safety net sometimes. I've found that building a solid test suite before any major refactoring is absolutely critical - it's the only reliable way to ensure you haven't broken anything when reorganizing code.
What's worked well for us is treating functions as the primary refactoring unit rather than trying to impose OO-style refactoring patterns. Breaking down large functions into smaller, well-named pure functions has provided the most bang for our buck. We've also found that leveraging spec for runtime validation gives us some of the safety of types without giving up Clojure's flexibility.
The tooling situation has improved significantly too. Cursive's refactoring tools have been solid, and I'd be curious if others have had success with the newer REPL-integrated refactoring approaches mentioned in the article. Has anyone managed to set up effective continuous integration that catches runtime errors in untested paths?
As a fellow Go developer, I want to express my deep gratitude for your immense contributions to the language and its community. Your work has not only shaped Go into the productive and enjoyable language it is today, but has also inspired countless engineers—including myself—to build better software. Thank you for your dedication and for paving the way for the next generation of Go developers. Wishing you all the best in your future endeavors!
Odin seems to strike a really interesting balance between simplicity and practicality, especially for game development. I like the idea of having “batteries included” without too much abstraction getting in the way. For those who have used both Odin and Go, how do you feel about the differences in day-to-day development? Are there any features in Odin that you wish Go had, or vice versa? Would love to hear more real-world experiences!