4 ms·
Phoenix is pretty nice, but its (or Elixir's, rather) biggest weakness is the lack of static typing.
by ylyn 4y ago
Phoenix is pretty nice, but its (or Elixir's, rather) biggest weakness is the lack of static typing.
- bongobingo1 4y agoAFAIK there was some posts by Jose Valim on twitter about static typing exploration, I think it was spurred on by their work with NX/Numbat (scientific Elixir libs). Twitter wont let me view more than 3 tweets without making an account so I can't find it...
- krstf13 4y agoHe talked about it at length at the most recent elixir conf eu : https://youtu.be/Jf5Hsa1KOc8 https://youtu.be/Jf5Hsa1KOc8 .But it might never materialise.
- aaaaaaaaata 4y agohttps://nitter.42l.fr/josevalim https://nitter.42l.fr/josevalim
- yellowapple 4y agoHaving written a fair bit of Elixir and Erlang code over the years, I don't feel like I miss static types much when I can readily pattern match on tagged tuples.
- sethammons 4y agoHaving written Elixir code for about a year and coming from Go, I miss static types dearly and specs are not enough. I have to dive into the code to know what I'm working with locally. My largest frustration is all the unhandled errors and exceptions that will not have the required context when they finally crash some process. It is apparently uniodiomatic to capture details in structured logs.
- vasergen 4y agoWhat is your experience with refactoring, especially a big project? This is where static typing helps a lot ihmo. Especially if you are in a startup like environment where things tend to change quickly.
- yellowapple 4y agoFunny you ask that, since I have indeed refactored OTPCL (a sort of Erlang-flavored Tcl-flavored scripting/config language I've been on-and-off hacking on for the last couple years) multiple times now, namely to rewrite the parser and to rewrite how command exports work - so the commit history should reflect some of the pitfalls and boons I encountered. I actually did pursue static typing (w/ type annotations and Dialyzer) at one point, but quickly lost interest, since it didn't really seem to add much. Having comprehensive tests, on the other hand, was crucial - especially since I could use pattern matching within those tests to make assertions about expected inputs and outputs. I will say that there were bugs that compile-time type checking probably would've caught, but tests also readily caught them. The same can likely be said for current bugs. It's ultimately the same idea: validate that your code adheres to the expected API and behavior; only difference is that the validation happens in different places.
- chasers 4y agoPattern matching and structs get you 90% of the way there imo. And Elixir started emitting warnings if you try to access a field in a struct and it doesn't exist.
- Multicomp 4y agoYeah thats why I'm keeping one eyeball on Gleam[1] which is a 'statically-typed Erlang/Elixir', when that hits 1.0 that's when I will put down my F# SAFE stack stuff and give it a try. [1] https://gleam.run/ https://gleam.run/
- nprateem 4y agoAnd that no one knows it. Unless you're prepared to do all the coding yourself or pay top dollar to recruit it's best to avoid exotic languages.
- eterps 4y agoI don't necessarily disagree with that sentiment, but you can also attract very good developers when you don't avoid exotic languages.
- ramchip 4y agoThat's a bit of an oversimplification. If you're OK with remote, it's not hard to find Elixir devs. You can also start with just one or two senior people, and for the rest hire people with web experience (or whatever else is useful) in other languages. There was a company hiring lots of Elixir devs that actually hired straight from bootcamps - I forgot the name unfortunately, they had an interview on the Elixir blog or Adopting Elixir book or somewhere like that...