Proposal: Custom Targets

[abueide]

Hi, I'm really a huge fan of @PgBiel's work on the glistix project. I'd really like to start getting involved and adding support for the nix target for some core gleam libraries. However it is difficult to upstream changes to libraries supporting newer / experimental platforms, since as soon as you do the gleam toolchain errors out complaining about the platform that doesn't exist. I'd love to implement some nix bindings for the gleam json library, so I want to start thinking about what the process could look like to make the bootstrapping of new/experimental targets a bit more friendly, so new efforts can get started without needing to fork the entire world, and enable more collaboration with upstream libraries who don't want to change their toolchain to some new experimental compiler, but wouldn't mind adding the targets to their branch for users who are playing around with the experimental target / compiler.

I'm imagining this would work by modifying the main upstream gleam compiler to ignore any code blocks that specify an @target(SomeExperimentalTarget) that the main compiler doesn't recognize. This will allow us to contribute bindings for experimental targets without breaking the upstream project's workflow, ci, etc when they're using the mainline gleam compiler.

I think it would also be relevant to start thinking about processes for upstreaming experimental targets into the mainline gleam compiler. What would it take to upstream the nix into the compiler under an experimental flag, disabled by default? What would publishing libraries with the nix target enabled to hex.pm look like?

Let me know what you guys think!

[lpil]

Hello there!

I'm not willing to take on any maintenance burden to facilitate forks, or to in any way formally endorse any forks. Gleam isn't a project for creating new backends and I want to exclusively focus on achieving the goals of core Gleam, which further fragmentation hinders rather than helps.

The Nix fork specifically doesn't preserve the semantics of the language due to its mixed strict and lazy evaluation styles. With this I would call it a different language, and think would benefit from libraries design with its semantics in mind.

Use of the target system is strongly discouraged. The goal is to deprecate it in future, for removal with a Gleam v2.

Once we achieve all our goals we could revisit having an API for alternative backends, providing we have sufficient funding. I'd estimate this would be 10+ years from now.

Sorry this isn't very helpful from your point of view!

[PgBiel]

Hey @abueide! First of all, I appreciate your interest in my project. Unfortunately, we'll probably be a bit on our own here for a while - but I think it's entirely fair that maintainers, with their limited resources, will want to focus more on improving Gleam's main targets, as that's the main goal of the project.

Although I've also wished for a simple mechanism to "ignore" invalid targets in the past, even if - regardless of the @target system - it were just for @external, since that would be enough to implement target-specific behavior. But, although that would be quite simple to implement, I can see that (as Louis mentioned) there could be some reservations regarding "endorsing" forks, or the potential of having new people assume Gleam's maintainers are in a position to help them with forks.

---

With that said, there are already bindings for gleam_json maintained by the Glistix project itself: https://github.com/glistix/json
Of course, it's a fork, so there are some annoyances to be able to use it and have dependencies recognize it. But it's there!

In addition, you can contribute to the project in other ways! I'd love some help in moving overall things forward, including implementing remaining Nix ports of stdlib functions in https://github.com/glistix/stdlib, or helping me design Nix-only libraries (such as Nixpkgs and NixOS config APIs). My time tends to be quite limited as life demands I work on other things simultaneously 😅, so the project ends up falling behind a bit... My dream here is to be able to write more complicated Nix logic in my own configs using Gleam.

If this sounds interesting to you, you could join our Zulip for further discussion: https://glistix.zulipchat.com/join/dj7k33san27nujoppkmuqalc/

(It turns out the Zulip link on the README had expired... I'm sorry 😅)

Thanks again for your interest and for promoting this discussion! 😄