You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My understanding is that the high-level differences between proto-lens and proto3-suite are:
proto-lens is works as a protoc plugin and proto3-suite does not
The proto-lens-protoc package provides a proto-lens-protoc executable that you can pass as a protoc plugin, whereas proto3-suite provides a compile-proto-file standalone executable
We consider this a mistake in the design of proto3-suite and we think that it should be fixed to also work as a protoc plugin
proto3-suite provides gRPC support and proto-lens does not
This is powered by the gRPC-haskell library, which is a Haskell binding to the C library for grpc
We also think that this should change in the long run. When we authored gRPC-haskell there was not yet an HTTP2 client package available, which is why we resorted to reusing the C library. Now that there is the http2-client package we think a Haskell-native implementation of gRPC is the better approach (mainly for improved concurrency performance and reliability)
proto-lens is on Hackage and proto3-suite is not
The main reason that proto3-suite is not on Hackage is because of our reservations about the
above two issues
That means that there are other Hackage libraries that build on top of proto-lens, which you can find here:
There are also differences in the API that each library presents, but I think the above three differences are key reasons that drive people to adopt one package over the other
Would be nice to know the difference vs https://hackage.haskell.org/package/proto-lens.
+@judah
The text was updated successfully, but these errors were encountered: