3 ms·

all good points, well made. I find it disappointing that we've come to label systems languages as the languages with the properties to implement the 'systems'

all good points, well made. I find it disappointing that we've come to label systems languages as the languages with the properties to implement the 'systems' of yesteryear instead of the systems of tomorrow; Singularity, for example. One wonders if Pike and co were to build a new OS just where they'd put the managed/unmanaged line. Wikipedia says http://en.wikipedia.org/wiki/System_programming_language http://en.wikipedia.org/wiki/System_programming_language "The distinction between languages for system programming and applications programming became blurred with widespread popularity of C and Pascal." and I'd hazard that Pike was smearing that blur wider by saying Go. The Go FAQ http://golang.org/doc/go_faq.html http://golang.org/doc/go_faq.html still starts by saying "No major systems language has emerged in over a decade" and implicitly saying Go is to be it. Now to my point that C/C++ is usually a bad choice. Most C++ projects I've seen have been misguided, legacy choices from the late 90s when C++ was the rage. Then again, I've always been mystified by the appeal of STL, since it only just got a hashtable. I have always ended up building higher-performance custom collections for stuff and found STL with its iterator-instead-of-ranges clunky. I've written buckets of C/C++ code for OS and multimedia projects, some fairly recently; but even then, I'd rather have written only the innermost mechanics of them in C and lashed them together in something that was nice to work with, good C interoperability (no I don't think python tooling is nice) and didn't throw completely out all performance concerns. And until Go came along, there really wasn't anything. Python and so on are only useful for coordinating stuff when the task is embarrassingly and massively parallel. Along comes Go; you can still x-ray some Go code and have a pretty shrewd idea what the resulting machine code looks like, just like C/C++. Its within spitting distance of C/C++ code for performance and will improve. And as the concurrent scheduling is all in the hands of wizards, one expects it to scale multi-core rather better than something working at the lib-level that requires more discipline to use. Having said that, I'm actually using Java for a current no-compromise-performance rewrite-from-Python project now. Its Go but its tried and tested. Still, I am not enjoying myself too much. FWIW, had a fun bug in production the other day; turns out I must be the biggest user of Python in a sense, since I discovered - via a crash - that multiprocessing is using `select()` internally and will fail if it it gets a descriptor over 1024.. how come nobody else has discovered this? I see only one person has, and the fix is in ... 3.3. Just a fun story.

codewright 14y ago
I'm sorry to be this blunt, but it's quite apparent that you haven't done any serious systems programming. That you were surprised by the syscall underlying multiprocessing...says a lot although I could point to other indications. Please don't make assertions as to the necessities of a specialty you haven't delved in, it makes it very difficult for me to be civil and respectful. There is...no real comparison between C/C++ and Java for last-mile performance at the bleeding edge, even if Java is a VERY good high-performance replacement for Python for stuff like network services. There are a variety of other use-cases where C/C++/Fortran/Ada are extremely necessary. Also note how abysmal Java has been for Android compared to Obj-C with its ever-present escape-hatch to raw C for making responsive and pleasant mobile apps. Especially games. That aside, stuff like Singularity is research-grade only for very clear and obvious reasons. It isn't practical yet, if ever it would be. Losing a lot of potential performance and control over the machine at the universal OS level is pretty...damaging and limiting. It's bad enough that an entire programming language ecosystem can put a cap on your power over the computer and the performance/behavior thereof, to do that at the OS level except as a research project is unconscionable. Please don't act as if Wikipedia articles about Microsoft Research projects are some indication of the vanguard of operating systems. > you can still x-ray some Go code and have a pretty shrewd idea what the resulting machine code looks like, just like C/C++. Er, maybe in the trivial case. You won't have anything close to a deterministic or real-time model for memory management available to you though. And never will. Everything Go provides on top of C in terms of extra features essentially requires GC to function. (goroutines, and related features). The only thing it really adds on top of C that doesn't necessitate the GC is most aspects of the type system. That could be reused in a hypothetical systems language. Go itself, in its current design, has absolutely zero future as a systems-language-of-first-resort outside of tinkering. (Some people will cross-compile Go code to chumbys and stuff.) However, it has something more excellent available to it. A potential future as the hero that slayed Java and supplanted it. I would rather it did that than focused on trying to compete with C or C++. It's not suited to the task and cannot be reconciled with that goal as a fundamental property of its design. Go is an excellent language for network services. Like Java. Doubly so once they replace that awful garbage collector in 1.1
- pjmlp 14y ago

codewright 14y ago

I'm sorry to be this blunt, but it's quite apparent that you haven't done any serious systems programming. That you were surprised by the syscall underlying multiprocessing...says a lot although I could point to other indications. Please don't make assertions as to the necessities of a specialty you haven't delved in, it makes it very difficult for me to be civil and respectful. There is...no real comparison between C/C++ and Java for last-mile performance at the bleeding edge, even if Java is a VERY good high-performance replacement for Python for stuff like network services. There are a variety of other use-cases where C/C++/Fortran/Ada are extremely necessary. Also note how abysmal Java has been for Android compared to Obj-C with its ever-present escape-hatch to raw C for making responsive and pleasant mobile apps. Especially games. That aside, stuff like Singularity is research-grade only for very clear and obvious reasons. It isn't practical yet, if ever it would be. Losing a lot of potential performance and control over the machine at the universal OS level is pretty...damaging and limiting. It's bad enough that an entire programming language ecosystem can put a cap on your power over the computer and the performance/behavior thereof, to do that at the OS level except as a research project is unconscionable. Please don't act as if Wikipedia articles about Microsoft Research projects are some indication of the vanguard of operating systems. > you can still x-ray some Go code and have a pretty shrewd idea what the resulting machine code looks like, just like C/C++. Er, maybe in the trivial case. You won't have anything close to a deterministic or real-time model for memory management available to you though. And never will. Everything Go provides on top of C in terms of extra features essentially requires GC to function. (goroutines, and related features). The only thing it really adds on top of C that doesn't necessitate the GC is most aspects of the type system. That could be reused in a hypothetical systems language. Go itself, in its current design, has absolutely zero future as a systems-language-of-first-resort outside of tinkering. (Some people will cross-compile Go code to chumbys and stuff.) However, it has something more excellent available to it. A potential future as the hero that slayed Java and supplanted it. I would rather it did that than focused on trying to compete with C or C++. It's not suited to the task and cannot be reconciled with that goal as a fundamental property of its design. Go is an excellent language for network services. Like Java. Doubly so once they replace that awful garbage collector in 1.1

pjmlp 14y ago