Re: [go-nuts] shebang support

[David Symonds‏]

It's come up multiple times before, and been rejected each time.

https://groups.google.com/group/golang-nuts/search?group=golang-nuts&q=shebang&qt_g=Search+this+group

[Andrew Pennebaker‏]

It's come up multiple times before, and been rejected each time.

https://groups.google.com/group/golang-nuts/search?group=golang-nuts&q=shebang&qt_g=Search+this+group

According to that list, Go shebangs are quite in demand. Can anyone give a good reason why shebangs should not be accepted into the grammar?

--

Cheers,

Andrew Pennebaker

www.yellosoft.us

[Dave Cheney‏]

go run exists for invoking short test programs. For anything else, the
intention is your code should be structured into packages and
commands.

Changing the grammer to allow # (which isn't a comment, or the word
`package`) at the start of a source file would entice people to solve
a problem which is already well covered by go run and go install.

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Andrew Pennebaker‏]

Python, Perl, Ruby, Lua, Node.js, and Haskell manage. Rust treats shebangs as comments. What's the problem?

https://github.com/mozilla/rust/issues/1772

[Jan Mercl‏]

On Sat, May 4, 2013 at 8:54 AM, Andrew Pennebaker
<andrew.p...@gmail.com> wrote:
> What's the problem?

Read [1] top to bottom with close attention to all Rob Pikes posts.

[1]:https://groups.google.com/d/topic/golang-nuts/iGHWoUQFHjg/discussion

-j

[Rémy Oudompheng‏]

On 2013/5/4 Andrew Pennebaker <andrew.p...@gmail.com> wrote:
> Python, Perl, Ruby, Lua, Node.js, and Haskell manage. Rust treats shebangs
> as comments. What's the problem?
>
> https://github.com/mozilla/rust/issues/1772

C and C++ do not. Java does not. I don't think C# has shebangs either.

What's the problem?

Rémy.

[Andrew Pennebaker‏]

Rob's a funny guy. "Category error", wooo, scary!

Compiler speed is not hurt by shebang support. Shebangs as comments at the beginning of files are O(1) to parse.

Compiled and interpreted are complementary, not exclusive. The secret behind fantastic interpreted languages like Erlang, Clojure, Haskell, and Ruby is that they're powered behind the scenes by solid compilers.

gorun is such an obvious improvement I'm surprised it's not in core Go already. I'll see myself out, it's rustx for me.

[Sebastien Binet‏]

Andrew,

On Sat, May 4, 2013 at 9:32 AM, Andrew Pennebaker
<andrew.p...@gmail.com> wrote:
> Rob's a funny guy. "Category error", wooo, scary!
>
> Compiler speed is not hurt by shebang support. Shebangs as comments at the
> beginning of files are O(1) to parse.
>
> Compiled and interpreted are complementary, not exclusive. The secret behind
> fantastic interpreted languages like Erlang, Clojure, Haskell, and Ruby is
> that they're powered behind the scenes by solid compilers.
>
> gorun is such an obvious improvement I'm surprised it's not in core Go
> already. I'll see myself out, it's rustx for me.

gorun isn't, but "go run" is.

-s

[Russel Winder‏]

All dynamic languages have this facility, on Posix compliant operating
systems at least(*), since #! is the magic number to the kernel to
perform interpreter startup. This allows Python, Perl, Ruby, Lua, etc.
to be used to create commands, and is why # is the comment character in
those languages. Note though that this also covers Groovy, JRuby,
Jython, etc. even though it involves a JVM because they have a compile
and run mode.

Although Groovy uses Java's // and /* */ comments it allows for the #!
line.

As you say Java does not support the feature but Scala, Kotlin, Ceylon,
Fantom, etc. do. So the modern thinking on the JVM platform is to allow
for a "compile and run" mode.

The interesting situation for this list is the native code languages. C
and C++ require ahead of time compilation for all commands and do not
support #! for source mode working. Haskell, D, Rust all do. You can
either use them in a fully precompiled mode or in a "compile and run"
one. This allows them to compete in areas where Python, Groovy, et al.
are currently the winners.

So it seems that the proprietors of Go wish to look backwards to the
toolchain ideas of C and C++ despite having some revolutionary ideas —
not all good, many of them actually very bad, despite two of them being
very good.

As to what the problem is: it is the way these threads develop and the
divisiveness that people seem to cherish. What I want to see from the
proprietors of Go to requests they are not going to follow up is not
"This is our language, we say how it goes, other programmers don't
matter.", but "We are not going to put this in the language, but if you
really want to here is what you can do." Be constructive rather than
confrontational.

In this case all that is needed is #! in the grammar as per Groovy,
Scala, etc. and a gorun instead of go run. The Go proprietors indicated
they wanted to create a community of support tool people and yet it is
being blocked in an area a lot of people want to go. This sounds like
dictatorship rather than community building.

The interesting point is whether goroutines are a sufficient pull to get
over all the problems of Go. Or whether D and Rust might actually get
some traction leaving Go the programming language used only in Google.


(*) C# is a Windows only language (caveat Mono) and so the whole #!
think is an irrelevance. Analogously F#.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

[Rémy Oudompheng‏]

2013/5/4 Russel Winder <rus...@winder.org.uk>:

> (*) C# is a Windows only language (caveat Mono) and so the whole #!
> think is an irrelevance. Analogously F#.

This is the whole point.

Languages are not "Windows-only". It does not make any sense.
Programming languages are designed to write programs independently of
operating systems.

Why would you include in a programming language syntax a knob which is
Unix-centric, non-portable between Unixen, and broken in a lot of
various ways? Especially in a programming language aiming to be usable
as "low-level" or for "system" things.

But well, all of this is already discussed a lot.

Rémy.

[Rémy Oudompheng‏]

On 2013/5/4 Russel Winder <rus...@winder.org.uk> wrote:
> All dynamic languages have this facility, on Posix compliant operating
> systems at least(*), since #! is the magic number to the kernel to
> perform interpreter startup. This allows Python, Perl, Ruby, Lua, etc.
> to be used to create commands, and is why # is the comment character in
> those languages. Note though that this also covers Groovy, JRuby,
> Jython, etc. even though it involves a JVM because they have a compile
> and run mode.
>

> [...]

>
> So it seems that the proprietors of Go wish to look backwards to the
> toolchain ideas of C and C++ despite having some revolutionary ideas —
> not all good, many of them actually very bad, despite two of them being
> very good.

I don't consider getting closer to POSIX to be a "forward" move. Go's
design had a lot of work to destroy and make a lot of legacy APIs and
habits finally disappear.

Why bring an old #! ghost of the past in the language?

Additionnally, on my French keyboard, "go run blah.go" is easier to
type than "./blah.go". Dot and slash need me to press the Shift-key.

Rémy.

[Anthony Martin‏]

You want to be able to run a go file directly
from the shell? Here you go:

$ cat a.go
// 2>/dev/null || go run $0; exit

package main

func main() {
println(42)
}
$ go run a.go
42
$ chmod +x a.go
$ ./a.go
42
$

There's your "shebang".

Anthony

[roger peppe‏]

only if you happen to be running the right shell.

[Anthony Martin‏]

roger peppe <rogp...@gmail.com> once said:
> only if you happen to be running the right shell.

Sure, it won't work with rc but it works with all
the common Unix shells: sh, bash, dash, ksh93, mksh,
pdksh, and zsh. Csh and tcsh need two characters
changed.

It takes advantage of the fact that these shells
will fall back to reading commands directly from
the file when exec(3) fails in the kernel (due
to the lack of #!).

It's a hack, though, no doubt.

Anthony

[Aram Hăvărneanu‏]

This reminds me of my favorite quine:

% touch quine
% chmod +x quine
% quine
% cat quine
%

--
Aram Hăvărneanu

[Alexandre Fiori‏]

I'd say the following reply from Andrew Gerrand is what makes more sense for not supporting shebang; from [1]:

"I still don't see how that would help much with bootstrapping. Are you saying we should rewrite everything in Go and ship Go compiler binaries for all platforms we want to support? Sounds like a lot of work for a very marginal gain, and is hardly a good argument for shebang support since it comes down only to the difference between  "./make.go" and "go run make.go", and that's a command you only type once.
Andrew"

[roger peppe‏]

the main point is that it won't work
if you do exec.Command("a.go").Run().
it's not really an executable in other words,
so not a viable alternative to the way
#! scripts are used with other languages.

not that i mind much.

[Andrew Gerrand‏]

Why speculate incorrectly as to the Go team's motivations, when you can read the several previous threads on this topic?

> As to what the problem is: it is the way these threads develop and the
> divisiveness that people seem to cherish. What I want to see from the
> proprietors of Go to requests they are not going to follow up is not
> "This is our language, we say how it goes, other programmers don't
> matter.", but "We are not going to put this in the language, but if you
> really want to here is what you can do." Be constructive rather than
> confrontational.

We are not going to put this in the language, but if you really want to here is what you can do

  go get launchpad.net/gorun

and use "#!/bin/env gorun" in your scripts. Of course, the usual portability concerns of shebangs must be considered.

> In this case all that is needed is #! in the grammar as per Groovy,
> Scala, etc. and a gorun instead of go run. The Go proprietors indicated
> they wanted to create a community of support tool people and yet it is
> being blocked in an area a lot of people want to go. This sounds like
> dictatorship rather than community building.

The Go language pushes a lot of responsibilities onto tools and libraries. This is a design choice. The existence of gorun proves that it is unnecessary to add shebang support to the core.

The Go project has hundreds of contributors, and more committers from outside Google than within. Yes, the core team gets final say in important matters, but usually it comes down to consensus among the people who have spent the most time working on and with the language. The core group of contributors (from inside and outside Google) regularly debate important issues on the public mailing list, and all opinions are considered. It works rather well.

However, if new people come to Go and say "give me shebang support in the core or I won't use it!" then I am happy for them to walk away unsatisfied. We have spent a lot of time in other threads explaining the rationale for our decisions. At some point you've got to concede that people disagree sometimes and that is a perfectly fine situation.

> The interesting point is whether goroutines are a sufficient pull to get
> over all the problems of Go. Or whether D and Rust might actually get
> some traction leaving Go the programming language used only in Google.

D and Rust have very different goals. (Just ask their designers.)

If you think goroutines are all that Go has to offer, then you must have a very shallow understanding of the project. Do you write Go code?

I can't speak for all Go users, but most that I have encountered appreciate it for  the restraint exercised by its designers. (The very quality that you malign here.) It is the overall combination (and sometimes absence) of features that appeals to me. Less is more.

Andrew

[Russel Winder‏]

On Sat, 2013-05-04 at 10:18 +0200, Rémy Oudompheng wrote:
[…]

> Why would you include in a programming language syntax a knob which is
> Unix-centric, non-portable between Unixen, and broken in a lot of
> various ways? Especially in a programming language aiming to be usable
> as "low-level" or for "system" things.

The "knob" is certainly Posix-centric, but why not make use of it on
those systems that support it? What is the non-portability? Why is it
broken?

"Low-level" and "system" are not an issue here.

> But well, all of this is already discussed a lot.

Indeed. Is there any chance of moving to agreement or will it always be
conflict?

[Russel Winder‏]

On Sat, 2013-05-04 at 10:24 +0200, Rémy Oudompheng wrote:
[…]

> I don't consider getting closer to POSIX to be a "forward" move. Go's
> design had a lot of work to destroy and make a lot of legacy APIs and
> habits finally disappear.

Go certainly has a lot of good "break the mold" features, I believe that
this is not an issue in this case.

> Why bring an old #! ghost of the past in the language?

Exactly because it is not a ghost of the past, it is a feature of the
operating systems we have.

> Additionnally, on my French keyboard, "go run blah.go" is easier to
> type than "./blah.go". Dot and slash need me to press the Shift-key.

Now that is a serious issue, just not one that is a problem for UK
keyboards. ;-)

[Jan Mercl‏]

