Hacker News Reader

Comment by BoumTAC | Hacker News Reader

I learn FP throught ELM and I really enjoyed it. Unfortunately the language seems dead.

What are the easiest FP language to learn ? I checked multiple time Haskell but it seems really hard

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.

Real World Ocaml is a decent resource: https://dev.realworldocaml.org/

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

Elm started with FRP and moved on to Model-View-Update, which I agree is way simpler to understand and work with.

https://elm-lang.org/news/farewell-to-frp

I have high hopes for the young Gren fork of Elm https://gren-lang.org/.

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 expect websockets to make a return, which were dropped with Elm 0.19...

Websockets were dropped?? It seems support was introduced with subscriptions in Elm 0.17[1] as a great feature?? How did that happen?

[1] https://elm-lang.org/news/farewell-to-frp

The official reason is here: https://github.com/elm-lang/websocket

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.

> Elm has always preferred purity over practicality

Elm preferring purity is its practicality.

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.

OCaml fits the bill for me. It is an amazing language, very practical, fast, and easy to code with. It is a shame that I didn't discover OCaml sooner.

FWIW, I tried Elm, Haskell, PureScript, Elixir.

What were some drawbacks of PureScript, or why do you prefer OCaml? I've only ever used Elm and Haskell, but been eyeing PureScript recently...

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 isn't dead. It's in that happy place of stability, people are getting things done with it w/o hassle or churn.

I've heard that an Elm-to-native app compiler is in the works somewhere, which IMO is very exciting.

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

Maybe elmish could be of interest to you? https://github.com/elmish/elmish

Proper FP as in pure functional programming?

Probably Purescript in the frontend (also hard) or Scala on the backend (easier, because you can also write impure code).

F# might be a good shout.

There is the SAFE stack https://safe-stack.github.io/docs/overview/ where the E means Elmish

Haskell is sort of the base model option if you want real full-power FP, and not just support for some FP techniques.

'Haskell Programming from First Principles' is a great book which helped me a lot in the beginning.

Very different from Elm or Haskell, but Erlang was my gateway drug to FP. I’d tried and failed to learn Lisp on a few occasions.

Elixir is more popular these days, but I still prefer Erlang’s syntax. Minimalistic, helps me “think” Erlang instead of imperative/OO.

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.

what makes you say Elm is dead?

Reply on news.ycombinator.com