4 ms·

Yes, we've been very happy with Barrister so far, in that it provides a simple syntax for RPC definitions that looks very similar to Java so is not hard to lear

by mands 11y ago

Yes, we've been very happy with Barrister so far, in that it provides a simple syntax for RPC definitions that looks very similar to Java so is not hard to learn. And yes, keeping it similar to standard function/object calls lowers the cognitive load. Hmm, yep recursion not supported atm, although we are thinking of extending the basic system shortly - there are a lot of other features we'd like to add - true sum types, a dynamic operator, and more. Python annotations are nice, and a lot of users have asked for a way to annotate RPC functions in their code. Doing this all in a cross-language way will be hard and so we're thinking of keeping the external definition in the meantime. -- Thanks so much for your advice. We're certainly looking at past attempts, and the research in transferring data is vast - I think it boils down to a trade-off between expression and usability - and for now JSON seems to have found pretty good sweet spot. Perhaps with just a simple schema layer on top that will be suitable for most use-cases. I imagine Thrift, ProtoBufs, etc will always beat it on speed, XML (+XML Schema) on expressibility, etc. For us, as you have guessed, we are just trying to make it as easy as possible for the majority of users – particularly web and mobile developers. This does also mean we're trying to stay language agnostic and find a type subset that works across most languages - JSON primitives let us get some of the way there. Thank you so much for all your advice - it's been so helpful and we're really happy you took the time out to try it all and record your thoughts. Would love to chat further - please feel free to drop me an email at HNusername @stackhut.com.

deleted 11y ago
[deleted]
hyperpallium 11y ago
Do you find recursive types are needed in practice, for RPC? JSON lacks references (so it's an object tree, not a graph), but that hasn't stopped adoption... What's a "dynamic operator" in this context? --- > The first RPC was great and CORBA came and went, following this the perception was that it was utterly unsuitable for anything, until perhaps the introduction of ProtoBufs, Thift, JSON-RPC and so on. I personally think it can be incredibly useful, but deciding on just the right features to keep things manageable is incredibly difficult (more so than the tech itself I believe). [from your grandparent comment] Yes, there's something in this space, but I'm not sure exactly what it is. Historically (there's pre-OOP papers on this), making the network invisible seemed really cool (still does!), but then all the Network Fallacies (https://wikipedia.org/wiki/Fallacies_of_distributed_computing https://wikipedia.org/wiki/Fallacies_of_distributed_computin...) got you. I think we've made real progress in general, e.g. JS programmers use async callbacks routinely, and there's promises; http is about dealing with the network. Not only is the tech worked out, but, perhaps more importantly, many coders are familiar with it. Whereas CORBA's superficial design defects (confusing API) obscured its fundamental design defects (distributed objects). > trade-off between expression and usability - and for now JSON seems to have found pretty good sweet spot. Perhaps with just a simple schema layer on top that will be suitable for most use-cases. Good summary!

by mands 11y ago

deleted 11y ago

[deleted]

hyperpallium 11y ago

Do you find recursive types are needed in practice, for RPC? JSON lacks references (so it's an object tree, not a graph), but that hasn't stopped adoption... What's a "dynamic operator" in this context? --- > The first RPC was great and CORBA came and went, following this the perception was that it was utterly unsuitable for anything, until perhaps the introduction of ProtoBufs, Thift, JSON-RPC and so on. I personally think it can be incredibly useful, but deciding on just the right features to keep things manageable is incredibly difficult (more so than the tech itself I believe). [from your grandparent comment] Yes, there's something in this space, but I'm not sure exactly what it is. Historically (there's pre-OOP papers on this), making the network invisible seemed really cool (still does!), but then all the Network Fallacies (https://wikipedia.org/wiki/Fallacies_of_distributed_computing https://wikipedia.org/wiki/Fallacies_of_distributed_computin...) got you. I think we've made real progress in general, e.g. JS programmers use async callbacks routinely, and there's promises; http is about dealing with the network. Not only is the tech worked out, but, perhaps more importantly, many coders are familiar with it. Whereas CORBA's superficial design defects (confusing API) obscured its fundamental design defects (distributed objects). > trade-off between expression and usability - and for now JSON seems to have found pretty good sweet spot. Perhaps with just a simple schema layer on top that will be suitable for most use-cases. Good summary!