r/gleamlang

...just cuz, it's a bit of a pain to import these symbols at the top of a file each time.

Especially when your code changes a wee bit, then one of the symbols becomes unused and you get yelled at by the compiler that you have an unnecessary import, then later you want to use it again and the import line changes again, etc.

Just wondering if a value such as e.g.

Ok(#(Nil, [], []))

is recognized by the compiler as something that a constant that can be constructed-once-used-forever or if I need to give it a hint by declaring such a value as const my_const = Ok(#(Nil, [], [])) outside the function to get better performance.

I.e., will

const my_const = Ok(#(Nil, [], []))

pub fn some_stub_i_need_to_fill_out_will_be_called_a_lot(_, _, _) {
  my_const
}

get better performance than

pub fn some_stub_i_need_to_fill_out_will_be_called_a_lot(_, _, _) {
  Ok(#(Nil, [], []))
}

or not?

Hi,

What are you using to vibecoding a gleam code? Is kimi good with it? And how about Codex?

Thanks

Let me start saying that I don't believe on perfect languages. But I quite think that Gleam may be what I was looking for for quite some time. But I'm confused with it's position on the Beam ecosystem.

I do program a lot in Go, and I do value the simplicity of the language, but at the same time the type system is so damn simplistic, to a point I can't program on it anymore. The issue is, a better type system becomes way too complicated as it tries, but it's not required, to add all features under the sun. For example, I was working with Scala using Cats on a previous job, and oh my God, indeed, very powerful, but the complexity is just unbearable.

From my experience this is what makes a good language to me:

• Simplicity. This is so subjective, but think on this like: can I learn the language in a weekend or does it take a full year? Go x Haskell
• Compiled
• Errors as values
• Async by default and without function coloring
• ADT
• Immutability
• Good visibility control of fields, structs, functions, and packages
• No nulls and rely on Option/Result types

I think Gleam checks all of this, right? Just the compilation that is not there, but I could live without it by having everything else.

The question now in my head is, why Gleam when Elixir is getting a type system? I did program a little in Elixir, I find it amazing, but being dynamic was such a deal breaker for me. I was very excited to know that José was working on a type system, but I still don't understand to which degree it will extend. From what I was able to read, and understand, it will fill kind of progressive typing and it will not be as strong as Gleam is right now.

Right now I'm working with Rust, despite it's complexity, but dealing with all those lifetimes/borrowing is something that I really don't like. I'm not building a billion requests per second service.

The goal is to make it easy to share data between a Gleam application and an application written in another language (one of the 12 languages that Skir supports).

I would love to hear what the Gleam community thinks of it.

At work, I develop AI agentic workflows in Python (using Pydantic AI, LangChain, etc.).

I came to Gleam because I was looking for the perfect language for AI-assisted coding, convinced that simple syntax, fast compilation, and functional programming are even more important attributes once an LLM writes the code.

But it seems there is no mature library in Gleam for easily developing AI agentic applications (I only found Jido in Elixir).

I would be interested in starting one (inspired by Pydantic AI, TanStack AI, etc.).

Before spending too much time on this project, would anyone actually use it if such a library existed?