I am currently in talks with an 80-year-old bank, trying to convince them to let us build their upcoming API in GO, rather than JAVA. We currently have more experience building the system in GO, and with a tight deadline in mind, I would rather invest time building the technology, rather than learning and planning it out in JAVA. I would like to reassess the decision. If you feel JAVA is still the right fit for building the banking infrastructure, I would like to know your point of view aswell.
Using JAVA potentially gets you into intellectual property problems since Oracle claims that APIs (and, particularly JAVA APIs) are copyright and has been asserting ownership. It is a risk that is hard to quantify especially since it is up for a decision by the SCOTUS.<p>Personally, I think Go is clean, tight, and elegant whereas Java always seems a bit clunky and verbose.<p>For 100,000 feet, it seems to me that the particular programming language used to construct a banking system should not be a primary design choice issue. What is important are the features and use cases the banking system is to support, what the operating environment is to be, what the security environment is to be, how the system is going to be kept non-fragile, what APIs are going to be exposed to users, what scaling is going to be expected, what performance is required, and so forth.
Why do you think the project should be in Go rather than Java? Do they have existing development staff experienced with Go, relative to their Java experience? Are they having trouble working with 3rd parties due to using Java? Would Java not support their business outcomes?
It is faster to develop and manage the code in go . But i agree customer are more comfortable with java.Both of them have their pros and cons . It's all depend on the requirements which one is better.
Honest question: Why do you think they should switch to Go? If Java is what they’re comfortable with and it’s still used widely in the industry, is the trade-off worth it?