We love this stack, and dailydrip and elixirsips have helped us get a lot of the knowledge we have. Josh does an awesome job at explaining the technology in a step by step fashion that is both concise and easy to understand.
Integrating Elm and Phoenix Channels via Elm-Phoenix-socket
11–20 of 76 posts
Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket
#12Elm and Phoenix really seem like a perfect match for each other
They're both very functional, but it's an interesting matchup given that Elm is very strongly typed and (according to my understanding) Elixir is totally dynamic. For those who are developing with both, I'd be interested in hearing if there's a reason why types would be more useful on the client than the server or whether there's another motivation for those particular choices.
I'm glad to dive in. On the client, fault tolerance is basically not a concern of mine. On the server, it's the most important concern. I find it more useful to think of Elixir as a highly concurrent language built for fault tolerance, where Functional Programming was a necessary requirement to get there. Jose has a great post on this here: http://blog.plataformatec.com.br/2016/05/beyond-functional-p...
Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket
#13Elm and Phoenix really seem like a perfect match for each other
They're both very functional, but it's an interesting matchup given that Elm is very strongly typed and (according to my understanding) Elixir is totally dynamic. For those who are developing with both, I'd be interested in hearing if there's a reason why types would be more useful on the client than the server or whether there's another motivation for those particular choices.
If you want some more fun, you should check out this: http://package.elm-lang.org/packages/elm-lang/core/4.0.1/Pro... (see the last paragraphs). I am hopeful that we will see an Elm backend running on the BEAM eventually.
Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket
#14Elm and Phoenix really seem like a perfect match for each other
They're both very functional, but it's an interesting matchup given that Elm is very strongly typed and (according to my understanding) Elixir is totally dynamic. For those who are developing with both, I'd be interested in hearing if there's a reason why types would be more useful on the client than the server or whether there's another motivation for those particular choices.
Look at Dialyzer and http://elixir-lang.org/getting-started/typespecs-and-behavio...
Also, Elixir community... there seems to be a paucity of awareness of Dialyzer and Typespecs. Perhaps they could be more prominent? They're included in the reference docs, but not really so much in a way that indicates what they are or how one would use them when writing their own software in Elixir.
There are many, many classes of problems that can be discovered before they're discovered at runtime. It's made a little harder in Elixir-land due to limited Map support in Dialyzer and Map usage being extremely common in Elixir code, but still spec'ing your functions is a good practice and habit to get into anyway.
Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket
#15Earlier quoted context omitted.
They're both very functional, but it's an interesting matchup given that Elm is very strongly typed and (according to my understanding) Elixir is totally dynamic. For those who are developing with both, I'd be interested in hearing if there's a reason why types would be more useful on the client than the server or whether there's another motivation for those particular choices.
I'm glad to dive in. On the client, fault tolerance is basically not a concern of mine. On the server, it's the most important concern. I find it more useful to think of Elixir as a highly concurrent language built for fault tolerance, where Functional Programming was a necessary requirement to get there. Jose has a great post on this here: http://blog.plataformatec.com.br/2016/05/beyond-functional-p...
Browsers have fault tolerance built in: the reload button.
Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket
#16Elm and Phoenix really seem like a perfect match for each other
They're both very functional, but it's an interesting matchup given that Elm is very strongly typed and (according to my understanding) Elixir is totally dynamic. For those who are developing with both, I'd be interested in hearing if there's a reason why types would be more useful on the client than the server or whether there's another motivation for those particular choices.
I think the static/dynamic client/server split is more coincidence than brilliance.
Elm and Elixir are like two neighborhood kids growing up together as best buddies. They are both new, functional, webby languages with communities that are very friendly and very interested in inventing new ways to make programming better. It's natural that both groups would be excited about working together.
Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket
#17Earlier quoted context omitted.
They're both very functional, but it's an interesting matchup given that Elm is very strongly typed and (according to my understanding) Elixir is totally dynamic. For those who are developing with both, I'd be interested in hearing if there's a reason why types would be more useful on the client than the server or whether there's another motivation for those particular choices.
Look at Dialyzer and http://elixir-lang.org/getting-started/typespecs-and-behavio... Also, Elixir community... there seems to be a paucity of awareness of Dialyzer and Typespecs. Perhaps they could be more prominent? They're included in the reference docs, but not really so much in a way that indicates what they are or how one would use them when writing their own software in Elixir. There are many, many classes of p…
The latest Erlang release fixed the Map problem with Dialyzer. It was entirely the reason I was lax with specs. I'd love to get a workflow more like this one: https://medium.com/@barruumrex/seeking-simple-satisfaction-2...
Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket
#18How come no one (seemingly) uses Elm, despite all the love? I've noticed a lot of quick, drive-by posts in Elm related threads about how great the language is. This thread ("This is a great little webstack!") and today's other front-page elm thread[1] both do this.
With such high praise, I would expect the language to be more popular. What's with the disconnect? My hypotheses:
1) There are no unhappy users because unhappy users just don't use it. 2) HN goes easy on technological curiosities, saving harsh criticism for large projects that deserve it 3) While there may be a widespread lovefest for Elm, there is too much momentum behind current technologies.
Any other thoughts as to what the disconnect is? Moreover, how do we get to a world where the webstack we all use is "a great little webstack"?
[0] https://news.ycombinator.com/item?id=11846707
edit: clarity
Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket
#19How come no one (seemingly) uses Elm, despite all the love? I've noticed a lot of quick, drive-by posts in Elm related threads about how great the language is. This thread ("This is a great little webstack!") and today's other front-page elm thread[1] both do this. With such high praise, I would expect the language to be more popular. What's with the disconnect? My hypotheses: 1) There are no unhappy users because un…
I've heard that interpolation with existing JS libs is painful.
Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket
#20How come no one (seemingly) uses Elm, despite all the love? I've noticed a lot of quick, drive-by posts in Elm related threads about how great the language is. This thread ("This is a great little webstack!") and today's other front-page elm thread[1] both do this. With such high praise, I would expect the language to be more popular. What's with the disconnect? My hypotheses: 1) There are no unhappy users because un…
This is a great point, and I think it is because the language is still really new. The language syntax and patterns have just firmed up with the 0.17 release. I think it just needs some time for additional adoption.