Not to my taste but if you like it, good luck to ya 
Funnily enough Gleam doesn’t have the syntax I prefer, that would be the ML syntax! I’d be very happy if Gleam was closer to Elm or OCaml. I don’t think my personal preferences align overly well with the language goals here.
I can think of 4 ways of writing a function definition in Elixir, does that count? 
Talk about “let it crash” ! 
2 Likes
Haha, not quite. I was thinking something more fundamental - two distinct styles that would visibly impact the whole codebase.
The funny thing is, if syntax is as important as many people think it is, having two styles just doubles your potential userbase, right? 
I personally can’t get on with whitespace dependent syntax (as well as the opposite end, lots of braces/brackets/semi-colons etc). I wonder if I have a form of dyslexia or something 
With that said I will butt out now - I was just curious and wondered whether it was something you might want to consider. Good luck with Gleam - it’s nice to see a language made in Britain 
2 Likes
Surprisingly OCaml isn’t whitespace dependant! Somehow they’ve made it that lightweight without paying any attention to whitespace at all. Quite impressive, though there are some awkward bits to it.
2 Likes
I really liked your talk Louis. Your calm voice and british english made the already very interesting and informative talk even better. 
Thank you for it.
4 Likes
Thank you, I’m glad you enjoyed it!
1 Like
I was curious if you considered making Gleam an OCaml compiler outputting Erlang (or Elixir) like jsoo or Bucklescript? At this point with ReasonML there would then be 2 syntaxes… one for ML fans and one more C-like.
Also do you know an example repo of an Elixir app showing interop with Gleam? I was thinking about trying it out but I think Gleam structs == Erlang records and not sure how it can handle Elixir structs (i.e. Maps) without runtime translation which are ubiquitous in my app.
Also it would be cool if anyone’s written external bindings to Elixir standard library or critical Elixir libs (like Ecto) or if it could somehow consume @spec obviating the need for external?? 
This was a previous project of mine, but due to lack of knowledge of the OCaml compiler I didn’t make much progress. In the end I stopped as I didn’t think I would have a result I was happy with, especially since I’m not completely happy with the tradeoffs that Bucklescript had to make.
A project that may be interesting to you is Purerl, an Erlang backend for the Purescript compiler. GitHub - purerl/purescript: A small strongly typed language that compiles to Erlang (not JavaScript)
Here is one, though not by me GitHub - wojtekmach/hello_beam: Elixir, Erlang, Gleam & LFE code all in the same project! 
Gleam v0.5 generates Erlang record definitions, you could metaprogram conversion functions in Elixir using the Record module. Gleam will likely support some kind of coercion later though it has not yet been designed.
This isn’t possible as Elixir’s stdlib is not entirely well typed, and @spec are not reliable or precise enough to give us the information we need. They could serve as guidelines though.
I would instead suggest that useful functions and modules are ported to Gleam as libraries
3 Likes
Thanks @lpil for the detailed response all makes sense.
I was afraid @spec wouldn’t be enough but was just hoping we could avoid writing huge external specs. Rewriting Ecto in gleam sounds like fun but wow that would be a huge project! 
I didn’t realize maps (Elixir structs) weren’t designed yet… will be great when some coercion exists since they are used so heavily. Until then just to rely on excellent typed_struct library and dialyzer.
Thanks again for sharing your work on Gleam!
Yep, OCaml is entirely whitespace independent! There are a couple oddities, like the fact that top-level let’s don’t need the in, but honestly those could be very fixed by just returning the module at the end based on the functions:
let add a b = a + b in
let blah () = print_string "blah\n"
module (* This is essentially the 'public' list *)
| ~add
| ~blah
Or could do it inline like
module
| add = fun a b -> a + b
| blah = fun () -> print_string "blah\n"
Or a whole variety of other things. OCaml is definitely organically grown, but it’s choices mean it’s parser is super efficient (no backtracking needed), the syntax choices are unambiguous, fully whitespace independent, etc… etc…
Well if you have questions… ^.^
But yeah, I’m not happy with what bucklescript did either, it didn’t have to at all.
Also, they were asking about having gleam able to output ocaml, not about consuming ocaml or anything of the sort. There are a LOT of languages that can output ocaml, it’s very easy to output to.
You can use elixir structs just like maps, as that is all they are, just be sure to have it fully filled out is all. ^.^
Oh! Thank you I misread that.
We certainly could do that. One of my long term desires is to have Gleam be able to compile to a fast native binary. OCaml might be a good option, I was previously thinking about using Chez Scheme or the new Lumen project.
1 Like
Just an opinion from mainly an Elixir and JavaScript programmer that tinkers in ReasonML and OCaml… for me i’m actually very attracted to Gleam because it’s a nice mix of that familiar syntax (Elm/Haskel doesn’t quite click for me) and they ML type system. (personally i’d prefer more Reason/Ocaml syntax but the current format makes sense to attract a larger crowd).
The Elixir syntax did draw me in at first but now after I look at Erlang I really like the simplicity of it. Elixir and it’s macro DSLs can make it hard to reason what’s happening… throw in poor docs w/o return types and you have a lot of wasted time.
Elixir also has a tendency to make very complicated libraries like Ecto. I would really just prefer sometime like Postgrex with a little sugar to reduce boilerplate and a more re-useable schema library to validate data. There’s SO much I don’t use. Yet Erlang seems to have a lot of SQL clients that don’t have longevity. I’m hoping the gleam community will embrace the more simplistic library approach but have the documentation and quality that the Elixir community provides.
Above all else I just can’t wait to maintain a codebase in Gleam so that I can make changes quickly with confidence again!
4 Likes
Thank you for the kind words, I think we have similar hopes for Gleam!
2 Likes
Can Gleam handle mutually recursive functoons already? Or is that still a limitation?
Good question! There’s no technical reason why mutually recursive functions cannot be added but the work has not been done yet. There’s a issue for tracking it here: https://github.com/gleam-lang/gleam/issues/346
Currently the same functionality can be replicated using an enum that tracks what state a recursive function is in so it doesn’t make the language more expressive, so it’s lower on my priority list than other features such as type safe OTP bindings.
In other news, Gleam v0.5 has been released!
As per usual I’ve written a little blog post detailing the major changes from the previous version, which can be found here -> https://lpil.uk/blog/gleam-v0.5-released/
2 Likes
Or just use a Y combinator. ^.^
Woot! The syntax is looking more like Rust all the time, lol.
You’d have to use a Z combinator in Gleam as we don’t have lazy evaluation. It would be very cool to see someone do this!
Gotta give the people what they want 
Don’t need lazy evaluation for Y combinator’s, you just need first class functions and that’s all.
Hmm, let me update and experiment… And got 0.5.0 via asdf…
Uhh, an issue please? ^.^;
➜ gleam new tester
* creating tester/LICENSE
* creating tester/.gitignore
* creating tester/README.md
* creating tester/gleam.toml
* creating tester/test/tester_test.gleam
* creating tester/src/tester.gleam
* creating tester/.github/workflows/test.yml
* creating tester/rebar.config
* creating tester/src/tester.app.src
Your Gleam project "tester" has been successfully created.
The rebar3 program can be used to compile and test it.
cd tester
rebar3 eunit
➜ cd tester
➜ rebar3 eunit
===> Fetching rebar_gleam ({pkg,<<"rebar_gleam">>,<<"0.1.0">>})
===> Downloaded package, caching at /home/<my_user>/.cache/rebar3/hex/hexpm/packages/rebar_gleam-0.1.0.tar
===> Compiling rebar_gleam
===> Verifying dependencies...
===> Package not found in any repo: gleam_stdlib-v0.5.0.
Hmm, tried a few different commands to no avail? ^.^;
Edit: For note, the OCaml basic Y-Combinator is just:
let fix f g = (fun x a -> f (x x) a) (fun x a -> f (x x) a) g
I’m definitely not complaining, lol. I’d prefer OCaml, but Rust is clean and clear in a different way, mostly. ^.^
Classic move, I’ve made a typo during the release process! I’ll fix this up right away.
