4 ms·

I always dreamed of something like this where functions could be called as normal but they could be an RPC behind the scenes. The compiler would take care of se

I always dreamed of something like this where functions could be called as normal but they could be an RPC behind the scenes. The compiler would take care of serialization/deserialization and routing. But how is it possible to not worry about network. Every function is now able to fail. Why don't you need to handle this explicitly? Or is there just a default behaviour that can be overriden? Edit: after reading the docs I think I understand a bit more. You'll have have to deal with network errors on anything crossing module boundaries.

whalesalad 4y ago
Erlang/Elixir does this!
qfg77 4y ago
I think it's safe to say that this doesn't go as far as the dream. In addition to functions failing, you can't share memory between functions etc. With Service Weaver, you have to be aware that you're writing a distributed application, but you get to write it as a single binary. So it's not as magical as it can be, but it improves on the status quo.
eliben 4y ago
You do have to worry about the network when you call between components. The documentation talks about this explicitly in "Semantics": "Method calls are executed with at-most-once semantics. This means that Service Weaver does not automatically retry method calls that fail. However, you can detect and retry failed method calls explicitly using weaver.ErrRetriable. If a method call fails because of a transient system error (e.g., a component replica crashed, the network is partitioned), it returns an error with an embedded weaver.ErrRetriable." With the following example: // Retry the cache.Get method call up to five times. var val string var err error for i := 0; i < 5; i++ { val, err = cache.Get(ctx, "key") if errors.Is(err, weaver.ErrRetriable) { // Retriable system error! Retry. continue } break } [The docs at https://serviceweaver.dev/docs.html https://serviceweaver.dev/docs.html are fairly comprehensive, kudos to the team!]
- gedw99 4y ago
  Thanks for this as I was also wondering about network partitioning, and all those failure fun and games that distributed systems must handle. This golang package helps to remedy that by providing a bus / messsge queue that can run in process or over the network. So you get rpc without thinking about it and failure is managed by the data plane forwarding the message when the network is healthy again. https://github.com/suborbital/e2core/blob/main/foundation/bus/README.md https://github.com/suborbital/e2core/blob/main/foundation/bu... This however forces all other code using a package like this to adapt to the realities that you’re in an async non blocking world now. A rpc call will give you a response eventually. So the calling func and all parent funcs will just have to wait around when the network is unhealthy?
waynesonfire 4y ago
You're dreaming of Erlang and it's brilliant use of actors and supervisors to manage failures to make it work.
- gedw99 4y ago
  That raced through my mind as I read their docs also. https://github.com/orgs/ergo-services/repositories https://github.com/orgs/ergo-services/repositories Is erlang written in golang. The examples are great and clearly shows what it offers in terms of failure scenarios that it handles. Supervisors tress etc. Weaver with ergo would be a nice mix ? You don’t specify your physical topology in code but instead at deployment time. Weaver gke but written for ergo where the Trees are decided at deployment time perhaps.
another2another 4y ago
In the old days, Microsoft encouraged people to do exactly that with their COM based applications, where a software component could be transparently migrated to another machine via DCOM. The original application needn't care where the component was now running since it's location in the universe was controlled by the registry. You could now scale your big fat client app out to many servers. What was once slow and bloated on the client machine could suddenly become fast and nimble on the 'high powered' server(s). Needless to say this caused, firstly much excitement among VB devs, and selling of Windows NT 4 Server licenses, soon followed by consternation and disappointment. Turns out: - software design of components running locally, and components running remotely should be approached in veeery different ways. e.g. making 100 property assignments on a component running in your local process space is just fine, but doing that on an object that exists on a server 100 miles of copper away has very different performance characteristic. Apps were suddenly unresponsive in many different and frustrating ways. - massively increasing the network load as storms of calls and responses to the servers just to display a form, and big round-trips of data that never existed before strained existing infrastructure. E.g. previously the db would fill the GUIs data grid directly with a query. Now... the gui would call the server component, which would get the data, then it would serialize that data into a different form (for ADO) and send it via DCOM to the GUI which would show 10,000 rows. All very slowly. - massive increase in load on the domain controller, as GUI apps happily created and destroyed objects that used to be local, now they resulted in a DCOM call to create the object which required security checks that were never needed before. Saw this bring domain controllers to their knees. - As you said, applications could suddenly fail in new and exciting ways since they're now on the network and that entailed a whole new set of failures to be aware of. - massively increased complexity in installation and configuration, since every little service had to be configured and installed in its own unique way. Security also became harder since permissions per-service (e.g. db permission, filesystem permissions) also had to be managed. Microsoft tried to help with MTS (their transaction service to host DCOM components), but by that time (early 2000's) people were already exploring web applications as the replacement for fat client apps and migrating away from this approach. >I always dreamed of something like this where functions could be called as normal but they could be an RPC behind the scenes. >The compiler would take care of serialization/deserialization and routing. You can still do it today if you want, just investigate COM+ if you're on Windows. It's not the compiler that decides whether RPC is needed, but the COM runtime (via the Registry). It's all still there.

