8 ms·

I'd be pretty nervous about any attempt to recreate Finagle in Go. Scala provides many ways of creating composable complexity. Finagle leverages pretty much e

I'd be pretty nervous about any attempt to recreate Finagle in Go. Scala provides many ways of creating composable complexity. Finagle leverages pretty much every feature of Scala (and there are many) to maximize this composability in a sane way, but because there is simply so much complexity in Finagle, a lot of opportunities for composability have been skipped due to lack of need within Twitter (maybe finagle-http has significantly improved in the last year, which is mostly what I'm thinking about when I say this) but it's a LOT of complexity, sort of like the RoR of distributed systems, and when you want to diverge from Twitter's chosen trade-offs, it may be a hellish experience. It's pretty sweet for when your problem space aligns with Twitter's, however. Go has basically none of the mechanisms for sanely creating composable complexity that Scala has. It makes me really grossed out to think about something with the complexity that Finagle exposes as a Go library. Go is all about small, sturdy tools that work for most of the cases most of the time and that compose well with each other - IF - they are built into the standard library. And if it's not, have fun spending your time writing uni-typed interfaces for any kind of interop with desired complexity. Go is great for writing dead simple byte slingers, pipelines that will be rigid in the most dynamic possibility, guns that shoot JS and interact with services, etc. That's simply not Finagle.

frowaway001 12y ago
Go has basically none of the mechanisms for sanely creating composable complexity that Scala has. It makes me really grossed out to think about something with the complexity that Finagle exposes as a Go library. Go is all about small, sturdy tools that work for most of the cases most of the time and that compose well with each other - IF - they are built into the standard library. And if it's not, have fun spending your time writing uni-typed interfaces for any kind of interop with desired complexity. Go is great for writing dead simple byte slingers, pipelines that will be rigid in the most dynamic possibility, guns that shoot JS and interact with services, etc. That's simply not Finagle. A thousand times this.
tekacs 12y ago
I didn't mention in it my sibling post here, but we started writing the core of wym (our microservices framework) in Go, then Node.js and finally settled on Scala for exactly the reasons you outline. 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.
- bkeroack 12y ago
  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.
  - mattheath 12y ago
    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.
    - threeseed 12y ago
      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.
      - reality_czech 12y ago
        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.
sagichmal 12y ago
I don't think the idea is to recreate Finagle in Go, but to create a toolkit that solves the same set of problems that Finagle solves in Go. And I don't think the problem domain is intractably complex; I think we have enough collective operational experience to have informed opinions, and I think Go's type system may be sufficiently sophisticated to encode those opinions.
jbooth 12y ago
Could you provide examples (beyond generics) where 'composable complexity' helped finagle achieve a goal? My experience with Scala has been that an author's 'composable complexity' becomes a reader's 'wtf is this complexity'. Go's philosophy has been to avoid complexity altogether in most of the tools they give you, forcing you to write lowest-common-denominator code that anyone can easily understand. Generics are sorely missed, but I really don't see additional expressive power from most scala features, just additional things I need to keep in my head for an occasional 5-line savings in the middle of some method (which IMO doesn't change the complexity equation at all). Would love to see some beautiful examples that change my mind.
- Zikes 12y ago
  Go libraries are typically highly composable because they operate mostly on primitives or strictly defined common interfaces. Orthogonality is a key feature.
  - bsaul 12y ago
    I agree with you completely, yet what could prevent the gokit team from starting with the definition of very simple , orthogonal, interfaces and maybe add the very few new types required, to immitate the go stdlib. I'm quite sure the result will be quite different from what those kind of frameworks look like in other languages, but that could be interesting still.
    - Zikes 12y ago
      That's what I'm hoping for. I imagine many of the services could be designed in a manner similar to database/sql, with its driver interfaces.
  - codygman 12y ago
    If I recall correctly those libraries aren't type safe and composable, but perhaps I'm remembering wrong.
    - 12y ago
eternalban 12y ago
Go, as of today, is a tailors language. (For context: C#, Java, Scala, etc. are plumbers' tools. And tailoring requires far more élan than plumbing.) My recommendation to the Gophers is to replicate OTP and definitely figure out dynamic linking. The criticism of the OP are legitimate.
eweise 12y ago
I would say one of the benefits of Scala is that it allows greater abstraction than some other languages which can provide more clarity. Example a service in Finagle is defined as; Request => Future[Response] I don't know what the equivalent would be in Go but I can't imagine its any clearer than this.
- riobard 12y ago
  type Service interface { Handle(req Request) Response }
  - frowaway001 12y ago
    Now make Request and Response generic so that you can tell different requests and responses apart. Then make Future generic so that you can use all the existing combinators out there, like `sequence` which turns `List[Future[Response]]` into a Future[List[Response]]`.
    - Zikes 12y ago
      Your reply actually highlights one of the key features of Go: if you design it right using channels, constructs like Futures and Promises aren't necessary.
      - codygman 12y ago
        > design it right using channels, constructs like Futures and Promises aren't necessary Careful implying that using futures and promises are incorrect unless you can prove that channels can do anything futures and promises can do while doing it better. Do you have any examples?
        Zikes 12y ago
        In Go they are incorrect at worst, not idiomatic at best. That's due to the nature of the language as channels are built-in primitives capable of fulfilling the roles of either, not a slight on the efficacy of the constructs themselves. http://golang.org/doc/effective_go.html#channels http://golang.org/doc/effective_go.html#channels

frowaway001 12y ago

Go has basically none of the mechanisms for sanely creating composable complexity that Scala has. It makes me really grossed out to think about something with the complexity that Finagle exposes as a Go library. Go is all about small, sturdy tools that work for most of the cases most of the time and that compose well with each other - IF - they are built into the standard library. And if it's not, have fun spending your time writing uni-typed interfaces for any kind of interop with desired complexity. Go is great for writing dead simple byte slingers, pipelines that will be rigid in the most dynamic possibility, guns that shoot JS and interact with services, etc. That's simply not Finagle. A thousand times this.

tekacs 12y ago

I didn't mention in it my sibling post here, but we started writing the core of wym (our microservices framework) in Go, then Node.js and finally settled on Scala for exactly the reasons you outline. 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.

bkeroack 12y ago
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.
- mattheath 12y ago
  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.
  - threeseed 12y ago
    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.
    - reality_czech 12y ago
      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.

sagichmal 12y ago

I don't think the idea is to recreate Finagle in Go, but to create a toolkit that solves the same set of problems that Finagle solves in Go. And I don't think the problem domain is intractably complex; I think we have enough collective operational experience to have informed opinions, and I think Go's type system may be sufficiently sophisticated to encode those opinions.

jbooth 12y ago

Could you provide examples (beyond generics) where 'composable complexity' helped finagle achieve a goal? My experience with Scala has been that an author's 'composable complexity' becomes a reader's 'wtf is this complexity'. Go's philosophy has been to avoid complexity altogether in most of the tools they give you, forcing you to write lowest-common-denominator code that anyone can easily understand. Generics are sorely missed, but I really don't see additional expressive power from most scala features, just additional things I need to keep in my head for an occasional 5-line savings in the middle of some method (which IMO doesn't change the complexity equation at all). Would love to see some beautiful examples that change my mind.

Zikes 12y ago
Go libraries are typically highly composable because they operate mostly on primitives or strictly defined common interfaces. Orthogonality is a key feature.
- bsaul 12y ago
  I agree with you completely, yet what could prevent the gokit team from starting with the definition of very simple , orthogonal, interfaces and maybe add the very few new types required, to immitate the go stdlib. I'm quite sure the result will be quite different from what those kind of frameworks look like in other languages, but that could be interesting still.
  - Zikes 12y ago
    That's what I'm hoping for. I imagine many of the services could be designed in a manner similar to database/sql, with its driver interfaces.
- codygman 12y ago
  If I recall correctly those libraries aren't type safe and composable, but perhaps I'm remembering wrong.
  - 12y ago

eternalban 12y ago

Go, as of today, is a tailors language. (For context: C#, Java, Scala, etc. are plumbers' tools. And tailoring requires far more élan than plumbing.) My recommendation to the Gophers is to replicate OTP and definitely figure out dynamic linking. The criticism of the OP are legitimate.

eweise 12y ago

I would say one of the benefits of Scala is that it allows greater abstraction than some other languages which can provide more clarity. Example a service in Finagle is defined as; Request => Future[Response] I don't know what the equivalent would be in Go but I can't imagine its any clearer than this.

riobard 12y ago
type Service interface { Handle(req Request) Response }
- frowaway001 12y ago
  Now make Request and Response generic so that you can tell different requests and responses apart. Then make Future generic so that you can use all the existing combinators out there, like `sequence` which turns `List[Future[Response]]` into a Future[List[Response]]`.
  - Zikes 12y ago
    Your reply actually highlights one of the key features of Go: if you design it right using channels, constructs like Futures and Promises aren't necessary.
    - codygman 12y ago
      > design it right using channels, constructs like Futures and Promises aren't necessary Careful implying that using futures and promises are incorrect unless you can prove that channels can do anything futures and promises can do while doing it better. Do you have any examples?
      - Zikes 12y ago
        In Go they are incorrect at worst, not idiomatic at best. That's due to the nature of the language as channels are built-in primitives capable of fulfilling the roles of either, not a slight on the efficacy of the constructs themselves. http://golang.org/doc/effective_go.html#channels http://golang.org/doc/effective_go.html#channels