Ask HN: When has switching the language/framework made an important difference?

I'm curious about real world examples where a change (preferably measurement/profiling driven) has lead to a significant positive outcome in performance, code quality/maintainability, etc.

Did changing from Python to Go make it so that you could avoid horizontal scaling for the size of your app, reducing operational complexity?

Did switching from Dart to Rails speed up development because of the wide range of libraries available, speeding up time to market?

While most bottlenecks exist outside of languages/frameworks, I find it interesting when the language/framework actually made a difference.

An example I'll use is switching an internal library from C# to F#: The module as designed mutated 3 large classes through a pipeline of operations to determine what further work was needed. I incrementally rewrote this module in type-driven F# with 63 types to model the data transformations and ensure that the correct outcome desired was compiler verified. In the process 3 bugs were fixed and 12 additional bugs were discovered that while edge cases, had a couple of old tickets with "unable to reproduce" as the last comment in the ticketing system. This could have been done in C# and because I did it in F# it is most likely slightly more difficult for the other team members to jump into. It probably also uses more memory to represent the types than the C# version. In this case however, the trade offs were worth it and I've been told the module has barely needed to be touched since.

Another example: same language, new framework: In a Python web app, we needed to have websockets. But at that time Django had no real websocket support. But there is future proof framework that does: aiohttp! Also one might argue that you can use old django with websocket using another process. But it leads to a more complicated architecture. We want to keep monolith the app as long as possible/sane.

In this case the original code had a class like:

    class DeliveryItem {
        public bool isTagged { get; set; }
        public Deliverer previousDeliverer { get; set; }
        public Deliverer nextDeliverer { get; set; }
        public string itemName { get; set; }
        public DateTime lastTransferTime { get; set; }
    }

While not ideal, this worked fine if pipeline was an ordered sequence. The pipeline had grown into a complex graph, with many different possible states, and new properties were incrementally added to shoehorn the new states and transfers between states into the single object.

The class grew large and it became difficult to determine from logs what path of the pipeline that an item had taken. It could have been scanned, weight analyzed, compaction determined, etc, etc. And these didn't always happen in the same order because of the business process.

Instead I created types like `NewDeliveryItem`, `PreProcessedDeliveryItem`, `ThirdPartyVerifiedDeliveryItem`, etc.

It allowed for explicit modeling of the pipeline, since functions could take a `PreProcessedDeliveryItem` instead of a `DeliveryItem` and would know that they wouldn't need to send it for processing.

The example has been translated a bit and isn't the best explanation, but gives a small amount of detail.

You can check out https://fsharpforfunandprofit.com/series/designing-with-type... and https://fsharpforfunandprofit.com/ddd/ to get more information on how this can decomplect seemingly simple applications.

I wish it were an easier thing to do, but I think as far as maintainability and codebase size scalability go, it's hard to quantify properly without metrics that are usually only tracked in enterprises.

I'm trying to think about how to make this more clear in the original post.