There are two sides to compatibility with Elixir: using Gleam in Elixir and using Elixir in Gleam. The former is harder, the latter is easier (with caveats).

Using Gleam in an Elixir project did/does rely on mix_gleam. I've used it some years ago and it worked then, but I haven't had recent experiences. There is a pull request[0] to Elixir to add built-in support for Gleam and as I understand it the Gleam team have made several changes to Gleam tooling to facilitate it, but it's unmerged as of now.

Using Elixir in a Gleam project is just an external function away, just like using Erlang or JavaScript (when using the JS target). E.g.

  @external(erlang, "Elixir.Some.Module", "my_fun")
  fn my_fun(some_arg: Wibble) -> Wobble

The two main issues on that side are macros and structs. Since Gleam doesn't know about Elixir source or Elixir macros, you can't use them directly. But you can have an .ex file that uses macros and then you can call functions from that file. Structs are trickier, because they're just dynamic maps with a special key-value pair, and maps in Gleam (called Dict) have fixed types for the keys and values. That means you can't model a struct as a Dict. Gleam uses records for its own custom types, so what you can do is either use records on the Elixir side (with the Record module or by hand), or map the Elixir side data structures to be more palatable for Gleam (and vice versa) in your external functions --- which is what you generally do with externals anyway. Of course, if you only intend to pass the Elixir structs around and then back to Elixir, you can model them as external types that are then opaque to Gleam.

[0] https://github.com/elixir-lang/elixir/pull/14262

is this not adequate?

https://gleam.run/frequently-asked-questions/#Can-I-use-Elix...

In that Tencent study less common languages got easier problems. Which explains why racket also performed suspiciously well in it. The authors recognize the problem themselves. I like elixir, but it's imo embarrassing how often elixir people cite that study despite it not actually supporting what they claim.

A much more recent and imo more realistic comparison of different languages with ai, is openai's study reimplementing sqlite in different languages: https://openai.com/index/low-resource-programming-languages/

That showed about what we expect, that popular languages like python, javascript, java, C#, etc do best, while less popular languages like Common Lisp, Ocaml, Zig, etc do slightly worse. But the difference is small enough I'd still just choose whatever language and ecosystem I know best that is appropriate for a project.

Lots and lots of production code to train AI models.

Only if they gain that ergonomic advantage without complicating flow of control. Metaprogramming is costly for example, in the past so have been operator overloading and lazy evaluation.