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.
I agree that error handling in Go is a headache. But since we are forced to handle every single error where it occurs, we can at least make the best of it and add context information before returning it.
I'm using a small utility library to wrap the original error and add function name, line, file name and optionally a descriptive message that explains what failed.
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.
OK so I've read it. Slices sound exactly like one would guess, using the word from other languages. A view into an array.
So exactly why are they not suitable for equality? Even that article starts with "Slices are analogous to arrays in other languages". Please elaborate on this basic thing.
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 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.
I was really excited about the idea of App.net being a developer-friendly replacement for Twitter, but when I finally got to try it, I was appalled by its complex and awful UI. One thing Twitter does relatively well is be simple. You can write tweets and you can read them. App.net had poor focus and failed to do a simple thing by trying to do a complex thing instead.
