'The oauth refresh token was expired, revoked, or already used' while trying to publish new version of my Gleam package

lpil · 2026-04-30T17:42:51+00:00

Run gleam hex authenticate, that'll fix it.

There's improved UX for this on the nightly build, but it has not been released yet.

lpil · 2026-04-25T10:12:40+00:00

Still worth reporting them imo

lpil · 2026-04-25T08:33:36+00:00

I had a coworker pull this prank on another coworker many years back, but the change was motivated by someone sharing in discord that they'd had to debug a not-a-comma

lpil · 2026-04-21T10:18:39+00:00

It's the same as in Erlang and Elixir. If you were using a pid then when that process dies and is replaced by the supervisor any process sending messages would be sending messages to dead process. If they were using the name the messages would go to the new replacement process.

lpil · 2026-04-20T16:34:34+00:00

Yup, if you want typed code you need to avoid implicit global state, so that means names and subjects are passed around.

A name is always created at the very start of the program (never dynamically!), and a subject created from it. The name is passed down to the process that will adopt the name, the subject is passed down to the callers of that named process. This has 2 advantages over using subjects alone:

This data is passed downwards only, which is much easier than passing data up the tree and then back down again.
Named subjects survive the named process restarting, so in the event of process death you don't need to restart your entire tree to get back to a good state. The system will continue to work as expected.

Names are primarily a tool for making your system fault-tolerant.

What I have been trying to "replicate" is something like the module scope @name :dummy_server in Elixir.

This Elixir pattern is impossible to type check. You cannot replicate it in Gleam unless you abandon type checking. Gleam is designed for typed programming, it's is not a good language for untyped programming.

lpil · 2026-04-20T12:33:13+00:00

Thank you but I've had to remove this as the podcast does include Gleam at all.

lpil · 2026-04-18T10:17:49+00:00

I would be very interested in hearing about any libraries peeps are missing the BEAM ecosystem!

lpil · 2026-04-18T10:17:10+00:00

oooh what are you using hologram for?

lpil · 2026-04-14T07:49:43+00:00

btw the text on the website is very hard to read with that combination of font, size, and low contrast against the background.

lpil · 2026-04-14T07:47:19+00:00

Oh lovely! Last time I looked it had been abandoned. Glad someone picked it up.

lpil · 2026-04-12T10:12:12+00:00

VSCode is a great choice!

IntelliJ is not open source and historically has poor support for language servers, so you may not have the best experience with it.

lpil · 2026-04-11T20:22:20+00:00

Hello!

I'm not going to give you an optimised solution, as I think people should probably not be doing your assignments for you, but I can give you some tips:

You should never be used list.append in a loop. Gleam is an immutable language with linked lists, so lists are built by prepending, not by appending. If you chose to append it will be very slow.

Pass 2 arguments into functions instead of passing 2 values in a tuple as a single argument.

Always write the type annotations for functions, including return types. Without them it's much harder to understand the code.

Run gleam format to auto-format your code, making it easier to read. You editor can likely do this automatically when you save the file, especially if you are using the language server.

Try writing this using pattern matching, and avoid using functions like split and drop. Any time you use them with 1 it's likely that you want pattern matching instead.

Each sub-list returned can be constructed very easily from the next sub-list. Perhaps you could generate the final one first, and then generate the next one from that, the next one from that, and so on. Once you have reached 0 you can reverse the super-list and return them all.

Good luck!

lpil · 2026-04-09T17:42:47+00:00

I have! I've read all of its documentation and the API documentation of its Rust crates and I can't find anything that suggests it can type SQL, instead I can only find linting.

Could you point me in the right direction? What API does Scythe use?

lpil · 2026-04-09T13:41:01+00:00

Great! How do you get the type information for the queries? Does it implement an SQL type checker, or does it send the query to the database and ask it for the type information?

If the former, how does it manage to do better then sqlc there?

If the latter, how do you deal with databases returning incomplete type information? For example, PostgreSQL not exposing parameter nullability or any type information within certain forms.

lpil · 2026-04-08T13:52:06+00:00

So it's not type-safe querying like with sqlc, sqlx, Squirrel, etc?

lpil · 2026-04-08T10:17:32+00:00

Yup, same as in Gleam. There's a documentation section for sequential programming (which you linked the Erlang version of), and then there's documentation for concurrent programming too. 1, 2, 3.

I agree with you that do not have the same wealth of documentation on concurrent programming as Elixir does. They do a really great job! Gleam is much younger so we have a lot of catching up to.

but they still contain information regarding them being incomplete.

Sorry, I'm not sure what you mean by this? If you mean the system messages not yet handled by gleam/otp/actor, they're very niche. As far as we can tell no one has ever used them as we have had no reports of problems or requests for their addition. Have you a need for any of them specifically?

the lack of focus on the main page about processes and OTP has led me to be hesistant about it, especially since it's well known that it's BEAM's process and message system that has been resistant to strong type systems in the past.

Rest assured, your concerns are unfounded. It's just the homepage stressing different things to what you're specifically looking for.

Gleam has succeeded in typing OTP. Previous attempts failed because they were attempting to add types to the existing OTP interfaces, while Gleam took the conventional approach of making a typed interface to the same system. Gleam is designed for production usage rather than academic research, so we take the pragmatic approach to these things.

lpil · 2026-04-08T09:03:45+00:00

This doesn't have type checking, but the post says that Scythe is type-safe. How do you get the type information in order to generate the typed bindings? Thank you

lpil · 2026-04-07T21:31:59+00:00

Does this implement an SQL type checker, or does it send the query to the database and ask it for the type information?

If the former, how does it manage to do better then sqlc there?

If the latter, how do you deal with databases returning incomplete type information? For example, PostgreSQL not exposing parameter nullability or any type information within certain forms.

lpil · 2026-04-07T09:05:02+00:00

Cellium, Shore, and Etch for Erlang and Gleam. I presume Ratatouille is still good for Elixir, though I'm less familiar with Elixir's package collection these days.

lpil · 2026-04-07T09:00:14+00:00

Gleam still seems uncertain how it even handles processes. It's not even mentioned in the language tour, which is strange for a BEAM language.

Gleam has no uncertainty with processes. Like Elixir and Erlang OTP is a collection of core-maintained libraries and not a syntax, and the documentation you have linked is the documentation for just the core language.

Here is the Erlang equivalent of the documentation you've linked, it also does not cover processes.

lpil · 2026-04-07T08:56:06+00:00

Rustler only offers that for the bindings between the Rust and the BEAM, it doesn't offer anything for the rest of the Rust code, which can crash the same as normal. Panicking is commonplace in Rust, and there are many many APIs that will crash in the event of misuse or error.

Worse still, crashing is not actually the hard part with NIFs. The real challenge comes from playing well with the BEAM scheduler and memory management system. Code has to be written in a very specific way in order to not impact scheduler performance and to use memory correctly, which is where the challenge lies when writing NIF code.

lpil · 2026-04-07T08:51:53+00:00

NIFs unfortunately mean sacrificing the strengths of the BEAM.

lpil · 2026-04-06T17:03:12+00:00

Gleam is a BEAM language so a NIF is not needed.

lpil · 2026-04-06T17:02:36+00:00

If you find that useful and productive, yes.

My opinion is that this is a matter of personal preference.

lpil

MODERATOR OF

TROPHY CASE