
Gluon: A static, type inferred and embeddable language written in Rust - jswny
https://github.com/Marwes/gluon
======
cfallin
This is an impressive effort!

It seems that Gluon has taken inspiration from Haskell right down to the
monadic solution to mutable state:
[https://github.com/Marwes/gluon/blob/master/std/state.glu](https://github.com/Marwes/gluon/blob/master/std/state.glu)

I wasn't able to find any 'cell' type or mutable records like in OCaml, so
this does seem to be a pure language -- is that right? I wonder how that works
in practice for small embedded scripts/logic -- my intuition is that the
discipline enforced by monadic types and purity is really great at large scale
but can be frustrating when you just want to hack something together.

Anyway, it would be interesting to see typical use-cases for Gluon!

~~~
Marwes
Author here, thanks for the kind words :D. The language used to be completely
pure and the state type is a remnant from that time (as well as to show and
test that higher kinded types such as monads works). I started to allow impure
functions a while back though for a few reasons.

* It is intended to easily work with a host language which are likely to be impure. Any functions and types which that host language extend gluon with would also have to be pure which is likely to present awkward or impossible APIs. I also cannot check that the functions are pure so it would be really easy for the host language to make a mistake and accidentally pass in an impure function.

* Pure languages require, at least as I understand, more optimization to perform well and I don't expect to spend much time on an optimizer for the foreseeable future.

* An extension language is more likely to be used by less experienced developers and regardless of my personal preferences, impure languages are what most people are used it.

That being said, I do encourage pure programming as the main paradigm inside
the language. The only mutable types which currently exists are the `Ref` type
(atomic cell taken from Clojure) and a channel type (`Sender`/`Receiver`)
which are used to send values between threads. I might add mutable records at
some point if I feel they make sense but currently I am leaning towards
keeping them out.

(From my own forays into embedding Lua in a C++ game I found it troublesome to
mix state in Lua and C++. This makes me believe (though I don't have any good
example of this as of yet) that it is a better pattern to keep all state in
the host language and keep the embedded language as pure as possible, keeping
mutation to only be "update host state".)

This turned out to be rather lengthy which I didn't expect. To finish it of I
would love to find some way to keep the language completely pure if the
problems mentioned above could be fixed or worked around. In embedded
languages there is already a notion of limiting what the embedded language can
do which could map really well to monads (ie in a game you might have Draw
monad, Update monad, Sound monad, etc).

~~~
cfallin
Ah hah -- I had missed your `Ref` and channel types. Thanks for the detailed
explanation!

------
sitkack
This is VERY well thought out,
[https://github.com/Marwes/gluon/blob/master/TUTORIAL.md#embe...](https://github.com/Marwes/gluon/blob/master/TUTORIAL.md#embedding-
api)

~~~
sanderjd
Agreed, it's a very good overview of the language. In case the author is here,
I think there is some confusion in the section about indenting:

> When a token starts on the same line as a token on an earlier line, gluon
> implicitly adds inserts a block expression

I think this means that lines where tokens start on the same _column_ are part
of an implicitly inserted block. The comment on the code snippet is similarly
confusing (and seems to have missed a refactor from `id` to `add1`).

Hope that is helpful! Looks like a really nice language.

~~~
Marwes
You are quite right! I uploaded a new version of the tutorial which should
clarify the indentation behaviour (and fix a few typos).

------
cm3
Another project from the author which is now abandoned, but might have
provided the spark for gluon: [https://github.com/Marwes/haskell-
compiler](https://github.com/Marwes/haskell-compiler)

It's a partial Haskell compiler written in Rust.

------
kenOfYugen
I really like how the parser is implemented [1]. Very straightforward and
readable even to a Rust amateur like I am.

Are there any more open source languages of similar nature, using Rust?

1\.
[https://github.com/Marwes/gluon/tree/master/parser/src](https://github.com/Marwes/gluon/tree/master/parser/src)

~~~
cjs_2
I know of Dyon [1] as an embbedable scripting language written in Rust.

1)
[https://github.com/PistonDevelopers/dyon](https://github.com/PistonDevelopers/dyon)

~~~
eggy
Dyon is built to work really well as a scripting language for the Piston game
framework written in Rust. I was just looking at it.

I'll need to compare and see if Gluon can be leveraged in any way.

------
majewsky
Is it just me, or do all the new languages this year look the same (like a
hodgepodge of Haskell and Rust)?

~~~
nathancahill
I'm ok with that.

------
sdegutis
How does this interoperate with the Rust program it's embedded in? Is making
functions or values available to it as tedious and verbose as in Lua? Or is
there some way of calling Rust functions or accessing Rust values
automatically from inside embed_lang neé Gluon? I'm assuming it's just as
tedious as in Lua, since otherwise it would need powerful runtime reflection,
which seems like a feature that Rust wouldn't really have or want.

~~~
sitkack
Lua has one of the cleanest no_magic c-apis of any scripting language. LuaJIT
has the cleanest with_magic c-apis of any scripting language. So clean that it
has been copied by PyPy [0], Guile [1] and others.

[0] [http://www.freelists.org/post/luajit/LuaJIT-FFI-Python-
CFFI](http://www.freelists.org/post/luajit/LuaJIT-FFI-Python-CFFI)

[1]
[https://www.gnu.org/software/guile/manual/html_node/Dynamic-...](https://www.gnu.org/software/guile/manual/html_node/Dynamic-
FFI.html)

And yes, Gluon appears have to an extremely low friction interface to Rust.
See my comment above.

~~~
hellofunk
What do you mean by magic here?

~~~
sitkack
Magic in the LuaJIT sense is automatically parsing C declarations and
constructing shims from LuaJIT into native code without having to interact
with a C compiler.

------
cm3
I like the separate heaps ala Erlang and GHC. Hope they're small enough by
default and initial size can be tuned for actively avoiding GC.

------
StevePerkins
Very unfortunate name since "Gluon" is already a commercial entity, sort of a
Java counterpart to Xamarin, and almost certainly has trademarks that would
overlap. Even if they didn't, it's still a pretty uncool move.

[http://gluonhq.com/](http://gluonhq.com/)

Did nobody run a simple Google search before picking the name?

~~~
archgoon
Very unfortunate that a corporate entity chose the name Gluon, as it's already
the name that was assigned fifty years ago to a fundamental particle. At
least, that's what I get when I do a simple google search.

Also, this project

[https://github.com/freifunk-gluon/gluon](https://github.com/freifunk-
gluon/gluon)

predates GluonHQ by several years.

~~~
andrewvijay
But I dont think anyone copyrighted a fundamental particle's name.

~~~
archgoon
I think it's pretty uncool to copyright a word which is a fundamental particle
and prevent people from using it.

~~~
cowsandmilk
Trademarks are fairly narrow in what they restrict other people from using.
While not a "fundamental particle", is it uncool for Intel to have processors
called "Atom", so now no one else can release an "Atom" processor?

~~~
archgoon
Thank you, I shouldn't have reused the incorrect terminology here (it
matters). Thanks for bringing this point up, I completely agree with you,
because there is no chance of consumer confusion between these products, which
is a reasonable standard to adhere to.

Now, if Intel were to go after the Atom Text editor, we would agree that'd be
pretty silly, no? Obviously they wouldn't, because there is no confusion. Now,
if AMD were to start selling ATOMe processors, I'd also agree that Intel would
have a reasonable complaint.

There is no reasonable confusion (for the target markets) between this gluon
project, gluonhq, and the router gluon project (linked to above).

------
cm3
In the sources there's a component called VM, despite Gluon being statically
compiled. Is that more akin to a runtime system or is it a separate VM for the
REPL?

~~~
lifthrasiir
Static checking does not directly imply static compilation.

~~~
cm3
You're right, there's no mention of static _compilation_ , just that it's
statically typed.

------
baq
if the language is statically typed and types are inferred, are there blockers
against including a JIT like LLVM or something simpler to the vm?

~~~
badlogic
The latest LLVM releases have major regressions regarsing JIT performance.
Compilation via LLVM has essentially become to time consuming for use in a
JIT. Bit of a bummer really.

------
ubertaco
Ooh, this is nice! Always a fan of more ML-alikes out there.

