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: two-languages_vs_one

  • I don't really understand the downvotes, at least not without comments, as I require information on how I could improve the question.
    – HackXIt
    May 23 at 12:04

1 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.

  • 1
    "If this is a personal project and you have personal reasons to do things, then go for it." - this is the main argument IMO. Using different technologies for small personal projects is an excellent way of getting a feel for these technologies and where they are applicable. For software developed with a team, you should have convincing technical reasons to choose a different language for a sub-project. May 23 at 6:08
  • For this particular task, there's no team involved, but I agree, if the project is finished and I'm not there anymore to maintain it, it will cause issues for those not familiar with the language. - In regards to the Go webserver, it will most definitly communicate with the C# service, the Go service must produce a valid request in the propriatary format, but that can be abstracted into JSON or XML and let the C# service do the heavy lifting, since the Website has very basic input anyways.
    – HackXIt
    May 23 at 12:02
  • GraphQL is a good input, but the application doesn't use a database at all. It's a propriatary application handling network channels, actuating devices and receiving log-information. The second service would send pre-defined requests for the propriatary service to handle and would basically get back an OK or NOK for the executed actions. I thought it would be a niche way of experimenting with a new language, but it's always hard to argue experiments in a professional environment.
    – HackXIt
    May 23 at 12:09
  • GraphQL doesn't require you to use a database. It's a way of either querying state, or mutating (i.e. invoking something). I'm assuming your front end needs to be able to show what processes are in play and the general progress on them. While that can be state in a database, it can also be a snapshot of what's happening in the proprietary API. That said, if it doesn't match your needs, don't use it. May 23 at 15:32
  • Alright, that's interesting to know and in my terms an acceptable answer
    – HackXIt
    May 25 at 13:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.