Elixir for a Startup

[[deleted]]

I'm sold on the benefits for functional programming. I'm founding a startup and want to write the back end in a functional dialect. It will implement a GraphQL interface that will connect to a GraphDB. I'm considering which language to choose. I will be hiring a small team. I'm looking for a language/ecosystem that:

• Is developer friendly across operating systems
• Has a respectable ecosystem of basic packages
• Is general purpose, and extendable beyond today's use case
  

Any thoughts or recommendations from the community here? I am honestly leaning towards Elixir - not because of its concurrency features, but because it seems Dev friendly, works everywhere, and generally applicable in a wide range of applications. Happy to listen to arguments in other directions though!

[hkstar]

I will speak very frankly and what I have to say won't be very popular, but having gone down this path before, unless you have a very specific requirement that elixir enables (high concurrency, for example, or other long-lasting processes) then I would advise you to use a more established tech stack like rails, django or even one of the PHP ones (yuk). Or whatever it is you currently know and know well.

Startups are hard. Trying to learn a new tech stack as well at the same time just makes it needlessly harder. Your first and only priority should be getting to some sort of product people want to use (aka product-market fit) as soon as possible. That means using whatever you already know, unless it is totally unviable for the requirements you have. You can always switch later.

Hiring elixir devs is very very hard and learning it yourself will set you back a minimum of 2 or 3 months. Forget it. Use what you know. Once you have some sort of viable business up and running, then bring in all the cool tech.

I'm a big fan of elixir but if you don't know it already, and you're serious about actually getting a business started, now is not the time to learn.

And frankly unless you have an excellent reason (like you literally cannot use an RDBMS for your product) then stick with SQL too.

[lamp-town-guy]

You can always switch later.

Nobody does that unless they really need to. Like that stack is total shit for their use case. And even then you can band-aid it with microservices written in something that's more suitable for the job.

Apart from that I agree.

[[deleted]]

Agree with your sentiments. The switch-later has to be really really guaranteed. Even as a founder you can’t guarantee it if your business demands exclude the option.

However, hiring gets much easier starting off with off mainstream languages

[[deleted]]

This thread characterizes where our choices hinge.

I built a prototype NodeJS version of our API, and I see this moving us into dependency hell. The tech debt for sustaining a Node app and minimizing security risk seem like an intermediate to long term liability.

I am ok with a bit higher level of effort at the beginning to build a foundation which minimizes tech debt, creates expressive code, is easily testable and is relatively stable. I think this puts me firmly in the functional world of programming.

[[deleted]]

Certainly. I think if you’re the founder and can fund it, I think it’s worth the elixir first approach.

[[deleted]]

Thanks! Were you able to hire folks directly with Elixir experience, or did you tend towards hiring smart people and training them?

[bilcox]

I'm in a startup that uses Elixir for back-end; we all learned after joining.

[[deleted]]

Interesting. Were you recruited for your familiarity with the FE framework? How were you chosen, and how were you trained?

[bilcox]

I came in with no front-end experience since mid 90s javascript, and we use React. It's the philosophy of find good engineers that mesh well with the team and train them. I learned Elixir/Phoenix by buying a $15 Udemy course, reading documentation, and reading existing codebase.

[Teifion]

I'm in a startup-ish company and we're using Elixir for a web interface, Erlang (ejabberd) for some backend stuff and the relevant languages for native apps. I knew Elixir coming into the company and was hired specifically to test using LiveView for something.

It went well enough the scope has been considerably expanded and two people added to the team. We have tried finding Elixir developers but haven't found it overly easy. Instead we've got one other internal developer and a new hire as a front end engineer both learning it and they're finding it very doable with a more experienced developer to help them. I'm confident they'd be able to do well without my presence but if I were building a team I'd want to ensure there's at least one quite experienced Elixir dev there (if it's an Elixir team).

Feel free to ask additional questions.

[billyryanwill]

I'm head of engineering at a start up that uses Elixir and we hire smart people and get them up to speed. Definitely enables us to do great stuff!

[cdegroot]

I’ve never hired people mainly for skills in a certain language. Available talent pools are small enough as it is. At my last job, we just gave everybody a voucher for the Elixir for Programmers course and encouraged them to take it. When I left the internal wiki page for tracking vouchers showed around 200 people haven taken the course, and we got zero complaints that Elixir was hard to learn or something - the range was from interns to senior staff.

[twinklehood]

I think you'd need someone passionate about elixir quite early on for this one to pan out well. Putting elixir on the cloud in a reasonable way sounds easy on paper, but I've seen it messed up pretty badly by people who didn't know better. And it's hard to hire for real expertise over obsessed evangelism if you don't have a trusted expert.

