@craigmaloney yes, and you lose all the little decisions and bug fixes implicitly incorporated in your old code over time, which honest refactoring would retain, or at least make you think about.
(Cue the classic Joel Spolsky's piece https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/)
@craigmaloney (I know that you know, I'm just fuming :-) )
@isagalaev No worries. :)
Though I'll never fault anyone for rewriting from Java. That language needs some serious help.
@craigmaloney I've been told the most recent Java is not quite so bad :-) But in general I stopped hoping once it was acquired by a non-software company.
@isagalaev True, but you also get the ability to use different methodologies when changing languages. Some projects may work better with a functional paradigm (or at least having the ability to have different functional pieces inter-operate on multiple servers).
I don't fault projects for re-writing if they want to modernize an aging codebase. But yeah, understanding the risks and the underlying reasons for doing a rewrite have to be ever-present in the redesign.
@craigmaloney "you also get the ability to use different methodologies when changing languages." — agreed. But I am watching a video where guys say, effectively, "we replaced a mess of if-else in Go with a functional filters in Clojure", and I want to say, "are you telling me you couldn't write filter functions in Go?"
And I should say love Clojure and don't like Go, but it's just not a good reason to switch.
@isagalaev Yeah, it shouldn't be the primary reason. Only reason I can think of for moving from Go to Clojure is either "we love Lisp" or "we're a Java shop and really love Lisp".
@craigmaloney fair enough :-)
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!