9 ms·
Go is doomed to succeed because it extends the mental model of C with a concurrency model that finds a decent compromise between power and ease of use, makes th
by vezzy-fnord 11y ago
Go is doomed to succeed because it extends the mental model of C with a concurrency model that finds a decent compromise between power and ease of use, makes the typing less prone to subversion, adds memory safety via GC, uses a structural subtyping system through interfaces that brings many OO-like benefits while still keeping to the C struct way of thinking, first-class functions, various syntactic rough edges cleaned up and so forth.
Because the Unix system programming world (and POSIX particularly) is very much built with the conventions and semantics of C in mind, most serious POSIX programming outside of C means you have to deal with painful FFIs, lousy wrappers, overly abstracted APIs that hide details like certain lower level flags and so forth. Some are better at this than others, of course (OCaml is one of the better ones)... but, nonetheless.
So it's unsurprising that many infrastructure developers are jumping to Go. There's just enough new things to incentivize a switch, but not too much that it dissuades from it.
- aaggarwal 11y agoI have never used Go before. From the sound of it, it looks like Go hits a sweet spot between C and Java? and of course the Google support is a major factor for a possible success.
- Elrac 11y ago"Between C and Java" hits it very well, I'd say. When I jumped ship from C to Java, Java's object orientation wasn't exciting to me, and its exception handling is an acquired taste. But dynamically growable, garbage collected buffers are something I'd missed for a long time. And the simple ability to concatenate strings without first reserving space for the result. Oh, and hash maps! Remarkably versatile data structures, those. Coming from C, Java was a delight. Java would have a lot more trouble dragging me away from Go.
- okasaki 11y agoWell, C++ has all of that.
- Elrac 11y agoOnly for small values of "all." The magic of concatenation and auto-conversion of strings that's baked into the Java compiler and, to a lesser extent, the Go compiler, is missing in C++ - not vital but convenient. Similarly, hashmaps, while built directly into the language in Go, are a library class in C++. Finally, garbage collection will likely never be part of C++.
- okasaki 11y agoIt has garbage collection through shared_ptr.
- albinofrenchy 11y agoNot sure if you are serious but the hard part of gcs is resolving and identifying cycles. Cycles with shared pointers are just leaks.
- reagency 11y agoThe main problem of C++ is that it has far too large values of "all".
- pjmlp 11y agoWhich is still too less when compared with Java, CPAN, Gems, .NET....
- reagency 11y agoThe main problem of C++ is that it has far too large values of "all".
- klibertp 11y agoWhat do you mean by "the magic concatenation and auto-conversion of strings"? Also, having a map implemented in a library is a Good Thing. It means that your language is extensible and expressive enough for this. AFAIK Go is - by design - not that extensible.
- xamuel 11y ago>And the simple ability to concatenate strings without first reserving space for the result Not exactly the same thing, but routine string manipulation in C gets considerably easier once you discover a highly underrated function called asprintf (basically combines sprintf and malloc, calculating the buffer size for you).
- Elrac 11y agoWoo hoo, thanks for the tip! But I still need to worry about creating a memory leak with this. :(
- Merovius 11y agoAlso, asprintf is a GNU-extension, so if you want to write portable code, it's a no-go (as for everything usefull in C).
- Elrac 11y agoThankfully, I'm not doing much C any more. Those hoity-toity hand-holding languages have spoiled me, and now I don't want to be bothered about memory management and other "trivia." :)
- pjmlp 11y agoNot in ANSI C nor POSIX.
- threeseed 11y agoException handling may be an acquired taste. But it is infinitely better tasting than Go's ridiculous error handling which is something you would expect in the 1980s.
- masklinn 11y ago> it looks like Go hits a sweet spot between C and Java? If your sweet spot is 90~95% java and 5~10% C.
- aaggarwal 11y agoThat's not really my sweet spot, but if it have such a strong inclination towards Java, then would it be much easier for Java programmers to move to Go compared to C programmers? And, what about python programmers, how would Go be for them?
- dsymonds 11y agoAny decent programmer should be able to switch between {C,Java,Go,Python} without too much difficulty. They each have their own differences and learning curve, but as long as a programmer doesn't identify themselves too tightly as a specific language developer (e.g. some people say "I'm a Java programmer", implying they couldn't possibly learn something else) then it's not hard to pick up Go.
- tptacek 11y agoIf you took "C" out of that list, I'd agree with it.
- dsymonds 11y agoYeah, C is probably the hardest to learn in that set.
- eropple 11y agoI think that's reductive. I'm a "decent programmer". (I think I'm a little better than that, if I'm being honest.) I regularly use Ruby, Scala, C#, and enough bash to choke a horse. Some C++ too, when I have to, but it's not something I ever want to touch. I can't deal with Go. And I don't think it's me--I don't do Haskell because of me, I don't do Go because of it. I find it almost impossible to think in Go. I find it incredibly primitive, well past the point of "stupid code is impossible to misunderstand" and into "stupid code because the language demands it." This wouldn't bother me, in a very "you do you" sense, if I wasn't stuck debugging faddishly-designed tools like Docker and Terraform written in it. To this end I think Go is a regression for the open source community, because what I see as veneration of stump-dumb languages makes it harder, not easier, to be smart about problems.
- vezzy-fnord 11y agoNot quite. To understand Go, you need to understand the history of the Bell Labs gurus somewhere around the late 9th and 10th editions of Research Unix, when the vestiges of what would become Plan 9 and Inferno began to take shape (the sam editor that would influence acme, the rc shell, mk and the predecessor to 9P [streams] would all originate here - see "Interprocess Communication in the Ninth Edition Unix System" [1]). Meanwhile, Rob Pike and his contemporaries did language research, particularly related to the semantics of CSP-style concurrency. Syntactically they were all C-like, as the Plan 9/Research Unix community all generally liked it. Newsqueak was the first and it was a cross between C and with special syntax and semantics for procs (green threads). It was written for GUI workstation environments in mind, the idea being to easily build multi-seat applications. From Newsqueak arose Alef, which refined on it but had manual memory management. Then from Alef came Limbo, the language running on top of the Dis VM that formed the core of the Inferno OS. Fast forward some years later, Rob Pike and some other Bell Labs vets are at Google. Some event happens which painfully reminds them of mediocrity in computing, that gives them the drive again and they resume right where they left from Limbo. Go is born. [1] http://cm.bell-labs.co/who/dmr/ipcpaper.html http://cm.bell-labs.co/who/dmr/ipcpaper.html
- r0naa 11y agoThat was very insightful, thank you for sharing!
- tptacek 11y agoI feel like "bringing CSP into a modern language" gave Pike's team social permission to launch Golang, but the parent comment is closer to the truth than this summary. According to Pike's blog, the real motivating factor for Golang was how forbidding and painful Google's C++ build process was. A lot of Golang makes more sense if you look at it through this lens: above all else, don't be like C++.
- pcwalton 11y ago> According to Pike's blog, the real motivating factor for Golang was how forbidding and painful Google's C++ build process was. A lot of Golang makes more sense if you look at it through this lens: above all else, don't be like C++. You and I disagree in regards to a lot about Golang, but I think you're spot-on here. I've thought for years that it was interesting how yosefk's criticisms of C++ in the "Frequently Questioned Answers" directly correspond to decisions in Golang: "compile times are long" → "use the Plan 9 toolchain", "memory management is difficult and unsafe" → "garbage collection", "templates are a mess" → "no generics", "exceptions interact badly with RAII" → "no traditional exceptions", "header files are a pain" → "use packages and forbid circular dependencies", etc.
- oldmanjay 11y agoIt doesn't feel right to say go is "between" java and c. There isn't a tremendous amount of expressiveness in go that java can't replicate, and there's enough in java missing from go that makes it a wash, for me anyway.
- not_with_retard 11y ago> There isn't a tremendous amount of expressiveness in go that java can't replicate, and there's enough in java missing from go that makes it a wash, for me anyway. And thus, you've completely missed the point of Go.
- tptacek 11y agoI'm a 90's C programmer and a Golang programmer now, and while there's some truth to this, it's reductive. A 2000s-era C programmer would not write socket code that worked the way net.Conn does. While C code gave us the "pipes and filters" abstraction of Unix, they are not an idiom in C code --- in fact, Golang's reader/writer interfaces feel more like a refinement of Java than a modernization of C. Golang feels very much like an offspring of Java and Python to me.
- api 11y agoWhen I looked it over it struck me as a stripped down Java that's friendlier for systems programming and could interoperate with C without the torture of JNI.
- vezzy-fnord 11y agoYes, Go has a heavy focus on interfaces and structural subtyping, as I said. It reflects the trend behind Pike's languages: C-like + some form of CSP + key abstraction. But, even the net package has a noticeable Plan 9 legacy, like the use of dial/listen, as opposed to the clumsy Berkeley socket way. You might recall this was a central complaint of Pike's in his famous presentation "Systems Software Research is Irrelevant". Obviously it's nowhere near as pure as ndb, but that's the reality of being in Unix.
- tptacek 11y agoI certainly can't deny the Plan9-ism.
- ChuckMcM 11y agoThat captures it for me, imagine a Python that squeezed to the essential bits of Java and left you with Go. It helped that Java, Python, and C++ were the core languages at Google where Go was developed so you had to have something that could bring that community along. For me personally Rust is more my style, but I agree with the original author that the structural aspects of Go program construction will benefit large communities greatly. It is something I had not really considered seriously before.
- 11y ago
- nickbauman 11y agoThe problem with Go is likely a result of having the kinds of stated goals that it has. The designers of Java deliberately created a language that was for people they didn't trust. The result is a hammer that looks and works like a dildo. So we're likely headed to where the commensurate Go analogy to Java is a hammer that looks and works like a catheter or something? One last analogy. What would you prefer: a pilot who has been certified to fly that aircraft and has a minimum number of flight hours or giving every passenger a joystick sticking out of their seat tray so that maybe collectively they won't crash the plane? Oh, and you kids get off my lawn (waves cane)! ;)
- Merovius 11y agoThe correct analogy (as we are generally not building people) is "Building an aircraft, that needs a pilot with certification and a certain number of flight hours, or building an aircraft that can be flown by any passanger with minimal instructions, if the need arises". In the latter aircraft, you still benefit from an experienced pilot, but at least, if they pass out, get drunk or plainly go rogue, you still have a decent chance of dealing with the situation, instead of just crashing.
- Dewie3 11y agoIt's weird to see so many of these "Go is a cleaned up/incremental step up from C" when 1) There have been plenty of natively compiled, garbage collected languages without much more fuzz than that before. 2) It seems more popular with people with a Python, Ruby etc. background rather than a C++ background (which was originally suspected would be a decent audience) or a C background.
- pjmlp 11y agoI don't like how Go's design turnoud to be, but I surely appreciate that it means less C code and more memory safe code. Eventually C will be squeezed into an Assembly like niche, used only for shaving out ms out of an application, kernel stuff or those little code tricks not exposed on the safe layer.