More recently, we've replaced Python, Ruby, and Java based systems with golang based ones. Not having to lug around a VM and associated other parts (jars, gems, ...) is a huge win. Performance is better across the board, and we've reduced the amount of hardware needed. There's also much better understanding of the code across the whole team.
Ask HN: When has switching the language/framework made an important difference?
21–30 of 152 posts
Re: Ask HN: When has switching the language/framework made an important difference?
#22Re: Ask HN: When has switching the language/framework made an important difference?
#23The SPARK people at AdaCore found a bug in the reference implementation of Skein just rewriting it in SPARK: http://www.adacore.com/knowledge/technical-papers/sparkskein...
byte_count := (n+7) / 8;
When n is near max size, it overflows to a small number, then (small number) / 8 = 0
the fix is to restrict n to [0,MAX-7)
Re: Ask HN: When has switching the language/framework made an important difference?
#24This mostly due to the inherent complexity in Spring and the fact that Spring developers are also Spring experts. When the main developer behind the application left, we struggled to add new features or even fix bugs because the team lacked the Spring expertise.
The rest of the business mostly dealt with Scala, so it was almost a no-brainer to go with Play.
The outcome has been very surprising. The application has better performance overall, is better suited for streaming and we have much more expertise in-house to add features and fix bugs.
The re-write was not without pain though. Spring is a well-supported and very rich framework. It probably does a bunch of things that the casual web developer will likely forget.
Re: Ask HN: When has switching the language/framework made an important difference?
#25The biggest change for me was when I switched to strictly typed languages. It doesn't matter if it's Go or Typescript or whatever. As long as it has types it dramatically improves maintainability and ease of scale.
Introducing types to the server side language has never done anything for me other than making sure that the types are in sync with those of the database while creating a lot of tedious overhead converting data that the application itself might not ever need to process to a particular type.
The Elixir gradual typing approach has always seemed like the ideal balance to me.
Re: Ask HN: When has switching the language/framework made an important difference?
#26Re: Ask HN: When has switching the language/framework made an important difference?
#27This is more than a little self serving, but when I switched us over to intercooler.js it made a huge difference in our app. When I pulled the trigger on it I was terrified that I was screwing us over by not using Angular (which was the cool tech at the time) or some other more javascript-oriented solution. Thankfully it has worked out well, and my co-founders don't hate me any more than they already did before hand.…
This isn't surprising to me at all. Having the creator of a framework working with a team using a framework is a huge benefit, almost regardless of the framework quality (within reason). And that's not a dig at intercooler's quality (I've never used intercooler, and am no fan of Angular), but I do think it's a huge confound. Meaning, if I had access to creator of framework A on my team, and was choosing between frame…
Re: Ask HN: When has switching the language/framework made an important difference?
#28Switching to React Native allowed our team of 6 to become a team of 2 and still go twice as quickly. It's not just the cross-platform capabilities - React is also just really great.
Re: Ask HN: When has switching the language/framework made an important difference?
#29The biggest change for me was when I switched to strictly typed languages. It doesn't matter if it's Go or Typescript or whatever. As long as it has types it dramatically improves maintainability and ease of scale.
Re: Ask HN: When has switching the language/framework made an important difference?
#30Several years ago, our team refactored a large Java control system into a Ruby based one. The Ruby actually performed faster, scaled better, and was much easier to understand and maintain. The ergonomics of Ruby enabled clearer thinking about the problem, leading to the better results. More recently, we've replaced Python, Ruby, and Java based systems with golang based ones. Not having to lug around a VM and associat…