On Tue, Mar 04, 2014 at 08:56:18PM +0100, Szabolcs Nagy wrote:
> * Silvan Jegen <s.jegen_AT_gmail.com> [2014-03-04 14:27:26 +0100]:
> > On Tue, Mar 4, 2014 at 9:25 AM, FRIGN <dev_AT_frign.de> wrote:
> > > A question to everyone on this list: What do you think about the
> > > Go-language?
> >
> > I used Python for all my scripting needs before Golang hit version 1.0
>
> i hear this a lot and don't quite understand
>
> you use python as a glue language (between dynamically
> loadable extensions written in c and wrapped so one can
> use them from python: the drawback here is that as usual
> the heavy python runtime has unspecified interactions with
> the c runtime eg. if you load a lib that starts threads and
No, I do not use Python with C extensions. That was someone else.
> then you call os.fork() from python) or for writting
> scripts/single shot programs/prototypes (where the simple
> syntax, dynamic types, repl etc helps)
>
> go is not very good for either of these: it cannot directly
> interact with anything written in c (it has a hack (cgo) to
> initialize the c runtime in a separate thread but that's
> rather fragile and slower than a direct function call, eg.
I remember reading about C function call overhead when calling them from
Go but as I have written in my prior mail, I use Go for simple scripting
tasks, not to call out to C code.
> dont expect fast opengl access from go) and you cannot really
> use it for quick scripting tasks
Why should Go not be suited for quick scripting tasks? I use Go to parse
text files, reformat them and/or sending them to restful services. It
really works quite well.
> go can be used when you interface with software across
> network or process boundaries (it cannot interface with
That's what I use it for.
> existing libraries easily so they have to rewrite every
> userspace lib in go, however it can interface with os
> syscalls as long as the syscall abi is stable: it is not
> on some systems such as openbsd)
>
> > It is not without its problems though:
> >
> > * There are no generics (it is not clear at the moment whether they
>
> i dont get this either
>
> you can do a lot of things without generics and
> just generate code when that's what you need..
On the lines you cut out I mentioned that I do not really miss any
generics for the cases I use Go for. The lack of generics is not an
issue for me (not yet anyway).
> > * The XML/JSON unmarshaling is cumbersome (I think I prefer the
>
> i dont think this is the bigest issue in go..
Well, it is for my use cases :-)
> it has segmented stack and you cannot handle reliably if
> a goroutine stackgrow fails to allocate (and it is slower
> than just using huge stack in a 64bit address space), it has
> userspace n:m task scheduling with it's known issues (no
> preemptive scheduling etc) and a gc with potentially large
> memory overhead and high latency so you cannot use it for
> anything with hard-realtime constraints, it does not have fenv
I think all these points are true for Python as well. Except that the
CPython interpreter itself is severely concurrency-challenged:
https://wiki.python.org/moin/GlobalInterpreterLock
> access semantics or long doubles on hw that supports this, so
> not really suitable for scientific computing (well barely
> anything can do this other than c, fortran or asm) the math
> library is not very high quality either and various builtin
> packages are much less optimized than the ones available in c
> (big, crypto, regex, image..), so often simple python scripts
> can beat go in performance, heavy usage of go interfaces and
> runtime type information can make things slow as well
Math libraries (especially for linear algebra) come up as a topic quite
often in the golang-nuts mailing list. There still does not seem to be a
consensus about the best way to handle matrices in Go.
Again, for my basic requirements those points do not matter however.
Received on Tue Mar 04 2014 - 21:30:47 CET