[HN Gopher] Ask HN: Have you ever migrated a large/old project t...
       ___________________________________________________________________
        
       Ask HN: Have you ever migrated a large/old project to a different
       language?
        
       I'm curious if anyone has had the experience of porting over a
       large, existing project to a different language (either because of
       performance or other reasons). If so, how did that go? It seems
       like it could be a rather risky venture and one that a person ought
       to embark on with some due caution. Any general ideas or
       suggestions for how to go about this? Is it advisable to gradually
       move over bits of the existing system (like the parts that need
       better performance, assuming that's the reason for the switch)?
       Really appreciate hearing about your experience.
        
       Author : xwowsersx
       Score  : 7 points
       Date   : 2022-09-13 21:49 UTC (1 hours ago)
        
       | contingencies wrote:
       | Only abortively.
       | 
       | The received wisdom of yore is that it's easier to port code from
       | one language to another than to rewrite from scratch. However, I
       | suspect in practice most people who do that will wind up
       | rewriting in part and that's where the pain happens, screwing up
       | all the undocumented edge cases.
       | 
       | In this day and age it generally makes more sense to keep the
       | codebase in the original language and use virtualization as
       | required to keep it running without the human overhead of
       | porting.
        
         | xwowsersx wrote:
         | > use virtualization as required
         | 
         | Can you elaborate on this? I'm not sure what is meant by
         | virtualization in this context.
        
           | contingencies wrote:
           | You keep the old stack running in an isolated, future-
           | platform-compatible, virtualized context to avoid the work
           | and risk associated with a port.
        
       | kashkhan wrote:
       | Have done several migrations from PHP to Java and iOS apps from
       | Objective-C to Swift etc.
        
       | mattpallissard wrote:
       | While a complete re-write can be fun, in my experience it's
       | usually not the best course of action. In decreasing order of
       | most bang for your buck (your mileage may vary)
       | * Profile the code, clean up the hot paths in the native
       | language.         * If it makes sense, implement as a c-extension
       | * Restructure your application to handle concurrency/parallelism.
       | Lots of options to try here; thread pools, external task queues,
       | break your application into multiple services.         * Re-write
       | one of the smaller services you spun out in the language of your
       | choice.
       | 
       | Edit: formatting
        
         | xwowsersx wrote:
         | This makes sense. I totally get the starry-eyed, romantic
         | appeal of rewriting in your new favorite language, but I know
         | that maturity would counsel for a good dose of conservatism
         | when it comes to this.
        
       | wizofaus wrote:
       | Depends on your definition of "large" and "migrated", but yes, a
       | number of times. In one case it was a straight rewrite,
       | maintaining the same functionality (from JS into C#). I'd been
       | anticipating it would take at least 2 or 3 weeks initially (based
       | on how long it took the original JS code to be written, and the
       | level of functionality), but it ended up taking less than a week.
       | It was done wholesale, because it was basically a microservice
       | where all the APIs depended on the same DB backend, and the DB
       | conversion (from dynamo DB to SQL server) was the first bit I
       | did. I had been planning for long time to do the same for a much
       | larger Java backend project. I'd been going through in my head
       | how to do it piecemeal but the problem was it wasn't just the use
       | of Java I was trying to get away from (though that was the
       | primary motivator - too many things about the
       | tomcat+spring+hibernate stack annoyed me and were a serious drag
       | on productivity) but some bad architectural decisions as well,
       | including the amount of business logic spread throughout various
       | layers etc. Still, if I'd been given the greenlight (I left that
       | role before I had the chance) I reckon I could've knocked it off
       | in a few months. The main challenge was that I would essentially
       | have to maintain the same API for existing mobile clients, and
       | there was a lot wrong with that API (very inconsistent use of IDs
       | for a start, including integer DB identity field IDs that I'd
       | hoped to get rid of). I'd even seriously thought about fixing the
       | API first within the Java version before converting to C#/.NET.
        
       ___________________________________________________________________
       (page generated 2022-09-13 23:02 UTC)