andrenth
Hello
I’ve done some Erlang a long time ago and now I’m returning to the platform via Elixir. One the few things syntax-wise that I feel is sub-optimal is how you call Erlang functions, i.e., :module.function(...). It just looks a bit odd to me, although I do understand why it is this way.
Wouldn’t it be cool if we could use the same transformation done in keyword lists ([{:foo => 1}] being the same as [foo: 1]) and call module:function(...) instead, just like in Erlang? ![]()
Trending in Discussions
As the title says, please share what you’ve been up to with Elixir. Whether that’s been learning it, looking into it, making stuff with i...
New
Hey there,
It’s been more than a year since we started using LiveView as our main UI library and building a whole library of UI componen...
New
I want to open this thread for you all to discuss and help those who really like Ash but are still hesitant to use it in a real project. ...
New
I am happy to introduce the very α version of the new programming language compiled to BEAM.
Welcome Cure.
It has literally three kille...
New
Quite interesting article Google brought me. Didn’t find any mentions about it here.
What do you think in general? Would you use togethe...
New
It would be helpful to have a list of companies worldwide that hire engineers without prior experience in Elixir. Often, it can be quite ...
New
Anyone running long-lived stateful processes on BEAM? We’re building an AI agent runtime and would love to compare notes.
We’re a small ...
New
Other Trending Topics
Hi there! We created Gust: A task orchestrator inspired by Airflow.
For those who have never heard about Aiflow, it’s a Python-based wor...
New
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge & Solve.
They are GUI (Emerge) and State management (S...
New
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
Aludel - LLM Evaluation Workbench
Aludel is an embeddable Phoenix LiveView dashboard for evaluating and comparing LLM prompts across mult...
New
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming










Most Liked- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
Qqwy
I have an alternative for you:
hauleth
The point is that the current syntax is in par with the whole rest of the language, as
Foo.bar()is the same as:'Elixir.Foo'.bar()(with exception for the aliases). So adding new call syntax would mean thatFoo:bar()also would became valid call. While this could simplify some things (it would provide difference between function call and map access) I think it would be too confusing, especially asfoo. bar()is valid syntax andfoo: bar()will not be.hauleth
Why and how would you do that in case of non-core modules? Like
poolboy?