Haha! I understand what you mean. It's a long story, but the gist of it is that I had been more of a hobby-grade developer, on and off, and had a few side projects that I would occasionally boot up and play with.

You could say that I was technical enough to be dangerous, but before PriceTable I did not have any "real-life" experience (or the depth and breadth of knowledge) that comes with building and maintaining a SaaS app with paying users.

I started playing with Rails back in... 2010 I think? And about five years ago someone in the Rails community introduced me to Elixir, and I fell in love with it. So when I conceived of PriceTable, I figured, why not use Elixir for it.

Also a hobby dev who learned Rails. What was the switch to Elixir like in terms of learning curve and community support?

To be honest, it wasn't all unicorns and rainbows. On the surface Elixir is very similar to Rails. But there are important differences. For example, Ruby is object oriented, whereas Elixir is not. I'd say it took me some time to ditch my OO habits and to start thinking of problems and solutions in terms of functional programming. Ruby also has a much larger standard library, whereas Elixir takes a plug-and-play approach: it has a small but solid foundation, and for any specialized functionality you're encouraged/required to reach for an external library.

There were other challenges too. Rails is a pretty mature ecosystem, and there are libraries and guides and examples for almost anything you can imagine. With Elixir/Phoenix, I ended up having to learn many concepts and system design principles and then implement them myself. For example, at the time I was working on the billing modules, the only Stripe library for Elixir was in a limbo, so I developed my own integration. With Ruby you'd literally install the official Stripe Ruby library and go wild.

Stuff like that wasn't necessarily a bad thing, mind you. I feel like a lot of things I took for granted in Rails (a lot of the "magic"), I had to actually learn with Elixir, and it made me a better engineer.

Elixir and Phoenix documentation is fantastic, and the community is both extremely friendly and very knowledgeable. There's an Elixir Slack that gets a fair amount of traffic, and both Jose Valim (Elixir creator) and Chris McCord (Phoenix creator) are very active both there and on the Elixir forums.

If you're interested in making the switch, I'd love to help. Shoot me an email at ege@pricetable.io!

As a former business guy who wanted software, I’d recommend that you focus on finding someone you trust over picking a specific tech stack. What you’re looking for is someone who can talk to you about the problem you’re trying to solve, which could be recommending no software, along with the benefits & trade offs of the whatever tools they intend to use. If someone you trust wants to use Elixir & Vue, great. If someone you don’t trust wants to use Elixir & Vue, run far away.

I agree with what you're saying, but I don't think it answers GP's question. OP didn't partner or hire someone to do something on an obscure stack, but OP themself as a non-programmer by trade chose that stack, and GP now wonders how OP came to that choice, as opposed to whatever should be the top hit when searching for a stack.

Most of the time it's just because something looks neat, is well documented and might be a useful skill. That's why I learned Ruby back in 2006 with little to no programming experience. I really wanted to make websites, but I hated the idea of learning Java.

It could start with identifying concurrency as a priority, then looking up the erlang BEAM as a best in class solution, and finally using recent forums to see what today's practical tools are for taking advantage of the BEAM and coming across elixir/phoenix.

*that's how I heard of it, at least. I'm not a developer, more of a sysadmin / analyst

I don't think there's a real answer to this that doesn't have a time variable.

Phoenix is pretty stable and fast. I'd assume it's pretty popular here.

I'd recommend .net core because i have the most experience with it ( but it moves fast since .net framework). But it's less popular here ( i think)

A couple of years ago, it was RoR ( and that is still a viable solution).

A long time ago, it was PHO and that's still a valid solution.

There are multiple answers to this and some people will prefer one over the other. It mostly has to do what they are used to and heard of.

I just wouldn't recommend a young and new javascript framework. Many have come and go.

Pick something stable and don't use the "latest and greatest" is the only advice i can give you.

It depends on motivation: is my motivation to learn something new or play around for fun? Then I'll choose whatever I'm interested in learning.

If the motivation is to build something I actually need independent of the stack - in other words, something I expect to be paid for building, or has some other utility - then I'll use what I know. That doesn't mean I won't learn new things, but I'll learn those things in order to get the job done, rather than for their own sake. That doesn't rule out small experiments - for example, trying out an individual library to accomplish a task - but the overall stack will be something I'm familiar with.