
Gluon – A static, type-inferred and embeddable language written in Rust - Lapz
https://github.com/gluon-lang/gluon
======
Xeoncross
Looks really interesting. The readme actually got me started with lots of good
examples.

Side note though: I won't ever use a symbols-instead-of-words language unless
I have to.

    
    
        let { (*>), (<*), wrap } = import! std.applicative
    

This is not my idea of good language syntax. I like jr developers, non-X
language developers, hardware guys, and even graphic designers to be able to
understand my code.

Consider simple string concatenation. This is what it looks like in
Objective-C:

    
    
        NSString *one = @"Hello";
        NSString *two = @"World";
        NSString *three = [[one stringByAppendingString:" "] stringByAppendingString:two]
    

Total fail for something so simple.

~~~
mikekchar
I'm dyslexic. I haven't looked into it in detail, but someone once told me
that dyslexia is some kind of problem processing things that are
pronounceable. When I was learning Japanese I was amazed how easy it was to
read kanji (the Chinese) characters. Apparently processing things that are
inherently symbolic (even if you can pronounce them) is done differently. It
was like someone lifted a veil. Even now I prefer reading Japanese to English.
I suspect if I learned Chinese I would enjoy it even more.

The same goes for languages with symbols. For me, they are an order of
magnitude more readable. Obviously people with dyslexia is a very narrow group
to design a language around, but I suspect that there are others who also find
it easier to think about symbols than words. That's why people design
languages in this way (and as someone else pointed out, probably why math has
such a large number of symbols).

There are things that are easy to learn and things that are easy to use. Often
there isn't as much overlap as you might expect between the two group. For
something like programming languages, I'll take easy to use over easy to learn
any day. Having said that, I am absolutely sure there are people who prefer
having a big block of prose in their code. I see that kind of code frequently
as well, so which one is easier to use almost certainly depends on the person.

~~~
Xeoncross
Great insight, thank you for sharing. I'll keep this in mind. Maybe in some
cases a middle ground could be finding a way to use less symbols instead of
more. Verbosity isn't always desired with symbol or prose.