whalesalad 4y ago

Erlang/Elixir does this!

qfg77 4y ago

I think it's safe to say that this doesn't go as far as the dream. In addition to functions failing, you can't share memory between functions etc. With Service Weaver, you have to be aware that you're writing a distributed application, but you get to write it as a single binary. So it's not as magical as it can be, but it improves on the status quo.

eliben 4y ago

You do have to worry about the network when you call between components. The documentation talks about this explicitly in "Semantics": "Method calls are executed with at-most-once semantics. This means that Service Weaver does not automatically retry method calls that fail. However, you can detect and retry failed method calls explicitly using weaver.ErrRetriable. If a method call fails because of a transient system error (e.g., a component replica crashed, the network is partitioned), it returns an error with an embedded weaver.ErrRetriable." With the following example: // Retry the cache.Get method call up to five times. var val string var err error for i := 0; i < 5; i++ { val, err = cache.Get(ctx, "key") if errors.Is(err, weaver.ErrRetriable) { // Retriable system error! Retry. continue } break } [The docs at https://serviceweaver.dev/docs.html https://serviceweaver.dev/docs.html are fairly comprehensive, kudos to the team!]

gedw99 4y ago
Thanks for this as I was also wondering about network partitioning, and all those failure fun and games that distributed systems must handle. This golang package helps to remedy that by providing a bus / messsge queue that can run in process or over the network. So you get rpc without thinking about it and failure is managed by the data plane forwarding the message when the network is healthy again. https://github.com/suborbital/e2core/blob/main/foundation/bus/README.md https://github.com/suborbital/e2core/blob/main/foundation/bu... This however forces all other code using a package like this to adapt to the realities that you’re in an async non blocking world now. A rpc call will give you a response eventually. So the calling func and all parent funcs will just have to wait around when the network is unhealthy?

waynesonfire 4y ago

You're dreaming of Erlang and it's brilliant use of actors and supervisors to manage failures to make it work.

gedw99 4y ago
That raced through my mind as I read their docs also. https://github.com/orgs/ergo-services/repositories https://github.com/orgs/ergo-services/repositories Is erlang written in golang. The examples are great and clearly shows what it offers in terms of failure scenarios that it handles. Supervisors tress etc. Weaver with ergo would be a nice mix ? You don’t specify your physical topology in code but instead at deployment time. Weaver gke but written for ergo where the Trees are decided at deployment time perhaps.

another2another 4y ago

In the old days, Microsoft encouraged people to do exactly that with their COM based applications, where a software component could be transparently migrated to another machine via DCOM. The original application needn't care where the component was now running since it's location in the universe was controlled by the registry. You could now scale your big fat client app out to many servers. What was once slow and bloated on the client machine could suddenly become fast and nimble on the 'high powered' server(s). Needless to say this caused, firstly much excitement among VB devs, and selling of Windows NT 4 Server licenses, soon followed by consternation and disappointment. Turns out: - software design of components running locally, and components running remotely should be approached in veeery different ways. e.g. making 100 property assignments on a component running in your local process space is just fine, but doing that on an object that exists on a server 100 miles of copper away has very different performance characteristic. Apps were suddenly unresponsive in many different and frustrating ways. - massively increasing the network load as storms of calls and responses to the servers just to display a form, and big round-trips of data that never existed before strained existing infrastructure. E.g. previously the db would fill the GUIs data grid directly with a query. Now... the gui would call the server component, which would get the data, then it would serialize that data into a different form (for ADO) and send it via DCOM to the GUI which would show 10,000 rows. All very slowly. - massive increase in load on the domain controller, as GUI apps happily created and destroyed objects that used to be local, now they resulted in a DCOM call to create the object which required security checks that were never needed before. Saw this bring domain controllers to their knees. - As you said, applications could suddenly fail in new and exciting ways since they're now on the network and that entailed a whole new set of failures to be aware of. - massively increased complexity in installation and configuration, since every little service had to be configured and installed in its own unique way. Security also became harder since permissions per-service (e.g. db permission, filesystem permissions) also had to be managed. Microsoft tried to help with MTS (their transaction service to host DCOM components), but by that time (early 2000's) people were already exploring web applications as the replacement for fat client apps and migrating away from this approach. >I always dreamed of something like this where functions could be called as normal but they could be an RPC behind the scenes. >The compiler would take care of serialization/deserialization and routing. You can still do it today if you want, just investigate COM+ if you're on Windows. It's not the compiler that decides whether RPC is needed, but the COM runtime (via the Registry). It's all still there.