Hacker News Reader

Comment by jerf | Hacker News Reader

It looks like the current "Somedays" come out to that: https://github.com/natefinch/gorram/projects/1

The .go files it generates for 'go run' are stored in $HOMEDIR/.gorram/$PACKAGE/$FUNCTION, a "go build" from there produces a standard executable. At the moment it seems to directly invoke "go run" with no ability to change that.

View on HN

^^ 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.

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