Good question :) I was thinking about this a bit the other day. I don't think I particularly recommend it though that might be due to my workflow. I currently get stuff working by manually poking around in the browser, and then I might write tests for it and then I run my script which recompiles with warnings as errors, runs the tests, runs credo and then runs dialyzer.
So by the time I'm running dialzyer, due to its nature & place in the chain, it is isn't really telling me anything useful. It might catch an edge case. More likely it complains about my types as they are a bit off or too general maybe and so I dutifully correct them and commit the changes.
I have the credo set up to tell me about missing types and so I try to go about adding those but they are often just copying and pasting from other controllers or putting some basic get_by(Model.id) :: Model.t in there or something. Nothing that in depth.
Unlike Elm or even Typescript where I'd do some kind of "type driven development", dialyzer feels like I'm doing "type homework" or something.
I think I have worked with the elixir language server a little and so I might get dialyzer warnings in my editor but the warnings are not that informative and it can take a while for the errors to refresh or something so you get left wondering if you've failed to fix the issue or if the cache has just not recalculated yet. I didn't love it.
I can't speak to its use in teams as I've only used Elixir for personal projects. Perhaps the documentation aspect of it pays off in teams or using a CI set up helps drive more value. Not sure.
Honest review! Thanks, Michael. I really love the simplicity and all-in-one feel of mix and the documentation culture.
But your experience aligns with my own experience, albeit it was a short 3 months. It’s still a little too risky then. My team relies heavily on JSON schema validation and type generation (from the schema) to keep our system tied up. Maybe it’ll just be too tough to trust Dialyzer to keep instep for now.
Has OTP and fault tolerance of the BEAM VM come in handy?
I guess my previous comment should also state that I have dialyzer where it is in the workflow because it takes so long to run. It is neither quick enough nor helpful enough to warrant a higher position.
As to OTP & fault tolerance, Fred Hebert's description of the "Let it crash" philosophy (ferd.ca/the-zen-of-erlang.html) was the whole thing that got me into the Erlang ecosystem. But Erlang looks a bit weird so Elixir it was :)
That said, I've not done any OTP myself in anger. I understand that it probably underpins Phoenix and some of the other libraries that I might lean on but I haven't yet found myself with tasks that have been best solved by building my own supervisor tree or agents or anything so I'm still a bit inexperienced with it all.
I came from Django and have enjoyed how snappy Phoenix seems to feel and I have faith in the underpinnings of it and the BEAM and functional programming with immutable data in a way that I don't really have faith in the stack required to get Django serving requests but I can't say I dug deep into it all.
At the moment it is the types that holds me up from truly embracing it. I had a happy 4 years of using Elm for my day job and I find it a bit unsettling to head back to a dynamic language like Elixir and the kind trial & error approach to programming that I have with it.
I am excited by Gleam which adds an Elm like experience (though with a curly brace syntax) to the Erlang ecosystem but at the same time I find myself finding enough value in Phoenix and now specifically Phoenix Live View that I struggle to figure out how much I could incorporate or switch to Gleam for the few projects that I have. I look forward to that community growing though and the libraries & frameworks that will come with it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Good question :) I was thinking about this a bit the other day. I don't think I particularly recommend it though that might be due to my workflow. I currently get stuff working by manually poking around in the browser, and then I might write tests for it and then I run my script which recompiles with warnings as errors, runs the tests, runs credo and then runs dialyzer.
So by the time I'm running dialzyer, due to its nature & place in the chain, it is isn't really telling me anything useful. It might catch an edge case. More likely it complains about my types as they are a bit off or too general maybe and so I dutifully correct them and commit the changes.
I have the credo set up to tell me about missing types and so I try to go about adding those but they are often just copying and pasting from other controllers or putting some basic
get_by(Model.id) :: Model.tin there or something. Nothing that in depth.Unlike Elm or even Typescript where I'd do some kind of "type driven development", dialyzer feels like I'm doing "type homework" or something.
I think I have worked with the elixir language server a little and so I might get dialyzer warnings in my editor but the warnings are not that informative and it can take a while for the errors to refresh or something so you get left wondering if you've failed to fix the issue or if the cache has just not recalculated yet. I didn't love it.
I can't speak to its use in teams as I've only used Elixir for personal projects. Perhaps the documentation aspect of it pays off in teams or using a CI set up helps drive more value. Not sure.
Honest review! Thanks, Michael. I really love the simplicity and all-in-one feel of mix and the documentation culture.
But your experience aligns with my own experience, albeit it was a short 3 months. It’s still a little too risky then. My team relies heavily on JSON schema validation and type generation (from the schema) to keep our system tied up. Maybe it’ll just be too tough to trust Dialyzer to keep instep for now.
Has OTP and fault tolerance of the BEAM VM come in handy?
I guess my previous comment should also state that I have dialyzer where it is in the workflow because it takes so long to run. It is neither quick enough nor helpful enough to warrant a higher position.
As to OTP & fault tolerance, Fred Hebert's description of the "Let it crash" philosophy (ferd.ca/the-zen-of-erlang.html) was the whole thing that got me into the Erlang ecosystem. But Erlang looks a bit weird so Elixir it was :)
That said, I've not done any OTP myself in anger. I understand that it probably underpins Phoenix and some of the other libraries that I might lean on but I haven't yet found myself with tasks that have been best solved by building my own supervisor tree or agents or anything so I'm still a bit inexperienced with it all.
I came from Django and have enjoyed how snappy Phoenix seems to feel and I have faith in the underpinnings of it and the BEAM and functional programming with immutable data in a way that I don't really have faith in the stack required to get Django serving requests but I can't say I dug deep into it all.
At the moment it is the types that holds me up from truly embracing it. I had a happy 4 years of using Elm for my day job and I find it a bit unsettling to head back to a dynamic language like Elixir and the kind trial & error approach to programming that I have with it.
I am excited by Gleam which adds an Elm like experience (though with a curly brace syntax) to the Erlang ecosystem but at the same time I find myself finding enough value in Phoenix and now specifically Phoenix Live View that I struggle to figure out how much I could incorporate or switch to Gleam for the few projects that I have. I look forward to that community growing though and the libraries & frameworks that will come with it.