Great find, grabbed that. Thanks!

As someone who learned Elixir during the Phoenix 1.7 release, let me tell you: If you downgrade to Phoenix 1.6 and learn from there, you should be fine.

The upgraded versions are mostly the same, but the differences in Phoenix 1.7 are enough to break the tutorials enough to confuse a newbie. Now, in the post-LLM age, that's not nearly as bad. But it was a real pain when I was learning.

what do you mean by 'security related concerns'?

Fair. If you have this friction then it's not worth pursuing.

One thing that really helped me pick it up was saying YOLO and rewriting one part of the business stack from Ruby on Rails to Elixir. It taught me quickly and well.

The official guides are also great and IMO you can get through them all without a rush in two weekends. But again, if you don't want to then don't.

You can also try asking right here in this HN thread. Maybe I or others would be willing to give you a more detailed response.

I haven't dug into this for a while, bit you should be able to define a catch-all event to return a respond to non-compliant requests . It should be built-in to some degree IMO, but I think it's not an unsolved problem.

> whether you understand the answers is a whole different story.

You can always ask follow up questions for clarification, people there are generally really friendly.

why did you give up on Rust?

Cookbooks are imperative, sure. But not every book is a cookbook.

Religious texts, philosophy, ethics, and even self-improvement books often don't provide a procedure to follow. They teach things like how to handle conflict, how to act fairly, how to navigate difficult situations, or how to reason about competing values.

People then take those ideas and apply them across many different situations in their daily lives. In a sense, they build a toolbox of reusable mental functions rather than memorizing a single algorithm.

That's also why many people finish a self-improvement book feeling like they didn't get much out of it. They were expecting a recipe. Instead, they absorbed a collection of abstractions that only reveal their value when applied later in real situations.

The fact that cookbooks are imperative mainly shows that procedural tasks are naturally expressed procedurally. It's not obvious that this generalizes to human reasoning as a whole.

> I keep itching to design a compiled functional language for games

Jank wants to be this, right? IIRC its author and chief maintainer was a game dev before he dedicated himself to the language.

https://jank-lang.org/

Maybe porting your engine would be a great way to prove out Jank 1.0 when it arrives ;)

It's not like you're dealing with hundreds of thousands of ad-hoc processes. If you're writing a web server, for example, each of these processes might simply be a client connection and they all operate the same. The fact that there are 2 or 100,000 is only a problem for the BEAM scheduler.

Sounds like there is some foundational knowledge of Elixir that you miss and everything seems more confusing than it should be. To me writing a 'server' in Elixir is orders of magnitude easier than doing it in Python, Rust or C++.

As someone else suggested, bring your concerns to the Elixir Forum and surely someone will clarify them for you

> Elixir is having to handle (possibly) hundreds of thousands of processes

OMG, why? Why would you ever have so many processes? All of them at the same time? Are you going to animate a 3D scene and run a process for each vertex, or something?

No, I mean, if you're WhatsApp - across all nodes - then somehow maybe yes? At scale. But in normal code, slicing workloads too thinly is counterproductive, and having even tens of thousands of processes is a sign that you're slicing it way too thin. Message passing between processes is cheap, but not free. Schedulers do a good job, but rarely have more than 16 cores to work with. And so on.

You can have that many processes if you want, to be sure. But if you're struggling with it, why would you want it?

Reading your comments in this thread, I have a feeling you just didn't spend enough time reflecting on how you want to use Elixir. In effect, you also failed to consider how exactly you should learn it. For example: Elixir is a perfectly capable procedural language. Start by writing CLI tools, without spawning any processes at all. Then try to parallelize their processing. If the tool accepts a list of files as arguments, use a `Task` to compute return values for each file. Tasks are processes, but with a particular contract that simplifies their usage. Later, you can experiment with error handling and supervision by putting the tasks under a supervisor. And so on. You go from the familiar to the less familiar, with a useful, working tool every step of the way.

But would be even harder to wrap your head around if you tried to implement similar capabilities in Java.

I love Elixir and Phoenix, but Phoenix especially uses a lot of compile-time macros and it can be a steep learning curve when you need to pull apart the skeleton framework to figure out how things are actually wired.

I pretty frequently find myself needing to open up the source to understand what's actually going on, the docs aren't bad but it often feels like they assume a lot of existing familiarity with phoenix.

In this example, `socket` is a compile time macro and it's being called with

    path = "/ws/:user_id"
    module = MyApp.UserSocket
    args = [
      websocket: [
        path: "/project/:project_id"
      ]
    ]

and what is does is register that data with the `phoenix_sockets` attribute inside the module you called `socket` from. At compile time that gets turned into a lookup inside your module, and presumable then the UserSocket module is invoked when a websocket request hits the specified path.

Would you find it more clear if socket was called like this?

    socket("/ws/:user_id", MyApp.UserSocket, [websocket: [path: "/project/:project_id"]])

Or, alternatively, would it help if the endpoint was more specifically defined like

    defmodule MyApp.Endpoint do
      use Phoenix.Endpoint, 
        otp_app: :my_app,
        web_sockets: [
          socket("/ws/:user_id", MyApp.UserSocket, [websocket: [path: "/project/:project_id"]])
        ]
    end

    example("with", 3, extra: "arguments", as: "a", keyword: "list")

    example("with", 3, [extra: "arguments", as: "a", keyword: "list"])

    example "with", 3, extra: "arguments", as: "a", keyword: "list"

> Elixir gives you too much freedom on how to write something on a syntax level

This is true perhaps compared to python or go, but not compared to Java, JS/TS, or some others.

> socket "/ws/:user_id", MyApp.UserSocket, websocket: [path: "/project/:project_id"]

Socket is a behavior, which is like a trait or interface. MyAppWeb.UserSocket implements the behavior. It's basically a convenience over having to write a bunch of repetitive WS or long poll handling every time you want a socket like thing. Its pretty well documented https://phoenix.hexdocs.pm/Phoenix.Socket.html.