474 subscribers
6 photos
1 video
2 files
550 links
python, go, code quality, security, magic

Website and RSS:
https://itgram.orsinium.dev

Source:
https://github.com/orsinium/itgram

Author:
@orsinium
https://orsinium.dev/
Download Telegram
My favorite videos about Elixir:

+ Elixir: The Documentary — a bit of Elixir history, motivation to write a new language.
+ Idioms for building fault-tolerant applications with Elixir — a deeper dive into why Elixir exists, what it solves, how it's different from Erlang.
+ The Soul of Erlang and Elixir — an interesting demo of Elixir features that make it different: hot code reload, observability, supervision, concurrency.
+ Intro to OTP in Elixir — a guide into concurrency patterns and error handling.
+ Elixir Tutorial — very basics of the language: syntax, types, pattern matching.

And if you want to properly learn the language, I highly recommend Elixir School.

#elixir
One of the best things in Elixir is it's metaprogramming capabilities. You can write pretty performant DSLs (domain-specific languages). That means, you can naturally write on another simple language (HTML, SQL, XML, protobuf) inside of Elixir. Maybe, with a bit different syntax but the same semantics. There are some of my favorite DSLs:

+ Ecto is the best ORM I ever worked with. If you used to active record approach, you'll might feel uncomfortable at first, then you'll question why there is some repetition, but when you come through this, you'll see how ingenious are some design ideas in Ecto. Inside, it has a separate module for migrations, for schemas, for queries, for data validation, for database connection. Each module is independent and can be used on its own, but it also plays together very well. And each module has a nice and very natural DSL. For example, if you know SQL, you already can read this query:

Ecto.Query.from(p in MyApp.User, where: p.last_name == "Smith") |> MyApp.Repo.all

+ In most of the languages, when you write tests, you write functions or calsses, inside all dome magic fundtions or methods to assert something... But not in Elixir. In Elixir, you have ExUnit which is so natural way to write tests. For example:

describe "get_user_role"
test "the first user is always admin" do
assert get_user_role(1) == :admin
end
end

+ The same for HTTP endpoints. Usually, you have functions which you register later (or decorate) for expected HTTP methods and paths. In Plug, you kinda just do what you need right away:

get "/hello" do
send_resp(conn, 200, "world")
end

forward "/users", to: UsersRouter

+ Temple is a DSL for HTML. Which is, again, very natural if you know HTML (but less repetitive):

temple do
h2 do: "todos"

ul class: "list" do
for item <- @items do
li class: "item" do
div do: item
end
end
end
end

The elephant in the room is that in Temple you still have all these soup of end's at the end instead of closing tags. Python-style blocks are easier to read but in Elixir you have Ruby-style do-end. The motivation is that because of macros and all that stuff the parser needs to be able to recognize code block without knowing the context. For example, in Python, if is always a test expression and then a block to execute (which can be on the same line as any other block but it's still a block). In elixir, if is just a macro (a function) in which you pass do-end block as the second argument.

+ Re is my first Elixir library, a DSL for regular expressions:

Re.one_or_more(Re.Chars.any_digit) |> Re.compile

#elixir
Learn You Some Erlang for Great Good is the best way to learn Erlang. It's targeted at people who already know a programming language (any) and want to learn more about FP and Erlang. The author really wants to understand it all. There is a separate huge chapter on recursion and thinking recursively, with lots of detailed examples. And the whole book is in the same manner: detailed, with examples, and real-world use cases. It goes from very basic syntax to standard library, concurrency patterns and solutions, testing, distribution and so on. If you ever got interested in Erlang, definitely start there.

Now, about Erlang as a language. Why would you learn it nowadays? Well, the language itself is a bit messy, the syntax is old and alienating, static type checking is bad (and so go-to-definition will often just shrug at you), and there are not so many vacancies for it. However, underneath it is hidden a gem:

+ The best concurrency, distribution, and error handling.
+ Ability to deploy a service that will be running for 40 years without any downtime and will never interrupt a single connection,
+ Painless horizontal scaling until you have servers for it.
+ No bug will ever make everything explode and will never go unnoticed.
+ The best observability.
+ Debugging right on production without any performance degradation.

This is why Elixir appeared. Elixir is a language that provides on top of it a friendly syntax, great metaprogramming, modern package management, logging, some additional distribution primitives. But underneath it lives Erlang and all the same patterns and behaviors.

So, it's worth learning Elixir if you know the pain of distributed systems and want a tool that solves it. And it's worth learning Erlang to know better how Elixir works inside.

#erlang #elixir
Let's talk about type checking of Elixir. No-no, it's no a channel about Elixir yet but I still want to write down some of the research I do in the language.

+ Dialyzer is an Erlang type checker. It's very forgiving and so not so helpful as most of other type checkers in other languages. You can read more about it in Type Specifications and Erlang section of "Learn you some Erlang". For Elixir, it is integrated in Elixir language server and also available as dialyxir convenience wrapper.
+ Gradualizer is a new type checker for Erlang, more strict and gradual. It's still in Alpha but looks promising. For Elixir, it's available as gradient.
+ TypeCheck is an Elixir library to check types at runtime.

#elixir
In Elixir community, there are a lot of talks about PETAL stack for dynamic websites. It stands for Phoenix, Elixir, Tailwind CSS, Alpine.js, and LiveView. The order of components doesn't make sense (except making it sound cool), so I'll cover them out of order:

+ Elixir is a functional programming language that has out-of-the-box scalability, hot reload, and other cool features that each big project needs.

+ Phoenix for elixir is like Ruby on Rails for Ruby. The default web framework. Big, powerful, and popular. Even if you write a very simple and small Elixir web app, you're likely to still use Phoenix for some of the conveniences inside.

+ LiveView is now part of Phoenix. And this is a huge game changer in web development. If you know PHP, it's similar to LiveWire. It allows you to have dynamic web pages where all content is rendered on the server side. LiveView will take care of sending data in both directions through websocket and make sure everything is stable and accounts for tons of corner-cases. At the end of the day, you will have a modern reactive website without writing a line of JS.

+ Alpine.js is for cases when you still need a bit of JS for some frontend-only logic. It's a micro framework. With LiveView, you don't really need React or anything huge like this because LiveView provides you with all nice logic, state management, components, and all that stuff. And alpine.js covers the rest. I used it for filters on my personal website and it works well. Well, it eats too much resources which is noticeable on a phone but it was easy and fun to code. So, I guess, worth it.

+ Tailwind CSS is a controversial one. It's basically CSS in your classes. When I need something low-level, I use CSS. When I need something high-level which takes care of nice defaults and adaptivity, I use bootstrap. And when I mix bootstrap with some custom CSS, I get all the same things that Tailwind CSS promises but with less boilerplate. IDK, I just don't understand yet what Tailwind tries to solve.

Someone even made petal_components Elixir library which contains Phoenix and LiveView components on top of Tailwind CSS and Alpine.js.

#elixir #web #js
An Animated Introduction to Elixir. This is a guide into Elixir with quite an interesting format. Each chapter is build around a code example (similar to Go by example) and when you press the "play" button, you see how the code changes a bit, and on the left there is an explanation for the change, with links and images. Beautiful! It only works on desktop, though.

#elixir