Hacker News Reader

Comment by NateDad | Hacker News Reader

^^ what he said. Definitely high on the list. I debated just making this code build the executable, but given that they end up a couple megs each, and that go run is quite fast (~120ms).. I figured the default of just writing the file would be fine.

View on HN

I'm fairly sure that "go run" does build the executable, it just deletes it afterwards (or it generates the file in memory).

Sorry. What I meant was that I considered generating the binary and leaving it around, but instead I generate just the code and rely on go run to create and then delete the binary.

My point was that go run being "fast enough" doesn't really mean anything -- it's precisely the same speed as go build. :P

By fast enough, I mean this:

The tradeoff between go build and go run is that go build makes subsequent runs faster, but it creates a somewhat large binary that takes up disk space.

So, when I say go run is fast enough, I mean that the speedup of using go build is not big enough to justify the extra disk space required to store those binaries, compared to the speed hit we get from using go run each time (IMO of course).

I see what you mean. However in a situation where you might be running the command many times (like in a script that goes through data or something) then it might make sense to precompile it. The compile time would add up fast if it was being run hundreds/thousands of times.

And this is why I'm intending to add a -c flag (and maybe a global config of some sort) to tell gorram to use a compiled version instead.

Reply on news.ycombinator.com