How serious you are about not supporting atoms?

[pwtail]

Are you really not planning atoms support? If so, what is the reason behind that? I think, of all gleam features that look questionable to me the absence of atoms is the elephant in the room.

Considering the fact that strings cannot be pattern-matched effectively (as I understand, a string is matched as a list of characters), it's like strings are missing from the language. People are used to using strings.

And there is also map structure in gleam. Isn't it a smarter thing to use atoms as keys? Because I see "strings" in the examples. And as I said, strings can not be pattern-matched effectively.

Are there really any downsides to adding :atoms?

[lpil]

Atoms are supported, custom types are atoms!

% in Erlang
-type mode() :: on | off.

pub type Mode {
  On
  Off
}

There's no plan for a literal syntax for untyped atoms, but they can be used with the atom module in the gleam_erlang package.

Considering the fact that strings cannot be pattern-matched effectively (as I understand, a string is matched as a list of characters),

Gleam uses binary strings and can be matched on performantly.

And there is also map structure in gleam. Isn't it a smarter thing to use atoms as keys?

The key type of the Map type is parametrised and can be any type, including atoms.

[pwtail]

Gleam uses binary strings and can be matched on performantly.

That fully answers my question. Thank you!!