Ask HN: How do you stay focused while it's compiling?
Nowadays, every time I need to compile and run my code, it takes about 3 minutes to complete, before it finally starts running.
These three minutes are usually enough for me to open hackernews, reddit or some other news website, and... voilà, just lost 20 more minutes.
So...
What do you do during long compiles? Can you stay focused?
34 comments
[ 3.2 ms ] story [ 76.9 ms ] thread(I say that, but I usually look at HN...)
Even less helpful for you, I recently been able to use Go more frequently, so I have no more long compile times. :p
I remember having to work in Java codebases, and it was an absolute nightmare. Slow was the name of the game at all levels: slow to design anything, slow to write the code required, slow to navigate, slow to compile, slow to start, etc.
What are the nature of the changes you're making? Is it something you can write and debug in another (faster) language, then translate to the main language? If you were able to do it this way, then you wouldn't need as many compilations.
I know what you mean. For example, once you get used to working on JavaScript web apps that have almost instant live reload time on save it's very, very painful going back to apps with a 10s compile/reload time let alone over a minute.
The first thing that usually happens when there's a switch from Java to most other languages is a shrinking of the codebase. That is, it's not uncommon to go from 200,000 lines of code to 20-30,000.
If you still need the runtime speed Java offers, then that's one thing, otherwise, you can use some dynamically typed language like Python or Ruby. I suppose there's also Go, as many can't go without static types.
At the end of the day (especially if all compile times end up being similar), I'd prefer almost any other language over Java. Swift, Kotlin, Nim, Rust, Elixir, Crystal, Julia, D, C#, anything.
That's an issue with your toolchain.
> The first thing that usually happens when there's a switch from Java to most other languages is a shrinking of the codebase.
This is debatable and depends heavily on the langauge you're moving to. Further, even if true, it will definitely result in either a performance hit or a code complexity hit (heavy use of FP), or even both.
> I suppose there's also Go.
I haven't seen the numbers comparing compile times for equivalent Go and Java codebases, so I cannot comment on that. I'm assuming that Google's main goal with Go is to improve compile times relative to C++ and Java, which they extensively.
For example, I continually noticed long and painful compile times, but when I mention these things elsewhere, the responses say Java actually compiles very quickly.
There can be a runtime performance hit, but that's mainly if one switches to a language like Python or Ruby. That is, many compiled languages have runtime speeds similar to Java's.
As for equivalent codebase sizes, do you mean literal lines of code, or having them provide the same functionality? I look mainly at equivalent functionality, as 1000 lines in Python can easily be doing much much more than 1000 lines in Java.
You can probably search for comparisons (of Go and Java). In the beginning, Go was indisputably faster, but apparently they've introduced certain changes in the last year or so that's resulted in slower compile times.
Even with slower compile times, it's likely Go still compiles much faster than Java, while also resulting in a smaller, more manageable codebase.
Yes, but you won't get a 10x reduction in LOC as you claim. The point is that LOC reduction is usually not "for free".
> As for equivalent codebase sizes, do you mean literal lines of code, or having them provide the same functionality? I look mainly at equivalent functionality, as 1000 lines in Python can easily be doing much much more than 1000 lines in Java.
Functionality. Of course it can, but you sacrifice performance.
> Even with slower compile times, it's likely Go still compiles much faster than Java, while also resulting in a smaller, more manageable codebase.
From what I've seen of Go, you typically need more LOC to achieve the same task compared to Java.
Where have you seen Go codebases being larger than Java's (with both providing the same amount of functionality)?
> A 10x reduction isn't uncommon, unless the code wasn't doing much (or wasn't very large) to begin with. Either way, the reduction is quite significant.
I'll shoot your question back at you: do you have any specific examples to back your claim?
I don't like Java either to be frank, but I'm defending it because I'm not convinced by your original claim, i.e., Java has long compile times and is 10x more verbose.
At the moment it's pluralsight.com.
Our code's full test suite takes longer than 10 minutes and I still feel pretty productive when working at it. Actually we lint/transpile our JavaScript with Google Closure which is faster than webpack, but it still takes over 5 seconds which is more than our scala app takes in continous compile? Also I always see these cool JavaScript people, but I've never seen any real world app that still has a amazingly fast micro seconds cycle.
I used to read a book while waiting for compiles when I was in High School.
I have test suites that take 5-20 minutes to run and I do just about everything I can to cache data to bring that time down.
I feel your pain.