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

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.




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

Search: