cy_hauser

Yes, but you discount the size of Google. Some of the things Google has killed have been large enough to have been considered successful products for a startup. They kill a "tiny" product because it's only large enough to be what some startup hopes to become. Google Reader is my favorite example of this. Multiple companies now exist in the soil on top of that grave.

No matter where you lop the end of the Pareto distribution off the remaining curve still fits the same distribution. I though that was a defining characteristic of the principle.

> ... reliable distributions ... do not control individuals.

The people who've made it always talk to the people who haven't as if they can, by force of will, change their circumstances. That may be true if an individual has an untapped talent but in general luck will determine your outcome way more often than force of will. If it were possible for everyone to be rich there would be examples of that in society all across the world and all throughout history.

I applaud your optimism though.

Of course you can code gen using Go's tags. It's done all the time.

As already pointed out, Go has the JFR it needs, not what Java has.

Go doesn't need a JITter.

Go isn't perfect, but neither is Java or C#. Go code is known for being maintainable and easy for newcomers to read so your last line applies to Java more than Go. But it seems like you want to hate Go. Why?

All that said, what makes your list any different than a similar list comparing Java to Blub? I don't see your list as preventing one from writing a Java app in Go using Go's idioms instead. (It can't fully do what Java or C# do.)

In general, users don't care about errors or stack traces. They don't want errors of any kind. As a developer I want users reporting errors, which can include a dense stack trace, so I can get the error and an explanation of what they were doing when the error happened. I'm more for making my life easier than worrying about what a user sees.

  type MyStruct struct {
    Name string
  }

  var-not-nil myStruct = &MyStruct{"Hello"} // this is a "not-nil" pointer variable

  myStruct = nil // compiler would catch this

Go is getting generics in (hopefully) in a few months. Some features are missing but most don't cause much pain and can be either simulated or worked around. Error handling is its biggest failure, but outside of that I find is at least as productive as other compiled languages in the same space.

I don't understand. What do you mean?

> almost every use of generics ultimately ends in type erasure or forced casting

Again, not understanding. Would you mind giving an example of this?

I deleted my SO account a few years back because I came to dread the "great q&a experience" so much that it was pointless. Trying to word a question so it wasn't closed immediately or getting the "what are you really trying to accomplish" was just too much to bother with. Best of luck though, I guess.

I disagree. A quick look through the Go code I'm working with now shows more than half the functions that check for and return errors have absolutely no business knowing about the error. These places are in the middle of the call chain, well away from the place that generated or first encountered the error. These functions check the "if err != nil" and bubble them up. That's just noise. Go's error handling in these cases color everything in their path.

-- Assume an employee filling out a form on a web site that takes on minute to complete.

-- Assume submits are randomly sent. (A bad assumption)

Per minute that's (1 * 60 * 400) 24,000 people submitting a form. Or over a million people submitting their form per hour. Nothing Google scale but enough for most any internal business application.

I think their complaint is valid, especially in light of their finding it difficult to find experienced coders who are in their salary range.

New coders can lean heavily on a good IDE to help: code completion, breakpoints, step wise debugging, one click links to the docs, easy code navigation, and more. Senior coders can and should use the editor of choice, but a great IDE makes a world of difference for a junior or even intermediate coder.