Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Really well written. We have a similar story where we re wrote parts of our Java code in go and the build time has reduced from 15m to 3.6m! Coffee break to reading a small medium article.


> the build time has reduced from 15m to 3.6m.

Is 3.6m the build time of the remained Java code, the rewritten Go code, or both remained Java and rewritten Go code together?


java ~ 3.4 mins, go - 3-4 secs :D


How much code do you have that compilation is 3 minutes?


Its not go code fully. Its java that takes 3 mins. Go takes very less time like 3-4 secs. Multiple smaller services so we compile only what we change.


> Multiple smaller services so we compile only what we change.

Also doable in Java.


sure. Never denied. But we are breaking apart that java code part by part. The docker build size is also very small as mentioned in the article. Our app involves lot of bandwidth so we good with smaller containers.


More importantly, how much time did it take to rewrite code that took 15m to compile! Are the machines working for the man, or the man for the machines ;)


3 person effort for 4 months. Compile time was just one of the advantages though.


As this is the 3rd language in your code base, 1st there was java, then there was Scala and now GO. I do hope all Scala code is gone by now! I assume this decision and investment was extremely well supported, but that is not obvious from your blog post and supporting comments here.

So 12 months of effort -> at Bay area salaries and costings that is in the order of magnitude of 300,000USD. Your parent company had 6.6 million NZD profit last financial year. So for investing around 5% of the total profit of the larger group your mayor benefit is reduced compile times. Plus some other second system benefits.

That is a rather expensive decision to have taken, and I think if you had been forced to do a proper ROI investigation before hand you would not have gotten that. In my experience when doing these calculations and getting the numbers down it is never the financially wise choice to change languages but instead actually fix the pain points that people have with the language and most often the actual project setup. It is only when a language change is incremental, adds a key feature or is a market requirement e.g. for deploying on certain devices that a new language makes financial sense.

I am not judging your GO decision over Scala as a better language but I am judging your management layer for doing this. Especially as it sounds like from other posts that GO is now 1 more language to support in your company. Increasing certain costs outside of yours as a team in cross team training opportunity, support and monitoring etc...

Of course sometimes changing language is like changing from speaking French to Italian in the office and hoping that office politics will disappear... Been there done that, it did not work out as hoped by the developers.


I'm sorry we never used Scala.it was a pure Java code base.


Sorry I was confused between your experience and the opening post which was moving from Scala to GO. So I assumed you were working for Movio and used their numbers. Therefore my post does not make any sense :)

Then it was a Java to GO move. I wonder where your compiles take the most time. For our work building the jar files are the most expensive part. Javac is about 20 seconds all in for about 3000 files to compile on my 2009 macbook.


Well, no surprise, i didn't have to resolve all those generics... :)




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: