Ask HN: Is Golang mature enough for FinTech startups?

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.

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.

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.

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/

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.

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.

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.

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.