Elm is not dead. It just prefers a slow release schedule but is still actively worked on in the background.
That said, you might want to check out OCaml for general purpose programming. Super fast compiler, great performance, can target both native and JS.
It is easier to use than Haskell due to defaulting to eager evaluation (like most languages) strategy instead of laziness and being generally more pragmatic, offering more escape hatches into the imperative world if need be. Plus great upward trajectory with lot's of cool stuff like an effects system and multi-core support coming.
> you might want to check out OCaml for general purpose programming
Any tips on backend frameworks to look at? I need to write a small websocket service for a side-project and have always wanted to try OCaml. I came across https://github.com/aantron/dream.
Dream is great for small http services -- I've not used the websocket support so I can't say much about it.
I do highly recommend starting with one of the Dream example projects just to lower the barrier to entry on the tooling side.
You can also use Rescript (compiles to very readable Javascript), which is the OCaml type system with more familiar syntax and some of the complexity shaved off.
You'll have a much easier time doing business stuff with F# - it's OCAML inspired but has access to broader .NET ecosystem. We're using it on front end as well w/ Fable compiler. It's pretty awesome.
It was pretty obvious that at some point, someone would fork Elm, given how Elm has always preferred purity over practicality... but it's not clear how this fork improves things even after reading the (tiny) documentation... can you expand on that?
It seems to address the important problems with Elm, around its overly restrictive project management, by 1. introducing more flexible package management (e.g. you can depend on a fork of a core package, or a private git repo etc.) 2. being open to adding various missing web APIs (e.g. while I'm not sure it's there yet, I expect websockets to make a return, which were dropped with Elm 0.19) 3. generally going for an open development model (even just not having to wait years to fix trivial crippling bugs in the compiler is a step forward...).
The other part is that I have a good impression of the person/people behind it and could see it sticking, for whatever that's worth.
Lead developer of Gren here. It's great to see people being interested in the project, thanks for the mention!
Just wanted to add that both websockets and indexed-db is being worked on by members of the community. I'm hopeful we'll have them ready for the 0.2.0 release in December, alongside preliminary nodejs support.
Since the 0.1.0 release, we've added support for local- and session-storage, which was another often-requested feature for Elm.
I believe it's quite possible to support websockets with the current language features, though, and I hope that websockets will be ready for Gren along with the 0.2.0 release in december.
I would recommend starting with Elixir. Elixir is a dynamic functional language, unlike Haskell/Ocaml etc. which are statically compiled languages.
This means that you can learnt he basic concepts of operating on data with pure functions, pattern matching etc. Plus it's a nice language that is great for building a lot of things (Phoenix is a great web framework).
Once you've got some of that background of how you build functional programs rather than OO, moving to something like Haskell or Ocaml is a bit easier because it becomes more about understanding how to declare types to keep the compiler happy and less about the fundamental program design stuff.
So sad to hear that Elm appears to be dead. It really excited me at first but I guess that like many I never made the time to give Elm a serious attempt.
For me, learning Racket was not too hard. The offical learning materials are excellent, although they are also meant for programmers starting from zero. For me that meant that I occasionally skipped over parts I considered "too easy" only to be confronted by my hubris later.
For me, what makes lisps easier than Haskells is that lisps are multi-paradigm. So you can write a more imperative implementation of whatever you're doing right next to the "proper" functional one to get things to click, and also to identify those elusive merits of functional programming.
I wouldn't describe the Racket community as "vibrantly alive", but it's definitely still moving along. And the knowledge is very transferrable to other lisps and schemes. Next on my list is Carp, for example. And if you (choose to) use Emacs you'll reap even more rewards from the knowledge transfer.
"Elm is dead" means different things to different people. I think what most people mean is they are not adding the features that they want from Elm. Elm has a strong opinionated nature, as well as being very well scoped to the front end and using "TEA" system for rendering, so it may appear that it is dead because there isn't much to update anymore.
People are still working on Elm ecosystem packages, so I think that is evidence that it isn't dead. But it isn't as "alive" (or perhaps... hectic) as the JS ecosystem of course.
Elixir paved the way into FP for me. I did Lisp, Prolog and a bit of Java & Javascript done the FP way (I know) at University though, but only with Elixir I've had the "now I get it" Eureka moment.
I have been using rxjs with typescript for some stuff. Functional reactive has proven to be a good paradigm for some stuff in the UI and thornier parts of shared state across multiple applications.
That said, you might want to check out OCaml for general purpose programming. Super fast compiler, great performance, can target both native and JS.
It is easier to use than Haskell due to defaulting to eager evaluation (like most languages) strategy instead of laziness and being generally more pragmatic, offering more escape hatches into the imperative world if need be. Plus great upward trajectory with lot's of cool stuff like an effects system and multi-core support coming.
Real World Ocaml is a decent resource: https://dev.realworldocaml.org/