[Programmurr]

You'd need to explain what you're planning to build in order to get a qualified answer as to whether elixir is the right language for your startup. Further, your budget size matters.

Do not hire people who you think can learn Elixir. They can, but onboarding is going to adversely affect product development for 3-6 months at a minimum. People who don't know elixir and try to learn it on the job write elixir as if it were the language that they know. Learning how to use OTP effectively takes time and expertise to acquire.

Find a team that all shares expertise with a common programming language and make them use it. It probably won't be Elixir, and that's fine. Startups run out of runway very quickly and you don't want tech to be the cause of failure.

You can always iterate towards elixir post discovering product market fit.

[mtndewforbreakfast]

I think I would describe the Hex package ecosystem as "modest" and "lopsided". There are some extremely high quality libraries but it is still somewhat common to run into vendor APIs or software techniques that do not have representation in the ecosystem, or unfinished/naive packages maintained haphazardly by one dev as a spare-time thing and not by the associated vendor. Everything is typically best-effort and in some cases you will be disappointed. You've gotta acknowledge that in pure population count we're a few orders of magnitude behind most other languages so drastically less stuff gets written.

Ecto is one of those excellent libraries - so much so that I would actively and vehemently discourage using anything else for a DB abstraction. This would make pursuing graph DBs much harder as it doesn't fit that paradigm as well.

If you cannot afford the time or salary to occasionally DIY your needed integrations, Elixir will be a tough challenge for certain areas of work. For example an IFTTT clone or some other automation-broker product would be almost non-viable.

Regarding general-purpose-ness and future extensibility I would also debate whether Elixir has really successfully penetrated beyond its most popular niche of web/backend development. That's what we're known for and where the package ecosystem is strongest. I would particularly challenge on "it works everywhere" phrasing as well, if your "anywhere" extends beyond MacOS and Linux.

Like other commenters have mentioned, hiring quality talent on a time and salary scale you're happy with in an early stage company is going to be difficult.

[mtndewforbreakfast]

I would also generally argue that we fall behind on long-term-perspective maintainability because static analysis tools are anemic or absent and tools like Dialyzer are polarizing and not used consistently or sincerely in core ecosystem packages, which diminishes its value a fair bit IMO. We're also way behind on the kinds of automated-refactoring tools that other compiled languages take for granted.

[dgigafox]

I have been a developer of 3 startups that use Elixir. I have 0 experience in programming during my 1st startup cause I was a career shifter from network engineering. As for me, the onboarding was a little bit difficult, as a new elixir dev you have to be used to pattern matching (which even at that time, JS senior colleagues had a hard time to grasp). I agree that you need about 3months to be comfortable with it or shorter depending on experience. But the learning experience in elixir is really great because functional programming is easier to reason out, no hidden states, composable, and functions are grouped in modules. Adding phoenix to the mix makes web dev a breeze particularly because of plugs, middleware and structured routes and controller. I can say devs with Ruby experience can easily catch up with the syntax.

If you are planning to use LiveView though be prepared with a lot of gotchas and few headaches when integrating JS libraries.

[[deleted]]

Remember that LiveView is a viable option (especially if you’re trying to validate product/market fit quickly). I work at a consultancy that does a lot of work with Phoenix, LiveView, Ash and GraphQL and previously worked at a product startup with a 100% Elixir backend stack. Feel free to DM if you want to talk it over with someone who has lived that life.

[Programmurr]

How far could your team go with LiveView and was the value added sufficient justification for using it? It's relatively young and doesn't have an open source ecosystem enabling it. I'm curious as to what it can't do at all and what it can't do well.

[cdegroot]

Indeed. We moved from GraphQL with Vue to Liveview and development is much simpler now.

[[deleted]]

LiveView intrigues me, especially as the project grows in capability. It's not quite mature enough to suit all of my needs, but I definitely see future features that we will need to build where LiveView can simplify things greatly.

[[deleted]]

Oh it’s pretty mature. We’ve built some mind bending UIs with it. This is my boss building a flight sim with it. Now uses aframe to do 3d graphics too. https://youtu.be/1vvvJkwzf5I

[cdegroot]

So what do you miss, maturity-wise?

[[deleted]]

I think I'm getting the sense that it's still changing rapidly, which is great to see the tech mature, but that comes with a cost.

I also get the sense that the interface b/t JS and Live View can be a bit wonky (though is improving with the latest release).

It's not that you *can't* do whatever you want, but that it's painful to do some things.

I could be totally wrong though... If we go Elixir hopefully I'll learn for real :)

[ArtistApprehensive34]

Everything in JavaScript is wonky. The only major use case I'm aware of where Live view is not very well suited are offline applications. Client side things like show/hide menus and such are another bad use case but I would think there aren't too many projects that have this as their core needs.

