-
Notifications
You must be signed in to change notification settings - Fork 17.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: freeze net/rpc #16844
Comments
retiring jsonrpc too? |
No. JSON-RPC is at least kinda an external spec. Let's not conflate the two here. |
Whats the problem with TLS? Been using the Package with TLS and jsonrpc for Could someone please formalise the term "freeze". the suggested link into On 23 August 2016 at 02:28, Rob Pike notifications@github.com wrote:
|
I'm in favor of the proposal for the following reason,
Also because the standard library where its API cannot evolve is not a good place for it. But I think the value of the following fact is significantly understated.
So I think that grpc is not a viable alternative for anyone who wants to preserve that property. It's a fine suggestion for many. But, a more |
I agree with @shurcooL that the value of using Go native types without an IDL is very high, even if just for introductory and prototype purposes. I would hate to see net/rpc removed because it was difficult to satisfy some sophisticated use cases. Maybe it can just be frozen, and appropriate warnings issued in the package documentation? edit: I misinterpreted retired as removed; mea culpa |
Nobody is proposing violating the Go 1 compatibility promise and removing anything. |
Exactly. As I wrote, "the proposal is to freeze the package". |
The following anecdotes of my experience with net/rpc and GRPC only makes sense if my understanding that freezing net/rpc would impact the growth of net/rpc/jsonrpc is correct? If not, I just wasted 15 minutes writing this. Here goes: I have worked with both net/rpc/jsonrpc and grpc in my projects. Incidentally both use cases were: Go server <-> JSON RPC Java Client. The first use case was to net/rpc/jsonrpc on localhost for automation testing of a phone (uiautomator) and second was a proper Android app using GRPC's streaming capabilities. In my experience, setting up net/rpc/jsonrpc was trivial, and there was enough Java JSONRPC support to be found while GRPC took a bit of work setting up.
I guess points 2 & 3 stem from the fact that there hasn't been enough work on GRPC to form a standard body of work. Also I realise 2 & 3 are client issues but when you choose GRPC the client libraries get chosen for you by default. net/rpc/jsonrpc provides a lot of flexibility of choice while picking a client library and is quicker and easier to use. |
False. See the first two replies in this thread. |
SGTM on freezing net/rpc. The net/rpc code is nice and simple. The interfaces are well designed. I use net/rpc with proto codecs to avoid the complexity and dependencies of grpc. Like rhedile mentioned TLS can be used without much difficulty. Freezing doesn't effect these use cases. |
We are currently using Are there any performance comparisons between (BTW there are huge gaps between C++ at 250K QPS/sec vs Java at 150K QPS/sec vs C# at 20K QPS/sec -- especially the last two I would expect to be similar. And these are all async calls, in our case we'd be using synchronous calls). |
We've done (using https://github.com/minio/dsync) some performance comparisons between The following table lists the results of a test with 8 EC2 servers that shows that
To verify that the actual (distributed) locking functionality is not influencing the tests negatively, we repeated the measurements without any server side logic (all code commented out) which gave these results (note that a single lock takes 16 messages, namely 8 locks plus 8 unlocks):
Again the We also found another reference graph that shows "Go sync" performance: https://performance-dot-grpc-testing.appspot.com/explore?dashboard=5760820306771968&widget=828849126&container=1808124444 So it looks like Are there any plans to bring the performance of |
@fwessels it would be interesting to see the performance difference with grpc using the serialization code generated by https://github.com/gogo/protobuf -- I think it'll show that grpc has lots of potential to get optimized |
@pkieltyka I would doubt whether this would make a big difference as the arguments in the test are really simple (just a string in and bool as return value). Do you have an idea how much difference it could make? |
Perhaps I'm missing something, but is it not as simple as using either Accept or ServeConn with a TLS net.Listener or TLS net.Conn?
As you said, nice API, no need for an IDL or other dependencies, and I would add simple, composable, and powerful. It's among the easiest RPC mechanisms to implement for Go, scales well, and achieves high throughput with low latency. grpc to me isn't really an alternative as it's design is focused on completely different goals. grpc provides many additional capabilities, but at the cost of the things that make net/rpc desirable. |
I am confused by the difference between 'deprecate' and 'freeze', is there any formality about these terms. I would typically see deprecation as frozen hoping for the ability to remove at some future time. The complaint about https is only partly valid, I agree it is annoying to find the recipe but once found does not change much - this could be added to the examples. I agree with others that that net/rpc is lightweight fast simple and serves many scenarios well. I have not suffered from any of what @robpike refers to as "outstanding bugs that are hard to fix," so would be happy for these to be migrated to documented known limitations, and avoid going to any great lengths to fix these bugs. for the reasons @robmccoll mentions I think it would be wrong to encourage folk to use alternatives like GRPC in place of net/rpc and the word 'deprecate' would discourage the otherwise perfectly sensible use of this simple useful package. |
I think everybody only means "freeze". |
Freeze it! |
CL https://golang.org/cl/32112 mentions this issue. |
The package has outstanding bugs that are hard to fix, and cannot support TLS without major work. So although it has a nice API and allows one to use native Go types without an IDL, it should probably be retired.
The proposal is to freeze the package, retire the many bugs filed against it, and add documentation indicating that it is frozen and that suggests alternatives such as GRPC.
The text was updated successfully, but these errors were encountered: