Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

"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.



>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).


Woo hoo, thanks for the tip!

But I still need to worry about creating a memory leak with this. :(


Also, asprintf is a GNU-extension, so if you want to write portable code, it's a no-go (as for everything usefull in C).


Thankfully, 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." :)


Not in ANSI C nor POSIX.


Well, C++ has all of that.


Only 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++.


What 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.


Magic 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.


Magic 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();


1 point for "magic concatenation;" I wasn't aware that works!

"nice try" on "auto-conversion".


The main problem of C++ is that it has far too large values of "all".


Which is still too less when compared with Java, CPAN, Gems, .NET....


Similarly, 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.)


I didn't say it was a problem. I was objecting to "C++ has all that."


Ah, but the standard library (including unordered_map) is part of the C++11 standard.


> 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.


There are a large number of people who would strongly disagree with the claim that implicit casting is a good thing.


Absolutely, 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.


It has garbage collection through shared_ptr.


Not sure if you are serious but the hard part of gcs is resolving and identifying cycles. Cycles with shared pointers are just leaks.


Exception 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: