Is it shooting myself in the foot to use Go for back end business logic?

I'm in the process of building a large business application in modern Java. It's hard to find any faults to be honest. Our code is boring, straightforward, and directly solves the business problem. Our team loves our tech stack and I personally find it very enjoyable to code in. The tooling is amazing (IntelliJ, static analysis tools, etc). We have extremely few defects related to Java itself. Nearly all issues are related to the complexity of the business problem.

But I think the success of most projects is less to do with the language and more to do with people. You need a solid lead that will provide a clean architecture, enforce consistent coding patterns, interface with business to provide clear requirements, enforce code quality with PRs, etc. Otherwise it's garbage in, garbage out.

Making some assumptions about what you mean by "business logic application backend." Taking it to mean the business logic layer in an application stack that sits between the presentation layer and the data access layer.

This style of application development benefits from an object-oriented language. Where an object encapsulates the domain logic of business rules. This can be accomplished in Go with structs and funcs.

Classes in Java make good domain models because of (overbearing) enforcement of file structure (object creation validation rules in the constructor, limit access to properties to getter/setter methods that can verify inputs before mutation, yadda yadda). In domain models, neatness and organization counts a lot for the long-term health of the code.

My opinion is that Go is well suited to the task of creating autonomous worker applications that enforce business logic rules for domain objects with well-defined borders. If your domain objects have overlapping concerns or you have actors/business rules that need access to more than one domain object for calculation/mutation you would be wise to think carefully about the application structure before selecting Go as your language.

All my service logic is written with Node.js. It executes fast enough. Now it’s as fast as Java (except arithmetic) and probably similar to .Net. The performance problem is not instruction speed or anything to do with the CPU. The performance penalty comes from GC. Java and C# are also garbage collected. I believe Go is not.

A GC bottleneck is encountered when information processing frequency sustainably exceeds processing speed for long enough to encounter a problem. This is extremely unlikely to encounter in real world operation but easily produced during performance stress tests. I have found that I can send web socket messages up to 450,000 per second (on my laptop) with a total message processing frequency of about 60,000 per second. That means I can send messages fast than I can process them on the receiving end, which produces a storage problem. After about 450,000 messages message processing drops to a speed of about 300 per 5 seconds waiting on GC. Since this is a per socket problem I cannot imagine this ever becoming a real world problem. Nonetheless, I don’t suspect Go would have such a bottleneck.

I have a client application running since 2015 used by his team. It is not a big company but there is a lot of business rules, controls and logics : the client's domain is in a very ruled business in France (end consumer laws, finance, etc)

Go key features were maintabilty and ease of coding new features or adaptations to new rules.

I'm coming from Java background and bank domain.

Edit: also Monzo is a bank using Go as backend

Go is an amazing language. It’s simple. Fast. Opinionated. It’s got tons of libraries. Works really well in K8s. I’d 100% support this.