Sadly you haven’t got any answers. I cannot give you any either, sorry.
To be honest, though having bought many Elixir books, I haven’t read half of them as the last months I get slowly “detached” from Elixir because of the fact that the ressources always lack at least one of this aspects, if not many.
If I continue learning Elixir, I want to learn it as “right” as possible. Haven’t wrote any elixir code for two months now. It’s a pity, as the language is great and this forum is great, too. I hope something brings my enthusiasm back I haven’t had since rails 15 years ago.
By “keyword lists in function signatures” do you mean typespec for keyword lists? You don’t really need to use typespecs at all if you don’t want to. Typespec link I provided should have info on it. Elixir HexDocs is your friend.
This is a pretty broad and rather strange statement.
The way out of something like this is to open-source something and ask for reviews IMO. I feel that most Elixir books authors think that everybody has to code in their own style, or they aren’t focusing on teaching coding style and what they might feel is an “idiomatic” Elixir.
My suggestion, if you feel you know Elixir well, but you want to step up your practical Elixir coding skills, would be to read the codebase of some quality open-source projects. The source code of Elixir core library is a great place to start, as well as delving into libraries that you use, and possibly contributing to them.
Subjective opinion here: I would not stress too much about what is idiomatic or not, but rather develop a sense for which codebases are easier to navigate and why. Reading other people’s code helps in this respect, because we always approach it as “beginners” with little context. As developers, I think we focus too much on code style on a superficial level (stuff that linters can enforce) and too little on deeper aspects of what increases/decreases cognitive load.
I just mean using keyword lists as function parameters. E.g., this mentions it:
keyword lists [are] the default mechanism for passing options to functions in Elixir
But the books & instructional materials I’ve read so far haven’t made use of this. And I think I might have had some trouble pattern matching with keyword lists when I last tried it…
Absolutely. Main focus should be readability and very quick onboarding of a stranger. Some people also focus on as little coding lines as possible which is IMO also a wrong metric.
Yes it should be explained better in that document. I haven’t had this problem because what I usually do is look at code made by core team like Ecto as example. I think it would be very helpful for future users if you created issue for this to https://github.com/elixir-lang/elixir repo, that keyword list function options need to be explained better.
Ecto uses parameter named opts that is a keyword list for lot of its functions to provider optional options. Maybe these will help you show how it’s used.
After, for the tests suite, I’m practicing it in Phoenix Programming 1.4. For the rest, I can’t say.
I recall having used defdelegate in Dave Thomas course on Elixir, where you build a hangman, people says that he wrote idiomatic Elixir code, and we write test all along.
I’ve found defdelegate kind of annoying when using Visual Studio Code because it makes code navigation lot worse. At least when using Elixir-lsp extension.
I agree with everything you said about the Elixir culture. I guess I’ve got some baggage coming from the Ruby world: Never-ending DSLs and methods with open-ended options which aren’t well documented and not error-checked. In fact, even the rails command line app doesn’t check many of the options given and will silently fail in some cases.
I may be going off on a tangent here, but I find the best way to learn idioms of a language is to read code. Reading skills don’t seem to be taught much in colleges and bootcamps, but it is an extremely valuable skill. With so much open source out there, pick a project with experienced developers you respect, and read the way they wrote the code. You’ll learn so much more than any blog or video can teach. You’ll actually build up your own intuition for not only what the idioms are, but why they’re not something different. If you just pick this up from books/blogs/videos your answer to “why” questions is likely “because #{person} said so” instead of the core underlying reasoning they used.
So actually, I’m not looking for resources for learning idioms. Rather, I’m looking for resources that are idiomatic. I.e., the code samples follow real-world practices. E.g., not skipping specs and @enforce_keys simply because it’s sample code.
Basically, I want to be coding using best practices all the time, and not needing to tack on that knowledge later on.
I can’t speak for most of the books out there. But I can tell you that Functional Web Development with Elixir, OTP, and Phoenix followed all of our “real-world practices”. We didn’t use the dialyzer and thus didn’t write specs. We didn’t use @enforce_keys because it creates brittle systems that are resistant to growth. I don’t believe you can definitively say that authors are leaving these things out for the sake of brevity. It might be that the authors don’t consider those to be “best practice” in the first place.
Thanks. Yep, I’m interested to learn how these features are used.
Personally, I’m a believer in strong typing for domain modeling. I find it analogous to database constraints. I actually use Haskell for data import & JSON production so that I can lock down & guarantee my data and attributes. I haven’t had a problem with brittle code. During development when I’d find that I needed to change my model, I’d make the changes and then the compiler would guide me to the code that needed to adapt.
What kind of growth are we talking about? If this is about rapid prototyping where you release 3 times a day then I’ll agree. But outside of that extreme case having stricter checks will definitely save you from mistakes made by tight schedules which will then tighten those schedules even further due to having to frantically fix bugs.
I don’t know the exact context and I might be way off but this is how it shook out for me, many times. Stricter checks intuitively feel annoying when you just want to build something quickly but they can also save a lot of time.
