Using two different languages where one would suffice for the task (microservices)

Question

I previously asked this on StackOverflow, but doesn't fit there and I was suggested to move it here.

I was thinking about using two seperate backend languages for seperating concerns in a project of mine. Another reason would be learning.

One backend would be a local windows service working with a special/proprietary interface in C#, another backend would be a webserver, which transforms UI interactions into the appropriate format for the local service.

I could obviously write both of those things in C# and it would be totally feasable, but I was looking for a reason to learn Go. However, I'd end up writing two seperate services in different languages, one for handling the webserver, another for handling the proprietary interface. In essence, those are two mini-projects which end up interacting with another.

I am unable to write the propriatary service in Go, because it's using a framework that's already written in C# and I'd have to rewrite said framework.

I thought it wouldn't cause much problems doing it this way for the sake of learning, because I'm seperating concerns in my point of view.

• One service only handles the webserver and is responsible for properly passing data to the internal service.
• The internal service only handles incoming data and does its proprietary thing.

IMO, changes to the webserver are now independent to the proprietary local server, as long as the format of interaction doesn't change.

I was wondering, is this approach a good or applicable idea or am I making the project just worse than I am able to anticipate at the moment?

Obviously, the question is a bit subjective, but I don't have the experience to properly answer it, so I came here.

A few other questions I have:

• What kind of problems might I run into, using this approach?
• How can I evaluate the effectiveness of such an approach?
• What metrics can I look at, to form a decision?

The idea being: Using two different languages, where one would suffice for the task, for the sake of learning, but (kind of) also for the sake of seperating concerns.

Go has benefits in readability and simplicity, making the development of the webserver easier. C# simply is the language used in the propriatary framework I'm using, thus it is easier to write the internal service with it, because I can use the framework natively. If I were to use C# only, I'd be simply adding a webserver-service to the project which talks to the propriatary one.

Here's a little diagram:

Answer 1

In general I would recommend keeping the number of languages in a solution to a minimum when you are working with a team. Mainly because you minimize the likelihood that the one person who introduced the language is the only one who updates the service. Don't get me wrong, Go is a great language, and I wholly advocate learning it.

I'm struggling to see the separate purpose of the second service in the opening post. At some point you still need to have a means of the Go service to communicate with the C# service, so restricting Go to just being the webserver portion is adding complexity without getting much benefit.

Now, if you were to have a GraphQL layer implemented in Go, that interacted with your C# service, then I can see something you can build on... particularly in a microservice based infrastructure. GraphQL is designed to treat your data like a graph, so you can query for just the records you need, and only pull back the data you want to display. It's a little more than adding a couple handlers to a built in web service which you get for very little effort in C#.

If this is a personal project and you have personal reasons to do things, then go for it. But if you are working with a team, consider the cost of adding the new technology to include long term maintenance. How much does your team need to learn to fix bugs or add features? Unless there is something inherent in the language platform you need, consistency between the services is going to be easier to maintain. In this case you have a language dependency because of your proprietary product you want to integrate, but often times teams may need to integrate python services due to the Machine Learning or Natural Language Processing capabilities that are mature on that platform.