What application can you really code in Go?
Vincent Risi
code in Go. To me it is still just such a toy with a very narrow
outlook, which seems to beggar the question of it being a system or
systems language. I could not see an operating system being written in
it, let alone a functional service. Even for command line utilities it
lacks sadly. When I first saw java I could see the application even
though it was very very immature. I was hopeful for a while that a new
interesting programming language was being created but this appears to
not be the case. I will look back in every now and then but I
personally would rather code in straight C rather than use Go as it
currently stands.
andrey mirtchovski
Jessta
> I cannot seem to consider any application or utility I would want to
> code in Go.
> To me it is still just such a toy with a very narrow
> outlook, which seems to beggar the question of it being a system or
> systems language. I could not see an operating system being written in
> it, let alone a functional service.
It's a systems programming language, not a language for developing
operating systems in.
It's for writing servers and such.
> Even for command line utilities it
> lacks sadly.
What do you mean by this? what do you need for writing command line
utilities that isn't doable in Go?
>When I first saw java I could see the application even
> though it was very very immature. I was hopeful for a while that a new
> interesting programming language was being created but this appears to
> not be the case. I will look back in every now and then but I
> personally would rather code in straight C rather than use Go as it
> currently stands.
>
Go is probably good for writing most of the stuff you'd write in C.
It does seem strange that you bothered to post to the list that you
don't want to use Go.
Do you want us to convince you to use it?
- jessta
--
=====================
http://jessta.id.au
adam_smith
in Go. The sort of programs I usually write in python and ruby. My
experience was very positive. The ease of development was not far from
that of python I felt. I wrote a it about it here:
http://loadcode.blogspot.com/2009/11/first-impressions-from-go-programming.html
I would never consider writing these kind of utilities in C or C++.
Then you have to hunt down and install third party libraries to deal
with string processing, command line parsing etc. With Go the
advantage is much the same as with python, ruby etc in that you get a
fairly large amount of functionality with the standard install.
A part from that I have started wondering whether Go might serve well
as an alternative for a 2D game engine I develop. It is in C++ and Lua
at the moment but I am rewriting it to C and Lua (due to performance
needs and desire for some more simplicity). Basically the game logic
is defined in Lua and rendering, collision detection etc is done in C+
+.
The reason why I see Go as potentially useful is that it can offer
many of the same advantages as a script language such as lua. It
compiles really fast and you could use the Go interpreter to write
code in a console at runtime for the game just as you would do with a
script language. I looked at some of the algorithms I wrote in Lua
which were very clunky to do in C++ and Go's terseness, closures etc
means I can write it almost as elegant as in Lua. I give some examples
of that here: http://loadcode.blogspot.com/2009/12/go-vs-java.html
that is mainly a rant against Java and its verboseness but I do use
some part s from my game engine written in Lua to demonstrate how it
could be done in a similar manner in Go.
I can see a lot of reasons why might become a big language within the
game programming world. Haven't thought much about that before you
asked this question but now you got me thinking... ;-)
Qtvali
* In Java, one often ends up using Queues (locked, blocking ones) for
communication between two objects. Mostly that is because when you
have two objects, which are meant to be separated, you don't want to
make any shared locks and mutexes, but want some simple guarantee that
they wont go into locks etc. Queues take a lot of memory, create
objects etc. when you often want just to pass some pointers or simple
structures. Also, Queues normally make up a situation, where you have
some number of unnecessary objects in memory.
* Java threads are made in such way that you can't have many of them
at once - you have to do a lot to keep all your logic in small number
of threads. Mostly different kinds of server frameworks - whole
separate systems - are doing it for you, ending up with a lot of
overhead to avoid some other overhead.
* Java network IO is also inferior to Go-s as far as I know - because
of the complexity it needs to make it scalable, again.
* Java uses far more memory for many kinds of structures as I have
understood here.
On the other side, there are still advantages of Java over Go. This is
not yet known, which one is better in overall - taking into
consideration that one needs to finish things so that all aspects are
implemented and it's enough to have a few bottlenecks (things, which
are needed in bigger project and very hard to achieve in given
language) to consider other platforms. Some 10% of code can take 90%
of development time just because of what it is doing needs very
complex design in that language - in case there are other languages,
where it can be done more easily, this matters in choice, it makes up
90% of final decision in this languages evaluation. And often those
things need some fancy feature, which is used once per thousands of
lines, but still used. This means - only simplicity is not an
objection, there is also some need for those complex features to exist
(even if noone uses them so much to make any code more complex),
because there are some complex problems - making up 1% of some big
project -, which need those features used in black box. Inline
assembly support (not that it has to be inlined in your code, but such
which wont create function call overhead) and some generics support
(to create some really complex algorithms only once for all data types
without loosing speed) plus reflection (to allow some things not
exactly implemented in language) will add to that - as you can do
anything in assembler as long as it's small and any abstraction with
metaprogramming and reflection given they are powerful enough. That is
- assembler itself is complex for many people, who haven't read the
manual, but it makes some things possible; metaprogramming (as
templates or some form of macros and reflection) is complex, but makes
some things really simpler, especially for users of libraries.
Michael Hoisie
networking libraries, and it's very fast for serving web requests:
http://github.com/hoisie/web.go
- Mike
Tom Lieber
> I cannot seem to consider any application or utility I would want to
> code in Go.
I found it to be very, very nice for a multi-threaded server I needed
to build. Not supporting callbacks from C is killing me, though.
--
Tom Lieber
http://AllTom.com/
Vincent Risi
without being given the possibility of circumventing the termination.
Whoops I crashed with the equivalent of a stupid 0x8NNNNNNN return
code. Like relying on errno in the bad old C code. So again why would
I want to use Go to write service providers. With java I get great
service providers that run on any platform. C# gives a very similar
set of services. C++ is really good for this and the coroutine aspect
is very easily provided by library. I think I will examine Scala next.
On Jan 2, 6:26 pm, Tom Lieber <t...@alltom.com> wrote:
befelemepeseveze
> I found it to be very, very nice for a multi-threaded server I needed
> to build. Not supporting callbacks from C is killing me, though.
You can have C callback(s) if this mechanism fit your needs:
---- Makefile
# Copyright 2009 The Go Authors. All rights reserved.
# Use of this source code is governed by a BSD-style
# license that can be found in the LICENSE file.
include $(GOROOT)/src/Make.$(GOARCH)
TARG=bind
CGOFILES=\
bind.go
CLEANFILES+=main
include $(GOROOT)/src/Make.pkg
%: install %.go
$(QUOTED_GOBIN)/$(GC) $*.go
$(QUOTED_GOBIN)/$(LD) -o $@ $*.$O
---- bind.go
package bind
/*
#include <assert.h>
#include <stdint.h>
#include <unistd.h>
int rpipe, wpipe;
uint8_t callback(uint8_t data) {
uint8_t buf, n;
n = write(wpipe, &data, sizeof(data));
assert(n == sizeof(data));
n = read(rpipe, &buf, sizeof(buf));
assert(n == sizeof(buf));
return buf;
}
*/
import "C"
import "os"
func F(data byte) byte { return byte(C.callback(C.uint8_t(data))) }
var rpipe, wpipe *os.File
var Handler func(byte) byte
func dispatch() {
var buf [1]byte
for {
n, err := rpipe.Read(buf[0:])
if err != nil || n != 1 {
panic()
}
buf[0] = Handler(buf[0])
n, err = wpipe.Write(buf[0:])
if err != nil || n != 1 {
panic()
}
}
}
func init() {
r, w, err := os.Pipe()
if err != nil {
panic(err)
}
C.wpipe = C.int(w.Fd())
rpipe = r
r, w, err = os.Pipe()
if err != nil {
panic(err)
}
wpipe = w
C.rpipe = C.int(r.Fd())
go dispatch()
}
---- main.go
package main
import "bind"
func handler(b byte) byte { return 2 * b }
func main() {
bind.Handler = handler
println("Callback bare bones", bind.F(1), bind.F(11), bind.F(111))
}
----
20:53 myname@tux64:~/prj/go/lab/callback$ make main && ./main
CGOPKGPATH= /home/myname/bin/cgo bind.go
/home/myname/bin/6g -o _go_.6 bind.cgo1.go _cgo_gotypes.go
/home/myname/bin/6c -FVw -I"/home/myname/go/src/pkg/runtime" -D_64BIT
_cgo_defun.c
rm -f _obj/bind.a
/home/myname/bin/gopack grc _obj/bind.a _go_.6 _cgo_defun.6
cp _obj/bind.a "/home/myname/go/pkg/linux_amd64/bind.a"
gcc -m64 -fPIC -O2 -o bind.cgo2.o -c bind.cgo2.c
gcc -m64 -o _cgo_.so bind.cgo2.o -shared -lpthread -lm
cp _cgo_.so "/home/myname/go/pkg/linux_amd64/bind.so"
/home/myname/bin/6g main.go
/home/myname/bin/6l -o main main.6
rm bind.cgo2.c
Callback bare bones 2 22 222
20:54 myname@tux64:~/prj/go/lab/callback$
----
In a real app it would be necessary to implement some protocol over
the pipes and based on it the dispatch() would call not just a single
handler only,
but I believe you already got the idea.
RogerV
> service providers that run on any platform. C# gives a very similar
> set of services. C++ is really good for this and the coroutine aspect
> is very easily provided by library. I think I will examine Scala next.
I've spent a good part of this decade writing code in a Java app
server that deals with all manner of situations where the desire was
to have robust code that could run 24/7 and recover from adverse
situations automatically as much as possible. To give an idea: serial
devices such as scale weight readers, in-pavement vehicle loop
sensors, gate arms, signal lights, OCR recognition systems, RFID
scanners, VoIP, JMS message bridge to Oracle AQ, etc., etc. Many of
these beans were written as custom JMX mbeans hosted in a JBoss JEE
app server. This means all code runs in one JVM process.
Java exception handling does indeed help in terms of writing custom
mbean code that can recover from adverse situations. Our software
systems have pretty darn good uptime consider the diversity of mbeans
thrown in together.
In looking at Go, it was apparent that it would not be possible to
write an app server with a similar architectural approach as might be
typical of Java or Scala.
First of all, am not even sure if it's possible to write a runtime
loadable module that is analogous to Java beans that are loaded into a
JEE app server. As far as I can tell, Go appears to support static
linking only of all Go code into a monolithic executable. (I actually
like and prefer this approach for some categories of software
programs.)
So to do a Go app server, one would need to control all software that
is linked into the resulting executable.
Secondly, to deal with auto-recovery from panic fault inducing
situations, it looks like perhaps the approach of a parent process
acting as a watch dog over child processes could be utilized. On any
unix/linux/posix/Mac-OS-X OS it is straightforward to code such using
the fork() call.
So in the end I think it would be possible to use Go to code app
servers full-filling the purposes of what I've described - is just
would go about the architecture differently and also have different
constraints as to code governance of what is (or can be) pulled into
an app server build.
BTW, you're going to find Scala to be a considerably more complex
language to learn than Go, but it too is a very interesting language.
There's a lot about the fundamental simplicity of Go that I continue
to find attractive.
Julian Morrison
nicer not to need it.
I wonder if it would be possible to use Go as an extension language?
By this, I mean: having a program which allows users to add code on
the fly (example: a MUD), and this is done by creating a temp file,
compiling it into object code, and dynamically linking it into the
running main program. Go is fast enough at compiling that this would
seem an invisible part of the "save changes" step. Instead of using
Lua as an add-on, the entire program, core and extension, could be in
Go.
It seems that Go would be fairly easy to sandbox, just by having the
user code be textually inserted as the contents of a function body in
a fresh package, with a safe set of imports loaded. There's no escape
via pointer hacking, and no way to alter a global that wasn't
imported. They can't add imports from inside a function. About the
worst they could do is make a dead end channel and block the thread.
This can be avoided just by banning the creation of channels.
I'm not sure - are there any other escapes from such a sandbox?
Is it possible yet to do this? (It doesn't look like it, yet - but I'm
only a newbie.)
Tom Lieber
> I have a problem with a library that may panic and have my server die
> without being given the possibility of circumventing the termination.
> Whoops I crashed with the equivalent of a stupid 0x8NNNNNNN return
> code. Like relying on errno in the bad old C code. So again why would
> I want to use Go to write service providers. With java I get great
> service providers that run on any platform. C# gives a very similar
> set of services. C++ is really good for this and the coroutine aspect
> is very easily provided by library. I think I will examine Scala next.
I don't know why, but that reminded me of a video:
http://www.youtube.com/watch?v=_GxC4kKD9qA
But anyway, great point, I hope Scala is everything you could hope
for. I've really enjoyed this thread.
On Sat, Jan 2, 2010 at 3:04 PM, befelemepeseveze
<befeleme...@gmail.com> wrote:
> On 2 led, 17:26, Tom Lieber <t...@alltom.com> wrote:
>> I found it to be very, very nice for a multi-threaded server I needed
>> to build. Not supporting callbacks from C is killing me, though.
>
> You can have C callback(s) if this mechanism fit your needs:
... buncha code ...
Thanks, I wouldn't have thought of using pipes, but it could make
sense for some things. Not for any of the cases I've been thinking of,
but I will keep it in my back pocket. :)
emghazal
> I have a problem with a library that may panic and have my server die
> without being given the possibility of circumventing the termination.
> Whoops I crashed with the equivalent of a stupid 0x8NNNNNNN return
> code. Like relying on errno in the bad old C code. So again why would
> I want to use Go to write service providers. With java I get great
> service providers that run on any platform. C# gives a very similar
> set of services. C++ is really good for this and the coroutine aspect
> is very easily provided by library. I think I will examine Scala next.
>
Remember that Go is still an experimental language at this stage.
Exceptions are currently an "active topic of discussion." The
alternative is to use watchdog processes as RogerV said, but I
believe forking a Go program doesn't go very well right now. It might
be supported better later.
Ramanan
you need a better imagination if you literally can't think of anything
you could write this language.
Vincent Risi
Peter Bourgon
message brokers (itself a huge class of applications Go seems
purpose-built for), any sort of simple network service... that you
can't seem to generate this list speaks more to your lack of
imagination than any fault of the language, I think...
Uriel
http://go-lang.cat-v.org/go-code
It is rather impressive for such a young language that is still rather
experimental, and I'm sure there are even more apps that are missing
form the list (*hint* let me know of any apps that I should add).
uriel
Vincent Risi
investigating Scala and I already have an application that I am
writing. Go lives in a limited space currently, and in my opinion is
still too immature for me to invest time and effort with it. I really
do hope it moves forward and becomes more universal. I actually do
like its syntax and simplicity but it usage value is still too narrow
for me to contemplate writing any application in it. I guess that it
may become useful in the upcoming Chrome OS, but Who knows and The
Doctor is not letting on.
Evan Shaw
- Evan