------
jdreaver
Gluon recently added implicit arguments with the latest release (see
[http://marwes.github.io/2018/06/19/gluon-0.8.html](http://marwes.github.io/2018/06/19/gluon-0.8.html)).
In spirit it is like modular implicits
([https://arxiv.org/pdf/1512.01895.pdf](https://arxiv.org/pdf/1512.01895.pdf)).
This is really exciting because modular implicits represent a pragmatic
balance between the flexibility of ML modules and the convenient overloading
of type classes.

Another cool feature of Gluon is modules are basically just records. This is a
strict improvement over ML modules in my opinion. (See [http://gluon-
lang.org/book/modules.html](http://gluon-lang.org/book/modules.html))

Congrats on the recent release!

~~~
MrBuddyCasino
> implicit arguments

Because it worked so well in Scala?

~~~
pas
What's your opinion of Odersky's scala3 implicit plan?

~~~
MrBuddyCasino
I'm not very familiar with Scala3, but as far as I'm aware implicits are still
a core part of the language?

Let me put it like this: I recently applied to two high-profile startups with
experienced technical leadership, and they both explicitly asked me if I was a
Scala fan. They weren't and made bad experience in the past regarding
productivity due to complexity, tooling and developer onboarding, which
unfortunately matches my experience. There is some good stuff for certain
niches (Akka, Spark etc.), but otherwise I feel like Kotlin is winning.

------
eximius
:sigh: I hate function call syntax without parens. It makes code _much_ more
difficult to read and, if it supports first class functions, passing around no
arg functions is harder than it should be.

~~~
PeCaN
I hate function call syntax with parens. It makes code _much_ more difficult
to read and, if it supports calling functions, calling functions with args is
harder than it should be.

~~~
kjeetgill
While I agree the parent could have elaborated more, would you like to as
well?

I've never worked in a language without parents for function calls so I share
their confusion reading Haskell or Ruby code at a glance.

I don't think a language needs to bend for non-users but being intelligible
without knowing the language _can_ I be nice.

As an outsider, the examples:

A(B(C)) A(B,C) A(B)(C)

Could all be valid Python but still communicate a little bit about A B and C.
Without parents they'd all look like "A B C". I'm sure it's more obvious if
you know those languages.

~~~
flomble
The interesting thing is that in Haskell, the equivalents of Python's `A(B,C)`
and `A(B)(C)` are identical: `a b c`. This is because of currying: you're
allowed to supply one argument to a function at a time, and you get back a
function that takes one fewer argument. So if `add(x,y) = x + y`, then
`add(5)` is a function (let's call it add5) so that `add5(y) = 5 + y`, or in
Haskelly notation, if `add x y = x + y` then `(add 5) y = 5 + y`. If you write
`add (x,y)` in Haskell, then it means a function that takes a single tuple
`(x,y)` as an argument.

A(B(C)) would be `a (b c)` or `a $ b c` or `(a . b) c`. The first is the most
vanilla way, the second is convenience (basically "evaluate everything after $
first, then plug it in") and the third uses the function composition operator
`.`.

~~~
chriswarbo
Nice summary. I would just like to add that `$` and `.` in Haskell aren't part
of the language syntax, they're just normal functions/operators, which some
people like to use.

We can define `$` ("apply a function to an argument") as:

    
    
        f $ x = f x
    

We can define `.` ("compose two functions") as (where `\x -> ...` is an
anonymous function):

    
    
        f . g = \x -> f (g x)
    

Equivalents in, say, Javascript would be:

    
    
        function dollar(f, x) { return f(x); }
    
        function dot(f, g) { return function(x) { return f(g(x)); }
    

People mostly use `$` because of its precedence rules, which cause everything
to its left to be treated as its first argument, and everything to the right
as its second, i.e. we can use it to remove grouping parentheses like:

    
    
        (any complicated thing) (another complicated thing)
    

with:

    
    
        any complicated thing $ another complicated thing
    

It's also useful for partially applying, e.g. `map ($ x) fs` will apply each
function in the list `fs` to the argument `x`.

------
kccqzy
Looks like a great language that's a nice mix of OCaml and Haskell!

What's the interop story? If I am embedding this language inside my app, I
reasonably want to make data structures in my app to be available through this
language. How would that work?

~~~
cjcole
The support for interop looks strong:

[http://gluon-lang.org/book/embedding-api.html](http://gluon-
lang.org/book/embedding-api.html)

[http://gluon-lang.org/book/marshalling-types.html](http://gluon-
lang.org/book/marshalling-types.html)

There are some marshalling traits that you can implement or derive.

------
losvedir
Now _this_ is what every language landing page should be like. I love the
nontrivial code snippet solving a fun little problem front and center.

------
wtetzner
Wow, I've been wanting something just like this for Rust. And it has row
polymorphism!

~~~
sitkack
Arguably, this is Rust.

~~~
wtetzner
Not sure what you're trying to say here. Gluon is much more like OCaml than it
is like Rust. And Rust _doesn't_ have row polymorphism.

~~~
sitkack
By being hosted in Rust, Gluon has access to the Rust ecosystem. So one could
use Gluon and still be in the family depending how seamless the interop story
is.

~~~
wtetzner
I think we are in agreement. I was saying that I was looking for an embedded
programming language like this for Rust, and now I've found it.

------
lasagnaphil
It would be great if someone made a UI framework with Rust and made this the
scripting language (making the experience Elm-like, but with a better type
system and without web technologies)

------
rixed
Too bad it has a different heap per thread. If I want to extend a C (or rust)
posix-multithreaded program, it means I can't easily use gluon to access the
state of my program (which requires accessing posix-multithreaded protected
variables in the normal heap). Same thing that makes Lua useless to simply
extend actual, pre existing C programs.

Anyway, I'm still happy to see that more modern languages than algol have
gained enough influence than the choice of type system, type inference and non
C like syntax is not frowned upon anymore.

------
knocte
Looks like F# but has a big design mistake in my opinion (which F# doesn't):
the symbol '=' in a functional programming should be tied to comparison, not
assignment. (The approach taken here is using "==" for comparison, which is
less ugly than JavaScript's "===" but still ugly.)

------
childintime
As the `in` keyword seems key to understanding the language, could someone
elaborate on it?

It isn't obvious after reading the intro on [http://gluon-
lang.org/book/syntax-and-semantics.html](http://gluon-lang.org/book/syntax-
and-semantics.html).

~~~
cobbal
Looks like a variant on ml-like `let`.

    
    
        let <variable> = <expression 0> in <expression 1>
    

will bind the value of expression 0 to variable in expression 1.

------
f311a
So many new languages lately, does anyone is risky enough and using such
languages in production?

------
tadfisher
This looks very similar to Nix, with improvements such as real typing and lack
of semicolons. That's a very good thing.

Any plans for a purely-functional variant (i.e. a single expression per
evaluation)?

~~~
djur
According to the manual, Gluon doesn't have statements, but it elides "in":

    
    
       let n = 1
       let m = 2
       let nm = n + m
       nm
    

is sugar for

    
    
       let n = 1 in
         let m = 2 in
           let nm = n + m in
             nm

------
badsavage
I feel like every day a new programming language presented on HN. Maybe you
didn't realize, but we know CL/scheme/clojure already and have no turning
back..

