* Silvan Jegen <s.je...@gmail.com> [2014-03-04 14:27:26 +0100]: > On Tue, Mar 4, 2014 at 9:25 AM, FRIGN <d...@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
