3 ms·
I agree with the author's main point that the golang toolchain has a bad case of NIH syndrome, and many of the specific problems he mentions have already been S
by infogulch 12y ago
I agree with the author's main point that the golang toolchain has a bad case of NIH syndrome, and many of the specific problems he mentions have already been Solved™ in other tools for some time. But there are reasons to have full control of your entire toolchain, one of which is not having to deal with getting patches merged upstream (in any of the dependencies). Another is having the toolchain easily deployable on a multitude of platforms including windows and plan9. The solutions he mentions are heavily reliant on specifics of the unix environment, and most such projects would not welcome platform-neutralization. (If your windows toolchain deployment includes "install MinGW and use Cygwin", it's no longer "easily deployable" there.)
- trhway 12y ago>I agree with the author's main point that the golang toolchain has a bad case of NIH syndrome, the blog seems to be from a Sun old-timer who pretty typically suffers from ... err ... enjoys this superiority style complex of "we have already invented everything, why stupid word chooses to go its stupid way instead of that great way we think it should go". This complex (and, as a major result of it, refusal to accept reality) is one of the major things while Sun went down. (hi! to Sun guys. Have you seen the abomination what FB did to our nice offices in MPK!? :)
- Jabbles 12y agoI hear they have a Sun sign there, to remind employees what happens to companies that stop trying. Or perhaps that's another office - or maybe just rumour.
- ropiku 12y agoIt's on the back of the sign in front of the campus: http://www.businessinsider.com/why-suns-logo-is-on-the-back-of-facebooks-sign-2014-12 http://www.businessinsider.com/why-suns-logo-is-on-the-back-...
- KyleBrandt 12y agoTaking the not invented here idea with Go and the recent generation lost to the bazaar post ( https://news.ycombinator.com/item?id=8812724 https://news.ycombinator.com/item?id=8812724 ) is somewhat interesting. I see Go from a user perspective as having both those design and culture aspects mixed together (successfully IMO).
- twotwotwo 12y agoPike said of the asm syntax a while back "It's a mess for which there is no good excuse aside from history": https://groups.google.com/forum/#!topic/golang-nuts/6-qcvLnW7b4 https://groups.google.com/forum/#!topic/golang-nuts/6-qcvLnW... . Also, later in that thread: > It's not a proper assembler, only a way to generate the startup object files necessary to get the binary running, and is neither clean, complete, nor documented. > None of that is excusable, only true. Plan 9 C compilers, incidentally, are going away too as soon as they port the rest of Go into Go. It's clear to me there was path-dependency--some folks who mostly worked on Plan 9 started a little skunkworks-y language project, and rather than deciding to learn the LLVM world and slot themselves into that à la Rust or similar, they brought along the toolchain they'd been working with since forever. To me, that's more like any other case of sticking with legacy code than NIH--it's "I'm using these tools I've worked a lot with because that's a lot cheaper for me than switching" not "I'm going to build tools from scratch right now because [I think I can do better|it's fun|rabid badgers made me do it]." I wouldn't mind using LLVM or some such to handle the lower levels at all; I hear it's great elsewhere and I specifically hear Go's ARM codegen is pretty wonky. But it's also expensive to do and a lot less important to most of us than the things the team's working on, like lowering GC pause times. Finally, in case anyone read it as serious, "Instructions, registers, and assembler directives are always in UPPER CASE to remind you that assembly programming is a fraught endeavor" is a joke. This is the same language that has 'notwithstanding' as an (ignored) keyword; not everything deadpan is serious.