4 ms·

Gleam's New Interactive Language Tour

94 points by crowdhailer 3y ago

lpil 3y ago
There is a blog post with a description of how it is implemented here: https://gleam.run/news/gleams-new-interactive-language-tour/ https://gleam.run/news/gleams-new-interactive-language-tour/
- dang 3y ago
  Thanks! We changed the URL to that above.
lf-non 3y ago
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.
- transfire 3y ago
  I think it is intentional, which personally I like.
  - lf-non 3y ago
    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.
    - brabel 3y ago
      > 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).
      - lf-non 3y ago
        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.
- lpil 3y ago
  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.
  - lf-non 3y ago
    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 https://kotlinlang.org/docs/ksp-overview.html
spinningslate 3y ago
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 https://exercism.org/tracks/gleam
- AlchemistCamp 3y ago
  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.
  - lpil 3y ago
    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.
    - AlchemistCamp 3y ago
      Oh, strange that github had a date of September 14th, 2016 on this one: https://github.com/gleam-lang/gleam/issues/2 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.
shirogane86x 3y ago
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.
- lawn 3y ago
  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.
  - shirogane86x 3y ago
    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
    - lawn 3y ago
      This is something I read in the Discord channel. And I have the exact same thoughts as you have.
lioeters 3y ago
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/ https://kazzkiq.github.io/CodeFlask/
- lpil 3y ago
  Thank you, I'll fix that link now.
cassepipe 3y ago
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/ https://tour.gleam.run/functions/function-captures/
- giraffe_lady 3y ago
  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.
manveru 3y ago
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.

94 points by crowdhailer 3y ago

lpil 3y ago

There is a blog post with a description of how it is implemented here: https://gleam.run/news/gleams-new-interactive-language-tour/ https://gleam.run/news/gleams-new-interactive-language-tour/

dang 3y ago
Thanks! We changed the URL to that above.

lf-non 3y ago

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.

transfire 3y ago
I think it is intentional, which personally I like.
- lf-non 3y ago
  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.
  - brabel 3y ago
    > 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).
    - lf-non 3y ago
      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.
lpil 3y ago
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.
- lf-non 3y ago
  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 https://kotlinlang.org/docs/ksp-overview.html

spinningslate 3y ago

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 https://exercism.org/tracks/gleam

AlchemistCamp 3y ago
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.
- lpil 3y ago
  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.
  - AlchemistCamp 3y ago
    Oh, strange that github had a date of September 14th, 2016 on this one: https://github.com/gleam-lang/gleam/issues/2 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.

shirogane86x 3y ago

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.

lawn 3y ago
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.
- shirogane86x 3y ago
  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
  - lawn 3y ago
    This is something I read in the Discord channel. And I have the exact same thoughts as you have.

lioeters 3y ago

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/ https://kazzkiq.github.io/CodeFlask/

lpil 3y ago
Thank you, I'll fix that link now.

cassepipe 3y ago

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/ https://tour.gleam.run/functions/function-captures/

giraffe_lady 3y ago
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.

manveru 3y ago

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.