> Writing in those other languages was indeed a hellish experience - it was very clear that they lacked the expressivity to model half of even just this very core piece.

This is something that keeps sending me back to Haskell, I'm glad to hear Scala applies as well.

I've been meaning to learn more Scala, is there any "Scala for Haskellers" literature you are aware of? I'm going to start searching for some, but you could know of one that doesn't come up in my search results.

There is an awesome book called "Functional Programming in Scala" that has a lot of great questions to work along to, and is great for somebody interested in both Haskell and Scala but doesn't assume prior experience with things like combinators and monads. If you are pretty far down the Haskell route and want to learn about one of the more advanced type-level libraries, You may want to jump into http://eed3si9n.com/learning-scalaz/ and use https://twitter.github.io/scala_school/ as a quick reference or intro. If you have the time and desire, a lot of people swear by a cover-to-cover reading of Odersky's "Programming in Scala".

Hey, sorry - when I came to Scala I'd seen enough other languages that I read the language spec[1] and learned most of it in a day.

Since I never spent time onboarding myself, I'm not sure I can be any help. :/

The docs website is amazingly good, though - the tutorial[2] covers most of the unusual-in-Scala bases very quickly.

[1]: http://www.scala-lang.org/docu/files/ScalaReference.pdf [2]: http://docs.scala-lang.org/tutorials/tour/tour-of-scala.html

Generally speaking, Go is not a good fit for frameworks (which are meta-tools by definition). Implement the actual tool itself in Go, not a framework to build the tool.

I would disagree with this - it's a very broad statement. While building frameworks often encourages developers to abstract to the nth degree and add far more flexibility than is required, if you have specific requirements what's the problem?

We built a microservice architecture in Go at Hailo which runs approx 170 services. Abstracting core functionality into a 'framework' allowed developers to build and deploy services extremely quickly, and let the platform team get on with adding and improving core platform functionality, such as monitoring, instrumentation, tracing, provisioning, configuration etc etc.

Let me clarify a bit:

One of the things I love about Go is that I don't have to learn all kinds of conceptually heavy frameworks to get real work done. I read the stdlib docs and get to coding.

I've also found that when I'm tempted to stray from Go idioms and do something too generically, I tend to get punished by the language. So I've learned to just suck it up and do everything the "Go way". I don't consider this a negative--rather that Go is just not very tolerant of other language styles. You have to accept this.

I think the best way to describe it would be to make a distinction between frameworks and libraries. A framework integrates itself too much into the application's overall structure, while a library provides another tool that lets you write your code the way you've always been writing it, but to do something new.

The weakness of the type system becomes a problem pretty quickly - simply having a different implementation of an adaptor, be it per language, transport or even simply type of node makes for an endlessly leaking abstraction.

That's what I felt that overlapped with the GP's comments on composing complexity. It's not so much that you _can't_ implement multiple cases (not to the nth degree, just a handful), it's that the abstraction leaks painfully.

I find your and the parent's arguments really interesting.

For me Go reminds me so much of Java 1. And it seems to be getting pulled by the community in the enterprise Java direction e.g. generics, annotations, dependency injection, broad frameworks and the simple, tightly focused tooling direction.

The community isn't pulling Go into any of those things.

* Go had annotations since pretty much day 1. Look at the annotations for JSON serialization, for example.

* Generics is something that Go is probably not getting. It's just become a troll topic at this point since everything that could be said about this topic, has been said.

* Dependency injection is something that Go isn't getting. It's a Java solution for a Java problem. Create well-thought out code with clean interfaces and unit tests... problem solved.

* Broad frameworks: it's just not going to happen. As a lot of other commenters have said, Go just doesn't support the level of abstraction that you need to create a FactoryPatternPatternStrategy. And that is a good thing, in my opinion.

* Tooling: I have no idea what you mean really. Java's tooling is hardly "simple" or "tightly focused" (have you ever USED Maven?) and Go's community didn't "pull" the golang authors to create simple tools... they've been simple and focused since day one.