d
Untitled
r
In its defense. I read this and I see this similar to what Unison or Haskell Transient support. That is encode a program as if it was in process because there is either a DSL or lang support for remote function one can invoke disregarding the details of the transport or network layer between local and remote functions. Also what others are trying to push with server-less. I’d love if Kotlin had transparent remoting functions and interfaces to hook providers and other vendors. Most new research in langs in session types and remoting shows our langs are tending toward abstracting away without having to acknowledge we are sending and serializing data back and forth. The cons is that this can also be accomplished with libraries and the design space is still too in early evolution and adopting a feature like this in a lang would only work in such a way that is generic enough to cover future use cases or under a experimental flag like contracts. I see something like:
Copy code
suspend remote fun doInRemote(arg: Int): Int {
  ... remote combinators or contract dsl to show where the config or endpoint is
}
This would remove the need to choose Json, Avro, Protobuffers, etc or any network serialization concerns as long as your client and server are both written in Kotlin and it would require some runtime in the suspension intrinsics in the stdlib so libs could integrate with this new type of continuation. It could probably kill many libs and popular frameworks that are mostly utilized to create webservices. I would be interested in such a feature because remoting functions are effect monads and Arrow already provides the infrastructure to build a simple webservice in a cluster if remoting functions were available with a simple integration that would be powerful in pushing Kotlin backend too to new layers because you can teach distributed computing with the lang features instead of vendors that go out of date every few years.
👍 2
d
Yes this is not a new concept -- or implementation. Im 'on the fence' as to opinion of if this kind of 'feature' is better implemented i the language or in a library -- I dont think it matters much if it can be done at all -- co routines are a good example of minimal language dependency ( as C was in minimal compiler builtin dependencies, in its day it was 'unheard of' to NOT have IO operations part of the language )