I'm still surprised the "use" syntax survived the 0.x release "experimentation" phase.
It's more confusing than explicit "I can read and tell what this is doing by matching the braces" callbacks, _and_ it's more confusing (and less expressive) than full-on do-notation (or F#-like "computation expressions").
Instead, it's the worst possible middle ground: it's a third, different mental model that is unfamiliar in an already-unfamiliar language amid other "rough-edges" choices (like not having if-then statements -- even though you can pattern-match on `case true...case false`, it's still another rock in the shoe), but it doesn't offer improved clarity (since you have to keep "what will the real code look like when this is desugared" in mind constantly when figuring out which variables to `use` and which to just assign, and which parameters should stay in the function call and which should get "magically" floated outside the parens, and so on...), nor does it offer improved power/flexibility (in the way that do-notation does, where you can generalize expressing any given nested/monadic operations as though they were not nested).
I love ML-family languages, and I find the BEAM VM intriguing. I want Gleam to be great, but it has just enough friction (in the form of unique-but-not-clearer-or-more-powerful language decisions) and just enough limitation (in the form of a very limited standard library) that I think it's currently just "okay".
> it's more confusing (and less expressive) than full-on do-notation (or F#-like "computation expressions").
It's strictly more expressive than do-notation. Anything that Haskell's `do` can do Gleam's `use` can do, but not everything that Gleam's `use` can do Haskell's `do` can do.
I don't think the clarity argument holds true, I think rather this is about what you're familiar with rather than an actual property of the syntax. Both are rather opaque.
Given there's a few languages with `use` now I think that familiarity problem will lessen too.
I've been keeping an eye on Gleam since I saw a talk by it's creator at Code Mesh London 2019, linked below.
It was one of my favourite talks of the conference, and of all the efforts to marry types and the BEAM it struck me as much more promising than other similar efforts.
I've run Gleam compiled for the Erlang target using the elixir-desktop project as a "native" Android app. Meaning that the Erlang runtime is packaged with Elixir and the Phoenix framework into an APK. The app runs your code in Phoenix and opens a LiveView frontend that serves as the app's UI.
Right now I'm working on a streaming music client in Gleam that runs as a progressive web app in browsers, desktops, and mobile. It looks just as native as the elixir-desktop app and has integration to the OS media notifications. This is using the JavaScript target.
If you are able to make mobile apps with JavaScript in other ways (Cordova?), then you can take Gleam's JS output and use that in such a system.
It's more confusing than explicit "I can read and tell what this is doing by matching the braces" callbacks, _and_ it's more confusing (and less expressive) than full-on do-notation (or F#-like "computation expressions").
Instead, it's the worst possible middle ground: it's a third, different mental model that is unfamiliar in an already-unfamiliar language amid other "rough-edges" choices (like not having if-then statements -- even though you can pattern-match on `case true...case false`, it's still another rock in the shoe), but it doesn't offer improved clarity (since you have to keep "what will the real code look like when this is desugared" in mind constantly when figuring out which variables to `use` and which to just assign, and which parameters should stay in the function call and which should get "magically" floated outside the parens, and so on...), nor does it offer improved power/flexibility (in the way that do-notation does, where you can generalize expressing any given nested/monadic operations as though they were not nested).
I love ML-family languages, and I find the BEAM VM intriguing. I want Gleam to be great, but it has just enough friction (in the form of unique-but-not-clearer-or-more-powerful language decisions) and just enough limitation (in the form of a very limited standard library) that I think it's currently just "okay".