
Gorram: go run for any go function - ingve
https://github.com/natefinch/gorram#gorram-
======
biztos
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.

~~~
NateDad
Thanks!

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

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

~~~
blakecaldwell
Who cares about non-Firefly fans? :)

~~~
yunhooho
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.

~~~
blakecaldwell
It's a joke - hence, the smilie.

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

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

Pretty cool.

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

------
djhworld
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

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

~~~
jerf
It looks like the current "Somedays" come out to that:
[https://github.com/natefinch/gorram/projects/1](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.

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

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

~~~
NateDad
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.

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

~~~
NateDad
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).

~~~
artursapek
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.

~~~
NateDad
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.

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

If not, then neater.

~~~
NateDad
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.

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

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

~~~
wyldfire
I think it's a Firefly reference.

~~~
viewer5
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!"

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

~~~
NateDad
TIL :)

