Elm, Elixir, and Phoenix: Reflecting on a Functional Full-Stack Project
teamgaslight.com
teamgaslight.com
I worked through their Elm course and it was excellent.
If the parent posted an affiliate link then that would have indeed been spam.
The courses from Pragmatic Studio are indeed excellent. Sometimes quality has a cost, and people should be ok with that. Not everything will be a free resource.
Note: I have no affiliation with Pragmatic Studio, they are just great courses.
It was not meant to criticize the OP but English is not my first language and sometimes I sound judgmental by mistake.
And I love to read good reviews here, they spare me a lot of time I would otherwise use researching a service or product.
For me a good review of a paid resource must mention the price ballpark so people have a choice to follow the link or not. May be OP is just a happy customer and not affiliated with them in any way but IMHO the parent comment really sounds like a guerrilla marketing ad for me.
So in this case, if it happened to be a free course, I would have expected the parent comment to specifically mention that it's free, otherwise it's implied to cost money.
I'm kind of curious now, how exactly would you have written the parent comment's message?
His post is fine although I would try to spare fellow HNrs a visit to the site just search for basic information like duration and how much it costs or how it compares to similar online resources.
The two languages have nothing in common beyond both being functional, and it kinda feels like someone posted a "Elixir and Elm" blog post in the early days and it all just snowballed arbitrarily from there.
I really like Elixir, a lot. I’ve had Erlang experience and I’ve never understood the hate around it’s syntax. Elixir is definitely more friendly in that regard and I’m glad it’s bringing the tremendous value of the BEAM and OTP to more mainstream development circles.
I think that Elm and Elixir fit their respective development niches (UI, distributed systems) extremely well, both have similar community cultures, and both started gaining some traction at around the same time.
Elm on the other hand inherits Javascript as its foundation, and the browser as its target. Javascript has an anemic standard library, and isn't a functional strongly typed language to begin with. Now since the browser is the target, file size is important, preventing Elm from simply shipping its own runtime + standard library.
If you need raw performance, the JVM is definitely better. If you don't want to have to deal with the inherent tension between a FP language and mutable surroundings, the BEAM is worth a look.
It has the drawback of the frontend language not being as tiny as Elm is, but it has the benefit (which I think is no little benefit) of having the same statically typed language (F#) on both front and back end.
Whether it's "Relatively popular" is hard to say. It's tiny as far as web stacks popularity goes, but in completely functional web stacks it probably has taken a bite already.
Or perhaps, some day, https://github.com/clojerl/clojerl.
[1] http://lfe.io/That's good enough for most people. From experience switching quickly between the two paradigms takes a bit longer than staying with the same one. That is once think about reducers, closures, immutable data it's easier to stay in that mindset then going back to mutable objects and attributes.
I love useful constraints.
Though also Python in a sense already has some extra state visibility by passing self around in member function as opposed to hiding in an implicit this.
I was excited when I discovered accidentally that tuple unpacking in function heads was supported in Python, then depressed when I discovered that was dropped in Python 3, "because no one uses it". Sigh.
edit: FYI, you have a typo:
> This is represented in Maybe‘s definition: type Maybe = Just a | Nothing.
Maybe's type is type Maybe a = Just a | Nothing