Is Elm a better language for a math game startup?

Help
#1

I’m working with a partner on a math game company startup. He’s the business side of things, and I’m the programmer for the first version (a minimum viable product).

So we want to run a math-instruction related game in the browser. Before I brought him on board, I was working by myself on it in Purescript. Now, he has encouraged me to shift gears toward creating quick and dirty prototypes and aiming to bring in investors later to fund more programming efforts to polish the game (I don’t have enough spare time to make it polished – I estimate a person-year of work from MVP to full-featured game and we don’t want to wait four years or however long it would take me alone).

So my thought is, if we bring on other programmers, how many programmers know Purescript? It might be a bit of a heavy lift to find them.

But, presumably more programmers know Elm. I see it looks pretty popular these days, just by searching blogs and articles about client-side programs.

The thing is that I’ve already gotten used to Purescript (as well as purescript-ide in Emacs and VS Code) and I don’t know how far back it would set me if I switched to Elm. I would need to learn Elm and rewrite my code base (which currently uses type classes in some areas). I’d really like to continue it in Purescript.

Mike

#2

In your case, while I might consider other languages than PureScript, I would probably steer clear of Elm.

Elm is pretty focused in ins target niche and one of its focuses is to remove any escape-hatches that might complicate the code or introduce unwanted runtime exceptions. I recently listened to podcast explaining how in simmilar stage of iterating-on-MVP they moved from Elm to bucklescript/Ocaml based stack, because it was easier to have these escape-hatches there [1]

If you feel like you can iterate on those MVPs in purescript the best, I would go for it.

On the hiring side, it can be tough. Once I worked on a clojure project and after a year we had to rewrite it in python, because our manager wasn’t able to hire more people (but there already were 5 of us on hte project), so you could run into that in any non-mainstream language.

[1] https://reason.town/paul-biggar-elm-to-ocaml

#3

Rather than finding new hires who already know PureScript, I see the real problem with using a nice language like PureScript as being how fast you can get a non-PureScript person up to speed with the language. This is where tutorials, patterns, idioms, and reference documentation are essential.

The other thing to note is that a project which uses a language only needs like ~20% of the projects developers to be proficient in the language, because a smaller portion of the developers are defining the abstractions and in-project libraries (the platform/language on which to build the app) and only those people need to know the best ways to exploit the unique features of the language and to explain it to the rest of the team.

Anyways, given the sparse technical details you provided, I hope this opinion/advice helps you.

1 Like
#4

Thanks for the thoughts, both of you. These are useful. There really isn’t much planned at this stage. We don’t know even much about what the final game will look like, or how it will be deployed (app? web page?).

Probably the most important thing at the moment is creating quick prototypes, and I do that well in a functional language like Purescript. I already paid my dues learning Haskell 10 years ago.

Mainly I want to avoid creating a large amount of technical debt – i.e. discovering the code base has to be ported at great expense, when that situation could have been avoided had I chosen the “right” language. But I suppose that’s the wrong way to think about things. “Plan to throw one away” (MMM) and all, right?

#5

PureScript’s type system allows you say most things you would want to say about your program, so I think you shouldn’t be worried about PureScript being the “wrong” language.

Personally, I don’t advise to rebuild an app in active use, but instead find ways to incrementally move the in-use app in the direction you’d like to go. Your situation and experience can likely mean my opinion doesn’t apply to your situation, of course.

#6

I’m not talking about rebuilding an app in active use, but I’m talking about moving from a “minimum viable product” stage, with a small user base, to a more polished “ready for prime time” app. If this is ever going to happen, it’s going to be because I (working alone) managed to bang out an MVP, then bringing in investors who will get the “real deal” funded. I don’t really want to work long-term as a programmer. I’d be happy to turn it over to a more experienced developer who can work in whatever language they please.

#7

I’m a co-founder of what was a startup company–now publicly traded–with roughly 200 employees. I’m also a huge fan of FP, and I’ve spent big chunks of time learning Clojure, Haskell, Elm, and more recently PureScript.

Having been through the gauntlet of building an initial team, raising dollars, and navigating all the challenges that impact a growing business, I’d rank talent acquisition as one of the most pivotal factors in the success/failure of a company.

PureScript is wonderful. Elm is cool too. They’re are lots of great languages out there that offer their own set of distinct advantages, but at the end the day, being able to hire talented developers, hit the ground running, and make the product roadmap a reality will generally trump any unique advantage one language offers over another.

Yes, Elm has some mindshare, but I’d be hesitant to make it a key part of my stack for the aforementioned reasons, and while PureScript is probably my favorite language of all time, it’s current “happy place” is in bringing me joy when I’m working on my side projects because it’s probably 1/5th as popular as Elm.

Just like nobody got fired for buying IBM, nobody got fired for choosing JavaScript. There are LOTS of ways you can make JavaScript more palatable and bring in some of the ideas you know and love from the FP world while simultaneously keeping the hiring machine running at full capacity.

Look into your crystal ball for a moment. Do you want to picture yourself explaining to your co-founder that you can’t find talent because you went with an esoteric language for your core technology? I’ve seen these types of decisions have some pretty detrimental impacts on startups that were founded by close friends, and it’s pretty heart breaking to be honest.

That said–I’ve also seen some really companies succeed that are built on languages like Haskell for their backend, but they’re the exception not the rule.

Building a business is hard enough on its face. Don’t make it harder by handicapping yourself out of the gate.

2 Likes