Ask HN: Is Golang mature enough for FinTech startups?

[dlist]

We would love to get your thoughts on GoLang in 2016. The language has spectacular speed and it is fun to work with but we're wondering whether to brave an entire FinTech site with it. Our backup is Rails. I've noticed that Revel and other frameworks in Go have lost steam, due to React, Angular, and Ember replacing the frond end. But that has its upsides and downsides too. Go and React would make a nice pair, but we may have to reinvent the wheel to protect against many attack vectors that are already taken care of by Rails. Then there is hiring and on-boarding on a less-standard architecture. Yet that speed is so tempting.

Braintree had some objections in 2013: https://www.braintreepayments.com/blog/gotchas-irritants-and-warts-in-go-web-development/

From a functionality standpoint, the site will be processing Stripe and/or Dwolla & Braintree; holding user profiles with private and public views; We'll do CloudFlare, SSL (DigiCert or CF), and Postgres in the back. We'll need to take care of CSRF, injections, user validations, OFAC checking etc. What do you guys think?

If you or someone you know has done GoLang for FinTech, would you be willing to chat?

[mattheath]

TL;DR Yes, but as someone else mentioned, the real question isn't if Go is suitable for Fintech, but if it's suitable for your team and the specific problem you are trying to solve.

I work for a startup called Mondo - we're building a full-stack bank and currently it's almost entirely in Go. However, this is a function of our architecture - we provide an API which our apps and frontend (some using react) communicate with. Behind this API are >100 microservices which comprise our application, and Go works exceptionally well for this type of architecture, as it excels at network services.

In your case it seems that you're building a web application, so Rails is going to be easier to build out a prototype, hire for, and has taken care of a huge number of your concerns already at a framework level. There is of course nothing stopping you from splitting out functionality later into smaller Go based applications, but I doubt at this point speed of code execution should really be a concern - if you're building a new company you need speed of product execution, no?

Regarding functionality, Go will do everything you're asking for: - CSRF can be handled with middlewares like Gorilla's CSRF package: http://www.gorillatoolkit.org/pkg/csrf - Postgres with the standard database package, or other packages on top - Third party APIs such as Stripe/Dwolla/Braintree will be fine - If you're looking at integrating with other (older) parts of the global financial network (eg. is there an OFAC checking service with a nice API?), then you may find other languages would be easier for these tasks. In our case we may end up abstracting some of these with services in other languages that already have libraries to interact with these systems, and then providing a nice internal API our services can interact with.

So, Rails has a huge number of framework level features which may help you move faster as you develop your product. But, yes, Go is perfect for Fintech applications, we're building a bank and love it.

[tedmiston]

Would you mind sharing more about your microservices, what languages/frameworks you're using there? And if you deviated from Go for specific reasons or more just personal preference of the engineer creating the service?

[djb_hackernews]

It sounds like you are building a transactional CRUD webapp that doesn't need to scale all that much, for a startup where the team already has a bunch of experience with Rails, which IMO, has the best ecosystem for webapps available (and I'm not a huge Rails fan.) And the main reason you are looking at Golang is because of performance improvements, even though it doesn't have a great ecosystem yet, never mind a solid webapp framework, and the team doesn't have much experience with it? Is that right?

Having written and maintained a large Rails app from the ground up, and done some small projects in Golang, I think you'll be extremely dissatisfied with all of the extra work you'll find yourself doing, which really takes away from the time of actually getting your product in your users hands.

When coming from Rails, most other options will have speed that is tempting. If it were me and I were in your position and wanted to avoid Rails I'd pick Java/JVM for its speed, ecosystem and its fit in to fintech. But that's me. Or just use Rails and rewrite it in the new shiny if and when performance becomes a problem.

[tedmiston]

My startup's experience was similar. Our core is an Angular app to a Django backend API.

Django and Rails are roughly the same level of maturity.

The approach that's worked best for us is to keep all of the business logic and CRUD-y stuff in this Django base, then spin out dedicated microservices in the special cases e.g. CPU-bound tasks. I think most startups end up with a similar architecture.

[sheepmullet]

Why not Java? It's more powerful, mostly faster, has superb tooling, high quality libraries for just about everything, tons of very experienced developers, etc.

[tedmiston]

In startups it's easier to hire devs for JavaScript/Ruby/Python over Java/C#/etc.

Particularly look at the orange bars in the graph "Programming Languages" on [1] which is based on data from AngelList.

1: http://codingvc.com/which-technologies-do-startups-use-an-ex...

[sheepmullet]

It really depends. Outside of SV there are 10x as many skilled Java/C# developers.

In the FinTech world most of the developers with deep domain knowledge will know Java/C++.

Of course it really depends on what the OPs startup is trying to do.

[tedmiston]

Your point is definitely correct. And the post I linked uses data worldwide not just in the bay.

In fact even in my city (Cincinnti, OH) there are more Java developers than any other language, but they are mostly in corporate jobs.

So here still there are less Java developers working in startups compared to other languages.

[dlist]

Java takes longer to build with and it's harder for startups that are working on product market fit. Once we figure things out, we can rewrite in Java, but before then it's premature optimisation in my book.

[sheepmullet]

> Java takes longer to build with and it's harder for startups that are working on product market fit.

Longer or harder than using Golang? Unlikely.

Golang has some advantages over Java like a simpler deployment model, less runtime overhead, etc but overall for a fairly standard web application it makes much more sense to pick Java over Golang.

> but before then it's premature optimisation in my book.

Then so is using Golang. You have answered your own original question :). Keep using Ruby.

[dlist]

>Longer or harder than using Golang? Unlikely.

Developer productivity is much higher with Golang.

[iamd3vil]

I work in a FinTech startup and most of our components are written in Elixir and are in production. We are very happy with it. So I would say atleast consider Elixir and Phoenix. It's as performant as Golang, it's even better in some cases and it's a better language than Golang imo.

[kasey_junk]

A caveat to start with, I am not a front-end guy (though i program golang backend infrastructure all day/every day)...but I think the question of whether golang is mature enough for fintech and if golang is a good choice as an early language for you are orthogonal.

In the domains that golang excels in, it is much more mature than its age. Things like security, memory use, serving network daemons etc. it is great. I would be happy to advocate for it in environments that require a "mature" stack.

But if what you want to do, is rapidly take data from a user and put it into a database, over the internet, I'd say it is a pretty bad choice. Especially if you already have rails experience. Rails is purpose built for that use case and it is (from what i hear) good at it.

[fiedzia]

Rust/django user here, but ... its 2016, micoservices has been invented long time ago, so use best tool for the job. As for other things: SSL can be terminated by AWS/nginx/whatever, so no need to worry about that. Every ORM I've worked with, regardless of the language, makes injections thing of the past, for non-db things few type definitions solve the problem too (rust has advantage here due to sane type system). CSRF can be solved by middleware + few hooks in right places, not a big deal. Yes, you will need occasionally dig into golang libs and frameworks to add a feature that existed in rails, so really this comes to balance between long-term performance gains and short-term convenience. With really large space between those two.

[shadeless]

I'd strongly recommend that you at least consider using Elixir [0] instead. Especially since you're coming from Ruby/Rails and you're looking at the frameworks, Phoenix [1] will get you 80% there.

Instead of me listing all the nice things about Elixir which you can read about online, feel free to send me an email with any questions regarding usage in production. I've been using it for some time and I'm very happy with it.

[0] http://elixir-lang.org/

[1] http://www.phoenixframework.org/

[dlist]

Looking into it and setting up a sandbox. From a performance standpoint, how does Phoenix stack up against Rails or Node.js for you? I'm looking at benchmarks http://www.techempower.com/benchmarks/#section=data-r12&hw=p... and, while there are advantages, it doesn't seem to stand out.

[shadeless]

IIRC there were some issues in how Phoenix was configured for the techempower benchmarks, I expect that it will have much better results in the next one.

You may want to look at these benchmarks also:

https://github.com/mroth/phoenix-showdown

https://gist.github.com/omnibs/e5e72b31e6bd25caf39a

Here is a post about using 2 million active websockets connections in Phoenix: http://www.phoenixframework.org/blog/the-road-to-2-million-w...

From my experience, Rails and Phoenix speed isn't comparable. Even in development mode (with code-reloading etc) Phoenix is much faster than a production Rails server. I've also replaced three Node.js servers with one Elixir server which did the same work with less memory and CPU usage, but I'm aware that most rewrites have a similar story, so I won't claim that this is enough proof.

[spotman]

If you are relying only on a framework for things like CRSF protection and do not understand how to avoid these pitfalls on a fundamental level then you have bigger problems.

Having said that I think I would choose your solution based on your teams skills. If they are comfortable with golang there is no reason it could not be made to work.

But as long as you understand how the table is set and the trade offs I don't think it matters. Golang is going to have less batteries included but it has other advantages too. If it's worth it is really a question of speed of code execution vs speed of writing code.

[dlist]

Our previous startup was with Rails and we did hit performance bottlenecks, even without Payments being involved. Consumers are very sensitive to speed, so that plays a big role in the decision as well. Team skills are adjustable - the founders are technical and the team is being built up hereafter. The big question is does GoLang still have any inherent issues that may conflict with the expected reliability of a financial company - is the Braintree objection out of date?

[jtmarmon]

you'd have to explain more about what you're doing, but i'm sure go is fine. i'm also sure rails is fine.

i can't speak for the first two points, but those seem simple enough to avoid with tests, really. most issues are.

the third issue is something you have to decide on. i'm sure the tooling around go is much better than it was three years ago, but you're not going to have everything in a pretty package like you do rails.

honestly the choice is probably inconsequential, unless you have some actual reason why the language choice matters for your application (which it almost always doesn't).

also if you're in fintech and doing bitcoin, i've heard the node ecosystem has the most BTC support, so that's a consideration