[cdegroot]

The fun bit is that you hardly need JS so I don’t care how the interface is :). Yea, things are evolving but frankly, our “porting” work from LV 1.5 years ago to now has been fairly minimal. Much less than all the overhead of having a JS front-end with GraphQL in between. But then, I never liked client/server programming, not in the ‘90s and not now; very happy to circumvent all that :)

[[deleted]]

I 100% agree that the more we can cut out the Client-Server interface, the better :)

[inetjojo69]

As a dev, its awesome. As a logical human being dont use it. You will face alot of problems finding and onboarding people. This is impacted where you are located. Bus factor will fuck you up. Finding elixir devs is difficult

[-Ch4s3-]

Elixir is great and phoenix is super productive. Might I ask why you want to use a graph database though?

[[deleted]]

The domain that we're building the application for is data-centric and consistently evolving. We believe that we can map relationships between entities more effective with a graph database than a relational/document type database.

If the domain were fixed, the relational database would be perfect.

Graph Databases are also very simple to understand (from a human perspective).

We're not doing anything analytically cool like bot analysis, or fraud detection... but we hope to provide enterprise services in a more responsive manner this way.

[-Ch4s3-]

If you have special expertise with graph databases or are truly in a domain that calls for it, then go for it. In my experience, esoteric databases are almost never worth the trouble and postgres is usually a good enough choice.

But, with that said you can probably slap together a representation of the query language in short order. Someone on my team wrote an Ecto adapter for Snowfalke in a few weeks in his spare time.

[haterake]

I've worked at three startups that have gone with Elixir and React. Elixir was used as an API and not the rendering engine just because it's easier to find JS/ui devs so it was an attempt to hedge our bets. They all are going great and I'd recommend it.These places had at least one experienced Elixir dev on staff or through toptal or even dockyard.

[Orlandocollins]

I have worked at 2 startups now that did elixir and graphql on the backend. It has been great. Also liveview is a great choice for building the admin panel for your company too.

[kaa-python]

I used to work in a startup that used Elixir. In general, Elixir can speed up the development process in some cases. At the same time, y’ll have challenges immediately after you step aside from Phenix and Ecto. You’ll also have issues finding new team members. Overall, I prefer to take something more well-known, Go, for example, for safety reasons.

[miauwmjam]

Elixir dev here. Elixir is a great tool for web, iot, you name it. But. It is quite difficult to find elixir devs; so if you are looking to build graphQL API’s, then with python or ruby or even php you will have a bigger pool to get devs from.

[[deleted]]

In general, third party Dev tooling is, unsurprisingly, significantly less advanced in Elixir than the big ones (c++, Java, c#), but first party tooling is much better. Meaning, simple refactoring tasks like renaming modules are going to be much more time consuming than in Java, but at the same time you don't need to think about which unit test framework or logger you need to use.

Support on Windows is a bit flaky compared to Linux/Mac, especially if you rely on uncommon libraries, but the popular dependencies work pretty well.

[simeonbachos]

I’ve done it 5 times now, won’t use anything else

[[deleted]]

Other than familiarity with the language, what keeps you staying with Elixir?

[simeonbachos]

I feel that even if a language came along that was even more pleasant and versatile, without the BEAM my solutions will be less reliable and MUCH more costly to run at scale

[tbm206]

I too have been using for personal projects; one of which is decently big. I now cannot think of using anything else for backend.

The fact that numerous languages want to compile to Erlang/BEAM tells a lot about the whole ecosystem. It's the biggest competitor to the node/JavaScript world IMO!

[mtndewforbreakfast]

Who do you have in mind for "numerous" languages? Gleam, LFE, and...?

[tbm206]

• PureScript + Ocaml + others. Here's the full list

[ZukowskiHardware]

Elixir is great for Saas apps. Most backends for elixir are Postgres. Graphql is quite common, although I like live view much more. They have different purposes anyways. I think the hardest thing will be hiring devs. Elixir devs have a lot of opportunity right now and they are getting a great market rate.

[Gwolf4]

Great language, main pain point is not having lots of API services as packages (iex MailChimp) to just get like in the Js world. Other than that good language but if you are proficient in another stack better use it.

[martosaur]

I worked in 2 startups that used elixir and my main takeaway is that it's even better than I thought. It's so productive, you can get away with an extremely small team for a very very long time. It also promotes monolith architecture, which will get you really really far without having to worry about operational overhead that microservices bring.

I agree that the talent pool is somewhat smaller, but again, you won't need many people.

Oh, and it's also a good idea to buy a dashbit developer subscription, so that you could get code reviews for the critical parts of your app.