
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&#x27;re wondering whether to brave an entire FinTech site with it. Our backup is Rails. I&#x27;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.<p>Braintree had some objections in 2013: https:&#x2F;&#x2F;www.braintreepayments.com&#x2F;blog&#x2F;gotchas-irritants-and-warts-in-go-web-development&#x2F;<p>From a functionality standpoint, the site will be processing Stripe and&#x2F;or Dwolla &amp; Braintree; holding user profiles with private and public views; We&#x27;ll do CloudFlare, SSL (DigiCert or CF), and Postgres in the back. We&#x27;ll need to take care of CSRF, injections, user validations, OFAC checking etc. What do you guys think?<p>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](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...](http://codingvc.com/which-technologies-do-startups-use-an-exploration-
of-angellist-data)

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

------
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/](http://elixir-lang.org/)

[1] [http://www.phoenixframework.org/](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...](http://www.techempower.com/benchmarks/#section=data-r12&hw=peak&test=json&l=2idxs)
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://github.com/mroth/phoenix-
showdown)

[https://gist.github.com/omnibs/e5e72b31e6bd25caf39a](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...](http://www.phoenixframework.org/blog/the-road-to-2-million-
websocket-connections)

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

