9 ms·
I 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
by aaggarwal 11y ago
I 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.
- Elrac 11y agoMagic concatenation: the "+" operator is understood by the compiler to be the concatenation operator if either operand is a String. "Magic" in the sense that it's an exceptional affordance made by the language (not the library) for this one data type and operator. Auto-conversion: "2" + 5 = "25". This looks horribly hackish, like some type buggering perl might do, or js. But it comes in handy when you want to build a message string. And yes, as the article tells us, a lot of things are very purposely left out of Go, which has advantages and disadvantages like most trade-offs.
- okasaki 11y agoMagic concatenation: string hello = "hello"; string world = "world"; string hw = hello + ' ' + world; Auto-conversion: stringstream ss; ss << "2 + 2 = " << 2 + 2 << endl; string result = ss.str();
- Elrac 11y ago1 point for "magic concatenation;" I wasn't aware that works! "nice try" on "auto-conversion".
- pjmlp 11y ago> Finally, garbage collection will likely never be part of C++. C++11 has a GC API defined. Reference counting is part of any GC book in CS speak.
- wyager 11y agoThere are a large number of people who would strongly disagree with the claim that implicit casting is a good thing.
- Elrac 11y agoAbsolutely, and it's something I consider somewhat of a liability in (e.g.) Scala. You can drive yourself crazy if you're not careful. However, I feel that doing the "implicit casting" thing only for the single, limited case of string concatenation strikes a happy medium between providing useful convenience and giving you enough rope to hang yourself with.
- danieldk 11y agoSimilarly, hashmaps, while built directly into the language in Go, are a library class in C++. And this is a problem because? (It's actually a weak point of Go that you cannot define them in a library without sacrificing type safety.)
- 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.