Re: [dev] What is bad with Python

From: Szabolcs Nagy <nsz_AT_port70.net>
Date: Tue, 4 Mar 2014 20:56:18 +0100

* 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
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.
dont expect fast opengl access from go) and you cannot really
use it for quick scripting tasks

go can be used when you interface with software across
network or process boundaries (it cannot interface with
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..

> * The XML/JSON unmarshaling is cumbersome (I think I prefer the

i dont think this is the bigest issue in go..

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
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
Received on Tue Mar 04 2014 - 20:56:18 CET