6 ms·

Could you provide examples (beyond generics) where 'composable complexity' helped finagle achieve a goal? My experience with Scala has been that an author's 'c

by 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.
  - elithrar 12y ago
    > If I recall correctly those libraries aren't type safe and composable You may be confusing interfaces (which enforce type compatibility) and the empty interface{}, which is effectively a dynamic type in the Go world.
  - Zikes 12y ago
    They are type safe, except for the unsafe package but it's hard not to know what you're getting into with that one. One of the best examples of composability is the Reader and Writer interface. They're designed to operate on slices of bytes, so a package intended to read from a Reader can read from files, stdin, networks, sockets, and a myriad other systems with absolutely no changes to the package's code or its implementation.
    - codygman 12y ago
      How would you do decode this json in a type safe way using Go? {"purchaseType": "Rent","price": 0.99,"title": "inception"} Here is an implementation in Haskell: {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE OverloadedStrings #-} import Data.Aeson import GHC.Generics import qualified Data.ByteString.Lazy as BL data PurchaseType = Free | Rent | Buy | Subscriber deriving (Show, Generic) instance FromJSON PurchaseType instance ToJSON PurchaseType data Media = Media { title :: String, price :: Float, purchaseType :: PurchaseType} deriving (Show, Generic) instance FromJSON Media instance ToJSON Media jsonData = "{\"title\": \"inception\", \"price\": 0.99, \"purchaseType\": \"Rent\"}" main = print $ (decode jsonData :: Maybe Media) -- running main gets: -- λ> main -- Just (Media {title = "inception", price = 0.99, purchaseType = Rent}) EDIT: Spec Change, boss wants an order confirmation message! orderConfirmationMessage (Media mediaTitle _ Rent) = putStrLn ("Thanks for renting " ++ mediaTitle) Then we recompile and... what's this? Main.hs:19:1-100: Warning: … Pattern match(es) are non-exhaustive In an equation for ‘orderConfirmationMessage’: Patterns not matched: Media _ _ Free Media _ _ Buy Media _ _ Subscriber Good thing GHC had told us Free/Buy/Subscriber's needed messages instead of our boss! In fact, had I been using -Wall this would be a compile time error. Getting to the point, my real questions are: 1. What is Go's way of ensuring your function handles cases like this, or is there an idiomatic way of avoiding it? 2. How do you discern between MovieType's without resorting to just using Strings and compromising type safety?
jfoutz 12y ago
Clarity of thought is rare. The ability to express those thoughts as code is even more rare. Go's approach is to makes it easy to say certain things. Goroutines are great. But it also makes it difficult to say complicated things like List<T>. Good programmers suffer, but really it's just a few more keypresses, ala Java. Scala makes it possible to say even more abstract things like T<int>. Not many programmers can really explain a higher kinded type, or why such a thing is useful. Novice programmers say silly things because they don't really know how to apply all of this abstract power. Go is pretty wonderful because it lets programmers of varying ability work together effectively. Scala is teaching people new abstractions. Are they worth it? Maybe not in Scala. However, I think languages with powerful type systems will ultimately win, because you can lean hard on the compiler to guarantee correctness.
- reality_czech 12y ago
  You forgot the other drawbacks that complicated type systems have: hellish compiler messages and long compile times. Those don't go away just because you learn more about the language. I also dispute the idea that only novices abuse complicated type systems. Actually I think it's the reverse... only people who know the language well can create something truly horrible. Don't believe me? Look at any of the C++ STL header files and experience Biij. Of course, just because they can doesn't mean they will. But in a world dominated by people of average intelligence, working around the programming equivalent of a gas lamp with an open flame just isn't a good idea.
  - tekacs 12y ago
    > drawbacks that complicated type systems have: hellish compiler messages and long compile times Scala has incredibly nice compiler messages and you can see Rust for an example of a language with complex types and short compile times. These issues have _nothing_ to do with complicated type systems - you're projecting the failures of the C++ template system - failures which stem in fair part from the fact that it's not really a type system but simply a templater. Finally, it's worth recognising that Scala goes to lengths to keep messy features inside their own compilation unit - for example, macros appear as functions to the outside and complex features such as implicit conversions must be explicitly imported for use. I tried building our project in Go and Node.js explicitly to make it as easy as possible for people to contribute, irrespective of their background. It turned out that the additional complexity I had to pump into abstractions to make it happen made the code just as complex to understand. It's quite possible that projects just have a natural complexity level and it's worth picking the language to match. There are certainly different times for different languages.
bmdhacks 12y ago
Take a look at the Stack class (an example of a free monad) and how it's used to compose clients: https://github.com/twitter/finagle/blob/master/finagle-core/src/main/scala/com/twitter/finagle/Stack.scala https://github.com/twitter/finagle/blob/master/finagle-core/... https://github.com/twitter/finagle/blob/master/finagle-core/src/main/scala/com/twitter/finagle/client/StackClient.scala https://github.com/twitter/finagle/blob/master/finagle-core/... http://twitter.github.io/finagle/guide/Clients.html http://twitter.github.io/finagle/guide/Clients.html A client is a layer of various components like load balancers and stats recorders, but they're also all configurable. Only using the expressiveness of scala could such a data structure be created to compose all of these pieces, yet still keep them modifiable and type-safe.

by jbooth 12y ago

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.
- elithrar 12y ago
  > If I recall correctly those libraries aren't type safe and composable You may be confusing interfaces (which enforce type compatibility) and the empty interface{}, which is effectively a dynamic type in the Go world.
- Zikes 12y ago
  They are type safe, except for the unsafe package but it's hard not to know what you're getting into with that one. One of the best examples of composability is the Reader and Writer interface. They're designed to operate on slices of bytes, so a package intended to read from a Reader can read from files, stdin, networks, sockets, and a myriad other systems with absolutely no changes to the package's code or its implementation.
  - codygman 12y ago
    How would you do decode this json in a type safe way using Go? {"purchaseType": "Rent","price": 0.99,"title": "inception"} Here is an implementation in Haskell: {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE OverloadedStrings #-} import Data.Aeson import GHC.Generics import qualified Data.ByteString.Lazy as BL data PurchaseType = Free | Rent | Buy | Subscriber deriving (Show, Generic) instance FromJSON PurchaseType instance ToJSON PurchaseType data Media = Media { title :: String, price :: Float, purchaseType :: PurchaseType} deriving (Show, Generic) instance FromJSON Media instance ToJSON Media jsonData = "{\"title\": \"inception\", \"price\": 0.99, \"purchaseType\": \"Rent\"}" main = print $ (decode jsonData :: Maybe Media) -- running main gets: -- λ> main -- Just (Media {title = "inception", price = 0.99, purchaseType = Rent}) EDIT: Spec Change, boss wants an order confirmation message! orderConfirmationMessage (Media mediaTitle _ Rent) = putStrLn ("Thanks for renting " ++ mediaTitle) Then we recompile and... what's this? Main.hs:19:1-100: Warning: … Pattern match(es) are non-exhaustive In an equation for ‘orderConfirmationMessage’: Patterns not matched: Media _ _ Free Media _ _ Buy Media _ _ Subscriber Good thing GHC had told us Free/Buy/Subscriber's needed messages instead of our boss! In fact, had I been using -Wall this would be a compile time error. Getting to the point, my real questions are: 1. What is Go's way of ensuring your function handles cases like this, or is there an idiomatic way of avoiding it? 2. How do you discern between MovieType's without resorting to just using Strings and compromising type safety?

jfoutz 12y ago

Clarity of thought is rare. The ability to express those thoughts as code is even more rare. Go's approach is to makes it easy to say certain things. Goroutines are great. But it also makes it difficult to say complicated things like List<T>. Good programmers suffer, but really it's just a few more keypresses, ala Java. Scala makes it possible to say even more abstract things like T<int>. Not many programmers can really explain a higher kinded type, or why such a thing is useful. Novice programmers say silly things because they don't really know how to apply all of this abstract power. Go is pretty wonderful because it lets programmers of varying ability work together effectively. Scala is teaching people new abstractions. Are they worth it? Maybe not in Scala. However, I think languages with powerful type systems will ultimately win, because you can lean hard on the compiler to guarantee correctness.

reality_czech 12y ago
You forgot the other drawbacks that complicated type systems have: hellish compiler messages and long compile times. Those don't go away just because you learn more about the language. I also dispute the idea that only novices abuse complicated type systems. Actually I think it's the reverse... only people who know the language well can create something truly horrible. Don't believe me? Look at any of the C++ STL header files and experience Biij. Of course, just because they can doesn't mean they will. But in a world dominated by people of average intelligence, working around the programming equivalent of a gas lamp with an open flame just isn't a good idea.
- tekacs 12y ago
  > drawbacks that complicated type systems have: hellish compiler messages and long compile times Scala has incredibly nice compiler messages and you can see Rust for an example of a language with complex types and short compile times. These issues have _nothing_ to do with complicated type systems - you're projecting the failures of the C++ template system - failures which stem in fair part from the fact that it's not really a type system but simply a templater. Finally, it's worth recognising that Scala goes to lengths to keep messy features inside their own compilation unit - for example, macros appear as functions to the outside and complex features such as implicit conversions must be explicitly imported for use. I tried building our project in Go and Node.js explicitly to make it as easy as possible for people to contribute, irrespective of their background. It turned out that the additional complexity I had to pump into abstractions to make it happen made the code just as complex to understand. It's quite possible that projects just have a natural complexity level and it's worth picking the language to match. There are certainly different times for different languages.

bmdhacks 12y ago

Take a look at the Stack class (an example of a free monad) and how it's used to compose clients: https://github.com/twitter/finagle/blob/master/finagle-core/src/main/scala/com/twitter/finagle/Stack.scala https://github.com/twitter/finagle/blob/master/finagle-core/... https://github.com/twitter/finagle/blob/master/finagle-core/src/main/scala/com/twitter/finagle/client/StackClient.scala https://github.com/twitter/finagle/blob/master/finagle-core/... http://twitter.github.io/finagle/guide/Clients.html http://twitter.github.io/finagle/guide/Clients.html A client is a layer of various components like load balancers and stats recorders, but they're also all configurable. Only using the expressiveness of scala could such a data structure be created to compose all of these pieces, yet still keep them modifiable and type-safe.