- atoms
- everything (or most things) is a macro, even def, etc.
- pipes |>, and no, I don't want to write a "pipe" class in Python to use it like pipe(foo, bar, ...). 90% of the |> power comes from its 'flow' programming style.
- true immutability
- true parallelism and concurrency thanks to the supervision trees
- hot code reloading (you recompile the app WHILE it's running)
- fault tolerance (again, thanks for supervision trees)
That said, in my personal experience with uv, it solves nearly all of the problems I've come across that were created by other python package management tools. It seems to have been very thoughtfully designed and I think there's a strong chance it'll become the standard, and that there won't need to be more standards after this. We'll see!
Well, The whole language itself is built on macros. The following series of articles certainly helped me stop worrying and love the macros..
https://www.theerlangelist.com/article/macros_1
Some interesting insights from the article: "Elixir itself is heavily powered by macros. Many constructs, such as defmodule, def, if, unless, and even defmacro[1] are actually macros...."
[1] https://github.com/elixir-lang/elixir/blob/v1.18.2/lib/elixi...
So one could write
class Piped:
def __init__(self, value):
self.value = value
def __or__(self, func):
return Piped(func(self.value))
def __repr__(self):
return f"Piped({self.value!r})"
Piped('test') | str.upper | (lambda x: x.replace('T', 't')) | "prefix_".__add__ # => prefix_tESt
counts = (
lines
| 'Split' >> (
beam.FlatMap(
lambda x: re.findall(r'[A-Za-z\']+', x)).with_output_types(str))
| 'PairWithOne' >> beam.Map(lambda x: (x, 1))
| 'GroupAndSum' >> beam.CombinePerKey(sum))