[omnigoat]

My word, a whole bunch of what I'm reading is exactly what I have/had intended to implement in my toy language, prism. Bit-specified integer (and real) types, increment/decrement operators as statements (prefix only!), hell, even using "var <X> ..." for variable declarations. The guiding principles are divergent though. And the bit about deducted type relations (http://golang.org/doc/go_lang_faq.html#inheritance) leaves me with mixed feelings.

I'm actually happy! It means my stupid little language has some validity :P

For those who wish to deride it: http://code.google.com/p/prism/

[omnigoat]

Well, in the interests of actually furthering discussion:

I feel as if string and map simply could have been part of the standard library. My solution to the this for prism was to have a section of the standard library (which doesn't exist yet) marked as "integral", to effectively have an implicit "import string, map from std.__integral__" at the top of every translation unit.

The absence of overloading operators seems to contradict their claims of improving the visual "flow" and feel of programming. There are cases where savvy operator overloading works wonders: vectors/matrices/quaternions, strings, complex numbers, etc. To be able to write my_string + my_other_string is far more elegant than strcat(my_string, my_otherstring). Consider what happens when you have four of five strings you'd like to concatenate!

The choice of CSP reflects Google's mentality: Their problems lend themselves very well to CSP. Other domains (in my opinion) work better with a STM model. But that's clearly a design choice, and I think it's fine!

[oconnor0]

I'm not a huge fan of "+" for string concatenation as "+" is, traditionally, commutative; I like Lua's "..". That being said I like "+" more than "strcat".

[agl]

Operator overloading has good points and bad points: we're erring on the side of simplicity for now.

However, you can write "abc" + "def" in Go and it does what you expect.

[astine]

=> "egi"?

[blasdel]

Thankfully strings in Go are completely distinct from Arrays -- immutable, and with hard baked-in UTF-8 support.

[spicyj]

I'm sorry if this is a stupid question, but where'd you get that? I don't get it. :(

[skarlath]

"abc" + "def"

a + d = e (1 + 4 = 5 = e) b + e = g (2 + 5 = 7 = g) c + f = i (3 + 6 = 9 = i)

I think he was making a joke about how + with strings doesn't necessarily mean string concatenation.

[patio11]

I think the point is even better than a joke: there is a danger in allowing things like, e.g., operator overloading (or redefining methods in the standard library), because programmers have different feelings about what the code "obviously" means.

If in your language, + means string concatenation by convention, then + darn well means string concatenation. If in your language + means "contextually appropriate depending on what arguments you pass to it", then

"abc" + "def" => "egi"

doesn't strike me as obviously wrong.

More broadly, consider a language in which we teach initiates that "Plus adds things in the way you'd expect!"

map = {}

map2 = map + {"key" => "contents"}

What are the contents of map and map2 now? Uh oh. More worrisome:

map = MemcachedWrapper.new

map2 = map + {"key" => "contents"}

What just happened?

[btilly]

And he could have expected 18AB to point out that those strings wouldn't necessarily be interpreted as strings in a math context.

[spicyj]

Oh, element-wise addition. Somehow I didn't figure that out. Thanks.

[d0m]

:P Nice one, made me smile

[aidenn0]

I always thought a huge benefit of lisp using S expressions is the lack of infix operators saves a lot of time and energy arguing whether/when they should be overloaded.