On Mon, May 6, 2013 at 6:17 PM, Russel Winder <rus...@winder.org.uk> wrote:

Let's check what Wikipedia[1] has, among other things, to say about the subject:

----
Under Unix-like operating systems, when a script with a shebang is run
as a program, the program loader parses the rest of the script's
initial line as an interpreter directive; the specified interpreter
program is run instead, passing to it as an argument the path that was
initially used when attempting to run the script.
----

Problem #1: 'Unix-like operating systems'. Go aims for more than that.

Problem #2: 'script with a shebang'. Go is not a scripting language.

Problem #3: 'the specified interpreter program is run instead'. Go has
no interpreter, only a compiler and linker. Using that combo as an
"interpreter" is a waste of resources.

[1]: http://en.wikipedia.org/wiki/Shebang_(Unix)

-j

[Russel Winder‏]

On Sun, 2013-05-05 at 11:05 -0400, Andrew Gerrand wrote:
[…]

> We are not going to put this in the language, but if you really want to
> here is what you can do
>
> go get launchpad.net/gorun
>
> and use "#!/bin/env gorun" in your scripts. Of course, the usual
> portability concerns of shebangs must be considered.

That works for me.

[…]

> our decisions. At some point you've got to concede that people disagree
> sometimes and that is a perfectly fine situation.

Agreed. This does not however stop the debates being constructive, as
your response has been here.

> > The interesting point is whether goroutines are a sufficient pull to get
> > over all the problems of Go. Or whether D and Rust might actually get
> > some traction leaving Go the programming language used only in Google.
>
> D and Rust have very different goals. (Just ask their designers.)

Indeed. D I know well, Rust I have just managed to get compiled.
However, I will likely still just use Go for the projects I have.

> If you think goroutines are all that Go has to offer, then you must have a
> very shallow understanding of the project. Do you write Go code?

This is probably not the place to go into detailed debate in this, to
boring for the members of the list. goroutines is not the only feature
of Go for me, but it is the one that makes me deal with the stuff I
really don't like about Go. Yes, I do write Go code, nowhere near as
much as many people here though.

> I can't speak for all Go users, but most that I have encountered appreciate
> it for the restraint exercised by its designers. (The very quality that
> you malign here.) It is the overall combination (and sometimes absence) of
> features that appeals to me. Less is more.

What this is leading to though is that the plethora of "3rd party"
packages, good in most senses, leads to a problem for new users deciding
which one.

I wonder if https://code.google.com/p/go-wiki/wiki/Projects needs to be
more actively curated. An anology is with the Emacs 24 package
management: there is a distributed set of packages (ELPA), MELPA an
actively curated list, and Marmalade which is user uploaded packages.

I suggest that "SCons Go Tools" and "goscons" may no longer be useful. I
think both are now stale projects.

[Andrew Gerrand‏]

On 6 May 2013 09:42, Russel Winder <rus...@winder.org.uk> wrote:

I wonder if https://code.google.com/p/go-wiki/wiki/Projects needs to be
more actively curated. An anology is with the Emacs 24 package
management: there is a distributed set of packages (ELPA), MELPA an
actively curated list, and Marmalade which is user uploaded packages.

I suggest that "SCons Go Tools" and "goscons" may no longer be useful. I
think both are now stale projects.

If you want to contribute, the Projects page explains how.

Andrew

[Ross Light‏]

As the developer of SCons Go Tools, I can confirm it is stale.  It was meant for a time before "go build".  I use make and bash for anything surrounding a Go project (i.e. resource zipping, code generation, Javascript minifying, etc.), or waf in some very particular circumstances.

Ross Light | Software Engineer | li...@google.com | 661-375-7677

[StalkR‏]

You can achieve executable ./example.go without shebang if your OS helps you.
I once got this from the list, for Linux/Debian:

apt-get install binfmt-support

cat > /usr/local/bin/gorun << EOF
#!/bin/sh
/usr/bin/go run "\$@"
EOF

chmod 755 /usr/local/bin/gorun

update-binfmts --install go /usr/local/bin/gorun --extension go