0x434D53

That happens, when a content marketer write about a technical topic... Just sad.

Which also teaches horrible security practices. Pleas also use gorilla/csrf and not your own brown "solution".

So what's the conclusion of this besides some useless numbers?

Wow, trying to doxx people is just the lowest.

You are not forced to handle errors. Or do you check for the errors returned by fmt.Print? I guess not.

This was my point: In many areas go forces the developer to the right thing (no unnecessary imports, gofmt...) and does not rely on developers discipline. But when i comes to error handling it does.

What i would wish for is some extended error handling supported by the compiler. I don't want a stack trace, but the compiler easily could produce for example a line number where the error was returned.

Go is one of my working languages. Like with every other language (Python, OCAML, C#, some Java, Swift) i have a love-hate relationship with go.

What i agree on:

What i agree on with the presentation: Concurrency using goroutines and channels is f... hard besides very primitive scenarios. Even fork-join isn't that easy. There also the lack of expressiveness hurts: It's nearly impossible to build higher level abstractions above the channels/goroutines. You always have to do the bookkeeping of your goroutines.

I also agree on the error-handling problems: It's often hard to locate errors. It requires a big amount of discipline by the programmers to achieve some kind of ability to locate errors. No, i don't want the Java/C#-'i throw exceptions everywhere'-style back, but Go is the other extreme. Some more lightweight-panic wouldn't be bad.

What i can't agree on:

That you cannot mock without interfaces in Go is typically not a problem: There is no real encapsulation (_, ., no constructors) so in many cases you just an instantiate your structs as you need them. The classic for mocking - time - is problematic as in every language. IO is typically behind the various io.Reader/Writer... interfaces: No problems there.

The criticism about memory consumption i don't get: Every system i saw ported to go from Java, Ruby or Python had a much lower memory footprint than before. And typically go allows to optimize allocation quite well when needed.

For an array (which are value types in go) you have the obvious element-wise equality.

For slices? Also element-wise? Even with different capacities? If the refer to the same window in the underlying array? Is there a need to copy the slice for inserting it to the map? Probably yes, because otherwise you could mutate the key from outside. But then it would be inconsistent to assignment (slices are reference types).

I have no idea how this could be done concisely.

A slice is not an array of bytes. That's exactly the point.

See http://blog.golang.org/go-slices-usage-and-internals to get a basic understanding

I don't get that outcry and panic inside the Scala community. We should give the 2 forks a chance and see what it leads to. There is still the chance then to reunite the community behind "one" scala. Also they could have great influence on Typesafe Scala. As far as i know the compiler (which is not very much): The 2 forks will anyway not move away from Typesafe scala at huge speed.

Let's come here again in 6 months and see where we stand.

It's the users fault! App.net was a alternative to twitter, but a paid one. Failed. So users are in no position that they are the product sold to advertisers. They actively decided to be the product.