Folks, let’s go easy. No one is shoving a compiler down other people’s throats. Perhaps the initial suggestion could have used more disclaimers, but all of the necessary disclaimers are also in the project’s README.

That’s inaccurate. We actually compile to:

case map do
  %{^key => value} -> value
  ...
end

So the most common case comes first and the fact map.key is equivalent to remove.function() does not slow down its lookup (except in the cases the key is missing, which raises an exception anyway).

Also inaccurate. We do emit warnings in several occasions, for example:

warning: incompatible types:

    map() !~ atom()

in expression:

    # iex:1
    atom.key

where "atom" was given the type atom() in:

    # iex:1
    is_atom(atom)

where "atom" was given the type map() (due to calling var.field) in:

    # iex:1
    atom.key

hint: "var.field" (without parentheses) implies "var" is a map() while "var.fun()" (with parentheses) implies "var" is an atom()

Conflict found at
└─ iex:1: Foo.remote/1

And we have been slowly moving towards emit warnings at runtime but we obviously have to be careful towards that.

In any case, I think this is beyond the point. Those are micro-optimizations and you should write code that is clear. If pattern matching is clearer, then certainly do that. For example, I doubt that the change from map.field to pattern matching will yield any measurable improvement on your application response time.

It’s obvious you’re quite a bright person and have invested significantly in developing tria.

I think diversity with compiler implementations is a healthy thing, there are always lessons to be learned and different perspectives that can yield improvement.

But the statement “just use tria” was a bit naive in my view.

Just look at the the long road to implementing erlangs JIT to where we finally have something viable.

Maybe tria may discover some fertile ground and lead to improved performance, we can only hope.

However “just” jumping to another compiler is not going to be viable for most, until tria reaches battle tested status.

Until then, may be you can identify some selective use cases where tria may prove useful, eg as a set of processing nodes in a cluster where the benefit of tria performance can be realised for some safe subset of the code base.

e.g. does tria work with Nx? would tria be compelling for a numerical compute node? If not, then what is the compelling use case for tria?

Getting actual adoption for some concrete use cases would provide important lessons and feedback until fully semantic Elixir/Erlang compatibility is achieved in tria.

I think clearly communicating and being honest about where the rough edges are is essential.

My sense is you have rubbed the community the wrong way, claiming tria is a drop in replacement for elixir which solves everything when it actually doesn’t RIGHT NOW.

Also think about how could one integrate with say one or more tria nodes in their cluster? This might help with both getting real-world use and ultimately adoption until fully battle tested elixir compatibility is realised.

The benefit of even considering tria needs to warrant the additional risk and complexity and that’s always the challenge.

I don’t think there is a single person in the Elixir community who is convinced, other than you, the author.

You need to change that by being real.

I currently don’t see a compelling reason for tria other than my own intellectual curiosity, but ultimately already have it relegated as an “incomplete elixir implementation by a wannabe who agitates the community.”

I’m saying what most are thinking, but beyond that I actually do think you’re very smart and capable so hopefully you take my suggestion and feedback the right way so that your contributions are constructive and lead to improving the state of elixir in ways we can’t predict.

If you do expect the community to take you seriously and to have any chance of competing against the status quo of Elixir on the BEAM you need to be cooperative rather than antogonistic and identify the compelling use case that tria fills.

Could any of it be incorporated into the BEAM or elixir proper?

Can others even work with you?

Elixir thrives because Jose both leads and works with others towards outcomes that benefit the community. I am sure if collaboration was possible it would have already happened.

However if tria js just an academic excercise in compiler writing to be able to say “FIGJAM” then please ignore my post while the rest of the elixir community continue to ignore you and tria.