Go scripts
Archos
The use of Go scripts is especially useful:
* During learning
* For administration issues
* Boot init of operating systems
* Web developing; by example for the routing
* Interfaces of database models
== Installation
$ git clone git://github.com/kless/goscript.git
$ cd goscript && ./Install.sh && cd -
== Operating instructions
Insert at the first line of the Go Script:
#!/usr/bin/env goscript
And set its executable bit:
$ chmod +x file.g
Archos
information:
https://github.com/kless/goscript
Archos
accessed from different architectures and/or systems.
I'm thinking in changing goscript to a shorter name like "g" or "go-"
Aleksandar Radulovic
This is quite interesting, I'm going to give it a try.
Why would you want to shorten the name? Users can always make an alias
if they want it shorter - the name goscript is very explicit (and
good, imho). Erlang uses "escript" and I think that's not explicit
enough..
Good job!
alex.
--
a lex 13 x
http://www.a13x.info
Archos
starting to change its name. It will remain "goscript".
Serge Hulne
I might be mistaken, but I think that an interpreted version of Go
could be more adapted to build web applications or web development
frameworks than the compiled version of Go.
The reason why I believe so, is that most robust web frameworks (e.g.
written in Python, like Djano, Pylons,web2py etc ...) seem to rely on
the fact that the underlying scripting language is interpreted, in
order to:
1) Load new "controllers" (scripts mapped to an URL) on-the-fly,
without having to restart the server.
2) Modify existing scripts without having to restart the server.
3) Protect the web application against the crash of an isolated script
running on the server (conversely it seems that if one uses web.go, an
unrecoverable exception in any of the controllers will make the whole
server crash, since the whole server is just one binary executable).
and again, perhaps I am mistaken in believing that an interpreted
version of Go would be more suited for web development.
Yet, I would be interested to know what other users of Go think about
the subject.
Serge.
Archos
the languages that can.
The magic behind of mod_wsgi (Apache module widely used to serving
python web applications) is looking at the files to see if any of them
has changed (I'm supposed that using Inotify) to restart the server.
The same for the django server that can be used during the django
development.
As I said here[1], the hot code loading could be added into a compiled
language and would be awesome to use in web frameworks.
[1]: http://groups.google.com/group/golang-nuts/browse_thread/thread/1ef278b571f79028/
Serge Hulne
or autonomously, as stand-alone web servers.
In the latter case, they retain the ability to load scripts on-the-
fly.
Therefore, I am not sure that this ability is necessarily always
linked to mod_wsgi.
Perhaps they use the possibility to call the python interpreter from
within a python script (or something like that :scripts running
scripts).
Serge.
On Dec 8, 3:18 pm, Archos <raul....@sent.com> wrote:
> Serge, Python neither Ruby can do hot code loading. Erlang is one of
> the languages that can.
>
> The magic behind of mod_wsgi (Apache module widely used to serving
> python web applications) is looking at the files to see if any of them
> has changed (I'm supposed that using Inotify) to restart the server.
> The same for the django server that can be used during the django
> development.
>
> As I said here[1], the hot code loading could be added into a compiled
> language and would be awesome to use in web frameworks.
>
Aleksandar Radulovic
My opinion is, especially after the experience of doing web
development with Java, Python, and Erlang, that nothing beats rapid
web development with interpreted (and dynamic) languages.
Hot-reloading is a huge time-saver (technically, it's not really a
hot-reload, as the dev. server in python, for example, monitor file
changes and restarts the server if it sees a change; due to the fact
that it's so fast to start up, it's practically hot-reloading :).
However, in production, it's widely recommended to turn this feature
off and to "preload" your applications. This is where Goscript and
compiled Go apps could fit fantastically well - power of rapid
development with compiled code in production. I would think there's a
use for that.
-alex
--
André Moraes
Any changes that your program support .goscript instead of simple .g files?
In Gedit the file ".g" seems to belong to another language (GAP ->
http://www.gap-system.org/Overview/overview.html)
I am working on a simple task automation tool for Go and goscript is
just what I was missing.
I already made some minor changes to go.lang syntax file to handle the
first line of goscript.
Will send you a pull request sonn.
Thanks,
--
André Moraes
http://andredevchannel.blogspot.com/
Archos
have to be greater than 3 or 4 characters.
I'm open to any other alternative. What about ".gos"? It hasn't caught
by another application[1]
[1]: http://www.fileinfo.com/list/g
André Moraes
--
André Moraes
http://andredevchannel.blogspot.com/
Archos
Aleksandar Radulovic
Slightly offtopic, gos means soda in Icelandic. Not particularly
interesting, just thought it was kind of funny.
Ideally, I would like to see .go being used, but that would require
changing the compiler (ie. to ignore the hashbang at the top), which
probably wouldn't be such a marvelous idea. The .gos is good, I
guess..
-alex
--
Archos
first line of a Go source file, I think that it would be helpful to
have a different extension for Go scripts so they can be easily
distinguished from "generic" Go source files, no?
Aleksandar Radulovic
-alex.
--
Serge Hulne
the regular go extension).
This is what tinyc does: it compiles C files on-he-fly and acts as a C
interpreter.
With tinyc (and with python as well) you have two options:
1. Embed the path to the interpreter on the first line (also as a
comment) and make the file executable with chmod, or
2. call the interpreter explicitly: like : python hello.py or tinyc
hello.c (in which case the first line of comment is not necessary)
If goscript could act on regular go file (and I don't see why not in
case 2.) then it would be even more useful because one could use the
existing tools (eclipse, Vi, etc...) to develop indifferently scripts
or binary executables (or script in a first instance, for RAD, and
compile the application later when it is ripe).
Serge.
André Moraes
The use may call 6g on a script file and that will not work (since the
first line will be the #!), also, some automated tools scans the
entire directory looking for .go files and checking dependency and
other stuff (which doesn't make much sense in scripts).
The ".g" was the best choice, but it is already used as mentioned before.
Serge Hulne
> The use may call 6g on a script file and that will not work (since the
> first line will be the #!), also, some automated tools scans the
> entire directory looking for .go files and checking dependency and
> other stuff (which doesn't make much sense in scripts).
Moreover, I am not suggesting that there is a trivial solution.
Still, I guess it ought to be feasible, since it appears to work in
the case of tinyc : it can be used alternatively as a compiler and as
an interpreter (on the *same* files).
Again, I am not trying to suggest that it would be necessary for the
purpose of having a Go interpreter, I am merely saying that it would
be extremely handy to be able to either :
- compile and run
- alternatively run directly a script by invoking the interpreter from
the command line "goscript hello.go" (without the initial comment,
which is in essence not necessary when the interpreter is explicitly
specified on the command line).
What is the contra:
- One cannot tell if it is a script or a regular source file (so
what ?)
What are the pros:
1. - When doing RAD, When learing / experimenting / (or when possibly
scripting a web application) etc .., there is no need to write a
makefile / invoke 6g, 6l, to compile and to create an executable.
2. - The decision to compile can be postponed (or abandoned if deemed
unnecessary).
3. - The available tools do not need to be all duplicated (godoc,
gofmt, vi related files, all syntax highlighting files, etc ...)
NB: The problem with the initial #! appears only if one wants the
scripts to be stand-alone (and to point to their specific
interpreter), it does not appear if one specifies the interpreter on
the command line (cf. Python and tinyc)
Serge.
Archos
projects. See here[1], in "Building Tools".
Anf for the issue of syntax highlighting could be easily solved if the
bang-sharp line were added to the actual Go syntax files, then it's
added another extension (.gos) for that same syntax.
[1]: http://godashboard.appspot.com/project
André Moraes
https://github.com/andrebq/chimp
I just commited the code yesterday, it uses Archos goscript.
Don't have to many automated task, but has one for compiling and
linking things (see the samples).
Very very very easy to use.
Serge Hulne
> I think that you're looking for is an tool to building automatically
> projects. See here[1], in "Building Tools".
>
http://bellard.org/tcc/
It says in particular:
"C script supported : just add '#!/usr/local/bin/tcc -run' at the
first line of your C source, and execute it directly from the command
line."
The extension of the original C source does not have to be modified,
which is extremely advantageous, because the source can use all
standard C development tools without any modification.
Serge.
Archos
that it was good to have separated both types of files for, as I said,
to know "visually" if it's a script.
If there is more people that they think it's better to use the same
extension, then I have not any problen in change it.
And, looking at directory "/etc/init.d/", it can be seen that those
bash scripts have not the extension ".sh". So it could be removed the
checking of extension in goscript. Ok?
André Moraes
Did you have in mindo how to use goscripts to script go programs?
Reading a little abou tinyc they have libtcc library to make dynamic
code generation.
Maybe wrapping goscript in some lib and working a little to make easy
to communicate with another go process will be very nice (net channel
maybe).
Serge Hulne
> If there is more people that they think it's better to use the same
>
Come to think about it there is a third alternative:
- provide a command line option (a "switch") to tell the interpreter:
"treat this (resp. those) file(s) as a go script (regardless of the
extension)".
Something perhaps along the line:
goscript -go hello.go
as opposed to:
goscript hello.gos
of course, it would also allow, as a side effect for:
goscript -go hello
This way, one gets the best of both worlds !
(which might prove useful in the future in cases where a script is
expected to have a certain given predetermined name)
I for one would definitely appreciate this flexibility.
Last but not least, I sincerely believe that allowing for different
extensions (in particular for ".go") can only make goscript more
popular.
Personally, I think that goscript is a really great idea, and that
goscript itself will certainly contribute to the popularity of Go for
the following reasons:
- It might win the heart of python fans.
- It is very useful, when learning, for quickly trying out lots of
examples without toil.
- It follows the Go mantra: it is simple and fun.
- and again, I think it is likely to win the vote of web developers
which like to make a lot of small changes here and there without
recompiling the whole stuff.
- it could be handy for writing plugins (as Go scripts) for a compiled
application, itself written in Go (not unlike lisp for Emacs or Python
for Blender, but definitely handier).
Yours sincerely,
Serge.
⚛
> If you are looking for a tool to build projects, take a look at:
>
> https://github.com/andrebq/chimp
give to Go some automation tools". It does *not* seem to be able
automate anything.
Archos
By now, that people choose the extension that they want to use, to see
if it is ".go".
Anyway, goscript will can to follow running scripts without extension
which is cool to use in system scripts.
André Moraes
I just cited because that is the goal of the project.
And by "automate" i mean: write the task once and then run it as many
times you want.
Tim Harig
> Personally, I think that goscript is a really great idea, and that
> goscript itself will certainly contribute to the popularity of Go for
> the following reasons:
> - It might win the heart of python fans.
Here and I thought that Go's advantage over Python *was* that it is a
systems language which generates native code rather then requiring an
interpreter.
> - it could be handy for writing plugins (as Go scripts) for a compiled
> application, itself written in Go (not unlike lisp for Emacs or Python
> for Blender, but definitely handier).
The problem with builtin scripting languages is that you end up having to
use whatever language the application developer happens to like. Much
better is to provide a scripting interface that *any* language can interface
with. Nothing procludes a fully compiled language from leveraging such an
interface.
André Moraes
> systems language which generates native code rather then requiring an
> interpreter.
Goscript don't make Go interpreted, it compiles go on-the-fly
>> - it could be handy for writing plugins (as Go scripts) for a compiled
>> application, itself written in Go (not unlike lisp for Emacs or Python
>> for Blender, but definitely handier).
>
> The problem with builtin scripting languages is that you end up having to
> use whatever language the application developer happens to like. Much
> better is to provide a scripting interface that *any* language can interface
> with. Nothing procludes a fully compiled language from leveraging such an
> interface.
Agreed, the scripts written in Go should be started as different
process and something like netchan used to coordinate the
communication.
In *UNIX systems starting process isn't really a big deal and the
isolation is much better than many scripts running on the same
process.
That is probably the best way to script Go something like:
https://github.com/nsf/gocode
Serge Hulne
> process and something like netchan used to coordinate the
> communication.
> In *UNIX systems starting process isn't really a big deal and the
> isolation is much better than many scripts running on the same
> process.
> That is probably the best way to script Go something like:https://github.com/nsf/gocode
case based on web.go.
Thanks for the explanations and the suggestions !
Serge.
Carl
There is a huge amount of systems management software out there, cmdb
and so on, that is currently written in other scripting languages
such as Python. If GO can provide an elegant high-performance compiled
solution that looks like a scripting language than this is certainly a
proposition which will find a lot of interest in the long term.
Is there a Windows implementation? Will there be one?
Archos
used there:
+ path*: I think that there is not problem about it
+ the time of a file: [1]
+ os.Stat[2]
+ Related to execute programs[3]
A Windows user should check if those functions work there, but I think
that if there is any problem, it will be with the function related to
execute programs.
Then, there would have to see as the scripts are executed/called in
Windows.
[1]: https://github.com/kless/goscript/blob/master/cmd/goscript.go#L138
[2]: https://github.com/kless/goscript/blob/master/cmd/goscript.go#L186
[3]: https://github.com/kless/goscript/blob/master/cmd/goscript.go#L194