On Tue, Mar 04, 2014 at 08:56:18PM +0100, Szabolcs Nagy wrote: > * 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
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.
