HUhuevosabio·Sep 17, 2025
Not to be confused with gluon the embbedable language in Rust: https://github.com/gluon-lang/gluon
In Gluon: a GPU programming language based on the same compiler stack as Tritongluon-lang
gluon
Rust2017–2025
gluon-lang / gluon
gluon
A static, type inferred and embeddable language written in Rust.
14Distinct people
14Mentions
0Explicit recommenders
3.5KGitHub stars
What to know before exploring
What it is
A static, type inferred and embeddable language written in Rust.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- pistondevelopers/dyon · linked in 4 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year14 dated mentions
Observed mentions: 2017-07-07 08:14:00 UTC to 2025-09-17 21:04:46 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 0 | 2 |
What Hacker News says
14 sourcesThere's Gluon, which doesn't share Rust's syntax but does have a Hindley-Milner-based type system and embeds pretty seamlessly in a Rust program.
https://github.com/gluon-lang/gluon
In Pyrefly vs. Ty: Comparing Python's two new Rust-based type checkersGluon: A static, type inferred and embeddable language written in Rust
1 points · Open discussionThis should be a good use-case for rust-based scripting languages, I think.
I loosely followed a project of that kind a while ago, I don't quite remember if it was Gluon [0] or Dyon [1]. Not sure if these are still active, or if another competitor showed up in meantime.
___
[0] https://github.com/gluon-lang/gluon
[1] https://github.com/PistonDevelopers/dyon
In Fornjot – The world needs another CAD programGluon: A static, type inferred and embeddable language written in Rust
2 points · Open discussionSimiliar to GP, I too have been wondering about a Rc'd Rust.
Unfortunately Rune and Dyon[0] are dynamically typed, which isn't so attractive to me.
More promising are Gluon and Mun, both of which are statically typed. Of these two, Gluon has a somewhat alien syntax if you're coming from Rust (it notes it's inspired by Lua, OCaml and Haskell) so Mun is probably a better choice...but it seems very early, and the website notes as much (to serve the needs of a Rust-scripting-language I'd want seamless interop between it and Rust, which isn't quite there).
So I don't think there's anything in this space right now, but there are some promising options.
If you're wiling to go a little further afield, I'm kind interested in assemblyscript[3] - it's 'just' another WASM-based language so it's not a huge leap of imagination to believe there could be
Read the rest
tooling to enable the seamless Rust interop. Just a matter of effort!
[0] https://github.com/PistonDevelopers/dyon
[1] https://github.com/gluon-lang/gluon
[2] https://github.com/mun-lang/mun
[3] https://www.assemblyscript.org/
I tried out Nix recently, with the intention of using it to get declarative management of my user account.
I discovered too late that Nix basically has no support for this.
While NixOS has some very nice features for declarative setup, user environment management boils down to terminal commands for "install package X, remove package Y".
The mentioned home-manager seems more of an awkward hack than a good solution in my view. It builds up a parallel package repository that you have to use besides the actual packages, and requires a lot of additional work if you want to customize something.
In my understanding (possibly incorrent?) it is also not actually immutable, but just dumps down files into $HOME, losing the most interesting aspect of Nix.
In the end I ditched it and stuck to my Ansible setup.
Nix is a great approach, and definitely w
Read the rest
orth a look, if you can stomach the other downsides (see below). But right now I would only recommend it for deterministic server builds or isolated dev environments, not for managing you main setup.
* Problems:
- There is plenty of documentation, but it is often incoherent, messy, missing important explanations, and it is generally very awkward to get a good insight and understanding of how all the parts fit together.
- The language... it is full of confusing oddities; clearly something that has grown peace by piece. Switching to something more coherent like Gluon (also functional, https://github.com/gluon-lang/gluon) would seem like a better approach to me.
- Packages: The quality can be very hit and miss. I discovered several that are written poorly. Plenty are also outdated/unmaintained. But: considering the niche nature of Nix, the amount of packages is actually quite impressive.
This is written in Rust, and the reloading mechanism looks like it aims to hot reload Rust libraries. So this could be used as a development workbench to glue together Rust libraries, think Python gluing a bunch of C++ libs together.
Language wise, it looks like it is in the Swift/Julia/Haxe space but with first class support for Rust. This looks interesting, I wish them luck and would love to use this in the future.
Two other languages to check out are
Dyon, https://github.com/PistonDevelopers/dyon
Gluon, https://github.com/gluon-lang/gluon
In Mun Programming LanguageI'm building a YARV compatible bytecode VM using the standard CRuby code to do the lexing, parsing, and compilation. It's the first time I've built anything more complex than a toy interpreter.
Interesting material here:
Gluon https://github.com/gluon-lang/gluon/
https://pliniker.github.io/post/dispatchers/
https://play.rust-lang.org/?gist=8fc08d2c9980aaee363d2f7842e...
Finally, there's also Dora https://github.com/dinfuehr/dora by Dominik Inführ, who is interning with the V8 team in Münich. Dora is incrementally compiled, though, rather than being a bytecode VM.
https://dinfuehr.github.io/blog/dora-implementing-a-jit-comp...
In Build a VM step by step with RustGluon – A static, type-inferred and embeddable language written in Rust
203 points · Open discussionGluon is also a language built on Rust: https://github.com/gluon-lang/gluon
In Gluon – A configurable and small virtual machine which runs Erlang BEAM bytecodeTotally agree. The thing with LuaJIT or more appropriately stock Lua is that the VM is small enough to include in your project directly. If Vec and String were exposed to Lua first class construct, we would be a long way there.
The two most mature, well-designed languages in the Rust world are Gluon [1] and Dyon [2]
I believe there is a _great_ opportunity for something like Terra [3] but woven into Rust. Perhaps with the same type of compiler plugin that enabled HolyJIT [4]
The grail is having both a GC and an ownership based gc-free lower level all in the same language. Start dynamic, harden to static and sprinkle in properties.
As a side note, I have been thinking about how to bolt ownership onto a dynamic language and then I learned about Snowflake [5]. I think it would be totally doable to bolt ownership onto Java using annotations
Read the rest
and AoT subsets of a program, completely escaping the garbage collector. This would be like Terra++
[1] https://github.com/gluon-lang/gluon
[2] https://github.com/PistonDevelopers/dyon
[3] http://terralang.org/
[4] https://github.com/nbp/holyjit
[5] https://www.microsoft.com/en-us/research/publication/project...
There's also the Gluon language [1] and, as someone below mentioned, this [2] enterprise mobile thing.
[1]: https://github.com/gluon-lang/gluon
[2]: http://gluonhq.com/
In Gluon – Deep Learning API from AWS and MicrosoftGluon programming language – alternative to Lua, functional, statically-typed
2 points · Open discussion