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

Things like bug count and time to market seem difficult to separate from having more experience as a developer or knowing your problem space better. We use almost all Java, and we have several projects that we did major re-designs of in the same language, which increased maintainability, found bugs, etc. But if I chose a different language, I would have probably attributed it to the new language or framework.

Unless you have a problem that fits a specific technology really well, my experience is that your time to market will be minimized by using the tools you know best.

I'll echo this sentiment, although I found Go much more limiting type-wise than Typescript, Java, or other mainstream typed language.

But in general, moving from PHP, Python and JS (where I started out years ago) to languages like Java, Flow-typed JS, and even Scala at work have made me realize how much dynamically-typed large projects loose in maintainability vis-a-vis statically-typed projects. Yes, excellent test coverage can help mitigate this, but static types go so much farther when used effectively.

Due to the desire to support Windows as a first-class citizen on a project, I've lately moved some support scripts from Bash to Python. These include dependency-scrapers (that assemble makefile rules), and archiving scripts (that back up selected files from selected directories).

This has been a big win in terms of the readability of the code, which has in turn made me more aggressive about adding features.

A few years ago, I rewrote an `R` script into Fortran, for better than order-of-magnitude speed increase.

The script optimized the placement of samplers in a building, in order to maximize the probability of detecting airborne pollutants, or to minimize the expected time required to detect. The rewrite cut the runtime down from 2-3 days to sub-hour.

Some of the speedup was intrinsic to the interpreted/compiled divide. However most of the speedup came from the greater control Fortran gave over how data got mapped in memory. This made it easier for the code to be explicit about memory re-use, which was a big help when we were iterating over millions of networks.

Re-using memory was helpful in two ways, I think. First, it avoided wanton creation and destruction of objects. Second, and more importantly, it allowed bootstrapping the work already invested in evaluating network `N` when it came time to evaluate a nearly-identical network `N+1`. Of course, I could have made the same algorithms work in R, but languages like C or Fortran, which put you more in the driver's seat, make it a little easier to think through the machine-level consequences of coding decisions.

That experience actually taught me something interesting about user expectations. When the Fortran version was done, my users were so accustomed to waiting a few days to get their results, that they didn't run their old problems faster. Instead, they greatly expanded the size of the problems they were willing to tackle (the size of the building, the number of uncertain parameters, and the number of samplers to place).

I have some similar work cut out for a batch file to Python port for a bunch of automation work. It's totally worth it like you say with readability and widening the feature pipeline.