I've been running through the gleam course on Exercism[0] and enjoying it so far. I like Erlang and the BEAM's mature, cohesive, rock-solid support for concurrency and distribution. I also like statically typed functional languages. Gleam fits in the sweet spot intersection of both.

It's still early days in its evolution, and it remains to be seen if it manages to reach self-sustaining popularity like Elixir has. I hope it does. A statically typed, functional language on the BEAM with a healthy ecosystem is pretty much my dream platform.

[0]: https://exercism.org/tracks/gleam

I did most of that course and enjoyed it too. With regard to BEAM, OTP etc, do you have any Gleam-specific reading recommendations? The bit I’m unsure about now is how to structure and deploy a semi-serious server-side app that has some state to manage.

It’s been ongoing since at least 2016, and I don’t think it will ever reach Elixir’s level of use. I’m glad it exists and people have more options, but don’t use it.

It doesn’t have macros, which are one of Elixir’s most important features. Even if you rarely write macros yourself in application code, the most popular libraries in the ecosystem (Ecto, Phoenix, Absinthe, etc) make heavy use of them. The popular DSLs they provide wouldn’t otherwise be possible.

Gleam is a different language, so just because macros are the most important feature in Elixir doesn't mean that their absence in Gleam will be a problem. There's a lot to like about Elixir as a language, but the BEAM is great in its own right and a static language on the BEAM can stand on its own, not just an "Elixir but without macros".

Macros aren’t the most important feature of Elixir. They’re possibly the most important feature that gives me a reason to choose it over Erlang. I think the BEAM is the most important thing about either language.

I think Gleam will far exceed Elixir's level of use. Avoiding complexity like macros is one of the reasons I think this. (it's similar to the go philosophy of simplicity, but gleam more does it more consistently than go).

But I guess only time will tell.

Gleam started in 2018 but has only been worked on full time for 1 year. Compared to Elixir it's very young.

I think it's a bit strange to bring up macros here. There are lots of languages that don't have Elixir's macro system, and they're doing fine.

Oh, strange that github had a date of September 14th, 2016 on this one: https://github.com/gleam-lang/gleam/issues/2

I was just going by that.

Re: macros, I brought them up because their absence was a reason I wasn’t drawn to the language when I checked it out a few years ago. I really do think macros are a big deal and all the other newer languages I use, such as Rust, have them or some kind of meta-programming features.

Best not confuse your personal preference for macros with a requirement for the global programming population. Most languages do not use macros, metaprogramming is comparatively niche and doesn’t lend itself well to the style of programming people are attracted to Gleam for.

> Best not confuse your personal preference for macros with a requirement for the global programming population.

I didn't. I said don't use Gleam and then said why.

I care about having ergonomic DSLs and a RAD web framework that's maximally productive for individuals and small teams. Others care about different goals. As I said above, I'm also glad Gleam exists and people have more options.

You actually said that Gleam won't reach Elixir's levels of success.

I've been trying Gleam of and on for a few years and different tasks. When it works it's really neat, but I find myself constantly having to write your code in Erlang which kind of defeats the joy of using it.

The biggest missing feature for me though is the lack of a receive syntax. Sending and receiving messages should be a first class citizen on the BEAM. There is a very limited workaround in the standard library, but I guess the requirement for type safety means we'll have to wait forever for anything that can actually do things like listen to PIDs or the inbox without Erlang or if the box.

I'm still hopeful this will be tackled, as I really can't stand the concurrency primitives of most other statically typed languages and Gleam has the most promise to fill that niche.

Gleam looks really nice but unfortunately the complete lack of metaprogramming of any kind makes it a non-starter for me personally. I still hope it succeeds though, the BEAM is a really nice platform and maybe having a statically typed language can help increase adoption.

Afaik they plan for some sort of metaprogramming, but they don't know how it will look like and it hasn't been a priority yet.

I looked around to see if that was the case and couldn't find any indication of it, but if it's true I might just try it out again in the future (however distant that future may be) because apart from the lack of metaprogramming I really like everything else about it

This is something I read in the Discord channel.

And I have the exact same thoughts as you have.

I love the recent trend of interactive code "playgrounds", largely thanks to WASM enabling the compilation of language runtimes/compilers to run on the web. The article section "How does it work?" goes into fun details, like how to run a dynamically generated ES Module script, and running it in a web worker.

By the way, the link to the CodeFlask library is broken (with extra ".js" at the end). The correct link is: https://kazzkiq.github.io/CodeFlask/

Thank you, I'll fix that link now.

I don't know if that kind of syntax used for function captures exists in other languages but I really like it, it's really intuitive.

Here is the example : https://tour.gleam.run/functions/function-captures/

I think it's not common because primarily functional languages usually have dedicated syntax for partial application or currying, or just do it automatically. Languages not built around functional programming usually seem to consider this sort of thing suspiciously clever, so not having syntax for it is an intentional choice.

ReScript just recently removed auto currying (inherited from ocaml) and instead added a very similar syntax for partial application. It just uses ... instead of _ for the arguments.

Gleam looks very interesting. However I don't see any support for annotations (metadata based code generation) or reflection. I am curious if these are things that just haven't been implemented yet or it is an explicit goal to avoid such features to keep the language simple.

We're interested in some form of metaprogramming or code generation in future, but we do not yet have a design yet that we're happy enough with to make the official one. It's important to us to keep the language easy to understand and compilation very fast.

It's very much an area of R&D, and we hope that folks share any ideas they may have. For example, I'm unfamiliar with Kotlin's system and it would be useful if folks could share any vision for how it could be applied to Gleam.

That's great to know. Will be looking forward to what you come up with.

Kotlin recommend ksp [1] but underlying platform's reflection is also available. I am not sure it (or something similar) will be a great fit for gleam but have been planning to explore it deeper for some time.

[1] https://kotlinlang.org/docs/ksp-overview.html

I think it is intentional, which personally I like.

Hmm ... to each their own I guess. But while developing backends with Kotlin I attempted to ditch all annotation/reflection/code-generation based libraries for a while, opting for functional libraries like ktor, exposed etc. But the end result always ended up being a lot more verbose and repetitive.

I now feel that some form of behind-the-scene code-generation or reflection support is generally good to have so that the bulk of the application stays focussed on application logic instead of various dto conversions, mappings, transformations etc. I don't shy away from Quarkus, MapStruct etc. now a days and I think my code is easier to follow because of what they enable.

Typescript is a bit of an exception here because the type system is quite powerful with various type transformation capabilities but Gleam's type system also appears to be quite minimal.

> opting for functional libraries like ktor, exposed etc.

KTor kind of relies on Kotlin serialization which uses code generation behind the scenes (which is why you need to apply a plugin on your build system).

Yeah its there by default but then there is nobody forcing the consumer to use it.

So in theory we could get the raw body, and then use something like Jackson's ObjectMapper.valueToTree to get an untyped object hierarchy and then convert that to properly typed domain objects through some manually authored utility methods. Nobody does that though because it is super convenient to have a library take care of that boilerplate for you with codegen or reflection which was basically the point of my original comment.