Support for other languages (Dart, Java, etc.)

428 views
Skip to first unread message

Richard Conway

unread,
Mar 5, 2023, 12:13:12 PM3/5/23
to Service Weaver
I think Service Weaver is a genius idea and addresses some of the major drawbacks of microservice development.  Do you have plans to add support for additional languages? Specifically, Dart, Java and/or Kotlin? If so, what does the timeline look like? I'd love to try Service Weaver, but would prefer to stick with languages I know, plus it would open up the project to many more developers.

Thanks and good luck!
Richard Conway

Srdjan Petrovic

unread,
Mar 5, 2023, 1:17:34 PM3/5/23
to Service Weaver
Hi Richard,

We would love to support more languages and clouds/deployers. The ideal situation is one where we focus on adding more languages, while the community helps us build and maintain deployers.

Our first ticket item going forward is allowing two different Service Weaver apps to discover and talk to each other more easily. After that, we'll start looking at adding more languages. Java/Kotlin seem like more likely candidates than Dart. I'm not familiar with Kotlin, but does it have a way of interpreting the program (like a pre-compile step, which we need to generate the client/server stubs)? I'm assuming that with Java this is trickier.

Thanks,
-Srdjan

Richard Conway

unread,
Mar 8, 2023, 12:04:43 PM3/8/23
to Srdjan Petrovic, Service Weaver
Hi Srdjan,
Just saw your email - got sent to spam.  Thanks for getting back to me.  Java/Kotlin are very similar, both running on the JVM and both of which can interpret at run time or be pre-compiled.  Kotlin is a more modern take on Java, reducing boiler plate and including features to make coding easier, more secure, easier to maintain.  But the number of Java developers is still much bigger, so if you want to grow the ecosystem, you can go with Java first. Kotlin programs can mix in Java libraries.  

I haven't had time to dig into the Service Weaver source yet, but from context it seems like you might be leveraging Google's ProtoBuf framework for passing data between services.  Is this correct? I know it generates stubs for passing data for many different languages. 

I'll start looking into what it takes to build deployers to see if I find a match that I can work on.

Regards,
Richard 

--
You received this message because you are subscribed to a topic in the Google Groups "Service Weaver" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/serviceweaver/IXcNidiiz8M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to serviceweave...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/serviceweaver/2f6bf43d-035b-4791-b9e0-9284496f906an%40googlegroups.com.

Srdjan Petrovic

unread,
Mar 8, 2023, 12:48:37 PM3/8/23
to Richard Conway, Service Weaver
Thanks, Richard.

As an aside, we don't use Protos under the hood. We rely on language-native types that can be serialized. Java's Serializable may work well here.

Similarly, we don't ask the developer to declare their services as gRPC services. Instead, the developer writes a native class/type and registers it with Service Weaver. For Java, this would be a Java abstract class, with methods declared on it. Each method essentially corresponds to a RPC call. 

Service Weaver then needs to inspect the source code, find all of the Java abstract classes that are associated with it, and auto-generate RPC stubs that correspond to those abstract classes' methods.

I wasn't sure if this is something that Java/Kotlin support? Languages like Go and Python allow this level of source code inspection.

Richard Conway

unread,
Mar 9, 2023, 11:05:04 AM3/9/23
to Srdjan Petrovic, Service Weaver
Hi Srdjan,
Yes, Java and Kotlin have strong support for interpreting their own classes for methods.  It's called "reflection" in Java terminology.  It's baked into the capabilities of the language. So there shouldn't be any issues going that route, in fact it might be easier in Java/Kotlin than in Python and Go.

I was thinking that the developers would write native services and then  Service Weaver would analyze the classes and generate native gRPC stubs for them since gRPC has tools to generate native language stubs and that would be less work for you. Thanks for the clarification.

Really great idea. I've been avoiding micro-services because of all the downsides - which Service Weaver rectifies. 

Regards,
Richard Conway


超级无敌阳光帅气的二狗

unread,
Jul 12, 2023, 1:14:51 PM7/12/23
to Service Weaver
Will you consider supporting rust?

mwhittaker

unread,
Jul 12, 2023, 1:15:41 PM7/12/23
to Service Weaver
We don't have any short term plans to support rust, but in the future it is possible!

San Nguyen

unread,
Apr 5, 2024, 12:11:35 PMApr 5
to Service Weaver
Hi, is there any plan to support python?

rgrandl

unread,
Apr 10, 2024, 4:26:39 PMApr 10
to Service Weaver
Hi San,

There are some folks working on adding support for Python and Java. We will provide an update when it becomes readily available.

Thanks,
- Robert

Charlie La Mothe

unread,
Oct 3, 2024, 3:27:07 PMOct 3
to Service Weaver
Since language-native serialization and Kotlin have both been mentioned, these resources may be of interest:
This email, including its contents and any attachment(s), may contain confidential and/or proprietary information and is solely for the review and use of the intended recipient(s). If you have received this email in error, please notify the sender and permanently delete this email, its content, and any attachment(s). Any disclosure, copying, or taking of any action in reliance on an email received in error is strictly prohibited.
Reply all
Reply to author
Forward
0 new messages