Gorram: go run for any go function | Hacker News Reader

Gorram: go run for any go function

github.com

162 pointsingve29 comments

This is cool, and reminds me of the wide, wacky world of Perl one-liners. But with an interesting twist.

I used to use a lot of one-liners, but as time passed and I worked with more different languages, I came to prefer having things "programmized" and available either through BASH functions/aliases, or in my handy "tools" directory.

What I like about Gorram is that it should be trivial to make it turn the one-liner into a standalone utility program.

So: try a one-liner in Gorram and if it's useful, run it again with a flag, say "-s FILE" and it saves the compiled program for you.

I guess that's a feature request. :-)

Also, I really like the "STDIN or file" guessing.

Thanks!

I would expect -c -o to do what you expect.... which is not yet implemented but will be at some point :)

Great name, great Teller quote. (Though that picture is going to be weird for not-firefly fans)

Also seems like the heuristics used are simple enough to hold in your head - hope it stays that way.

Who cares about non-Firefly fans? :)

That's a really weird thing to say. Not everyone is into the same TV shows as you and that doesn't mean you shouldn't care about them.

It's a joke - hence, the smilie.

This is a typical response from a non-Firefly fan. :)

I really do what the heuristics to be very natural... there's nothing I hate more than having to look up how to use something.

Another thing I intend to do quite soon is add usage for a particular function, so you don't have to guess how gorram will interpret it.

This reminds me of powershell's ability to leverage .net assemblies.

Pretty cool.

Very nice project. It would be cool if this was an actual feature of `go run`.

This is cool.

Can't help but think the examples don't really demonstrate anything new though, in the sense that there are existing tools for manipulating json (jq), generation SHA digests etc

I have a small go script I wrote in my toolbox that reads lines from stdin, puts them into a map and increments a counter each time that line is seen (sort like `sort | uniq -c` but less memory efficient in some situations.

The tedium with that code is having to write the bits to read from stdin etc, so I can imagine using this to 'auto generate' that bit for me

Really interesting idea. Is there a way to compile one of these commands into single portable a binary?

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.

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

Neat. Not a gopher, so does this only work with pure functions that only reference other pure functions?

If not, then neater.

Um... sort of? Not really pure-pure. The functions can do whatever they want - download from the internet or whatever...

And when you get into closures or use complex initializations.... a lot can happen with a single function call.

This is really neat - anyone know of a python equivalent?

What is it with making projects sound like STIs these days?

I think it's a Firefly reference.

It is; Firefly's version of the curse "goddamn". It's set in the far-flung future, so they had some fun with lingual evolution, most notably incorporating bits of Chinese. "Gorram" evolved from "goddamn" the same way "zounds!" evolved from "God's wounds!"

A form of it was actually somewhat popular in the 1800s. It was used by Dickens and possibly coined by him.

TIL :)

"My days of not taking you seriously are certainly coming to a middle."

"Preacher, don't the Bible have some pretty specific things to say about killin'?"

"Quite specific. It is, however, somewhat fuzzier on the subject of kneecaps."

Reply on news.ycombinator.com