As always Gleam’s lsp actions show just how much useful code generation can be done without the need for any gen ai so long as you have strong types. I continue to be amazed just how much the community cares about the developer experience of the language.
Feels like Gleam is gaining a lot of steam and getting a lot of attention recently. It’s the language that I am most excited about right now. It’s hitting all the right notes.
Yeah this is one of the typical mistakes of guest languages, they start by offering something that the platform language is missing out on, and eventual in the pursue for greater mindstart try to expand elsewhere, however by doing so, they lose the capabilities that made the original target platform special, and eventually become their own thing, if they survive beyond the typical adoption curve.
Most Gleam code is backend agnostic, but code that does something BEAM specific like OTP or Erlang FFI is only available when targeting the BEAM and JS ffi is only available when targeting JS. You can also provide two implementations of a function, one for each backend if you want to target both.
I think it might help to start with a baseline assumption: newer high-ish level languages (or any such language looking to expand mindshare) will inevitably be asked “[how] can I run code written in this language in a browser?”
Yup that's right, you can't use Erlang code on JS runtimes or JS code on Erlang runtimes. Most library code doesn't use either, so it's usable on both.
Elixir is also quite a lovely language even when not using any BEAM specific functionality! I used it a lot for writing regular sequential programs.
It's useful because you can write back-end and front-end code with the same language. Code sharing should work, as long as you don't use runtime-specific features blindly. All basic language features seem to work the same regardless of runtime.
Nah it's just the easiest and most reliable way. Usually anyway; sometimes you have extreme timing or space constraints and can't even use that. On microcontrollers I sometimes have to resort to GPIO debug outputs and I've worked on USB audio drivers where printf isn't an option.
Thinking back on how Python 3 broke nearly all existing Python beginner code because they made print a function instead of a statement feels ironic now.
Sure print being a function has slight benefits in certain cases but the Gleam team also makes very compelling arguments to implement echo as a special keyword.
So what do we learn from that? Maybe don't do breaking changes to your language. Maybe debugging and actually printing should be separate things, one a statement, the other a function? I don't know.
I don’t know enough about Gleam’s implementation to say how applicable this is, but from a more general language design perspective… a keyword isn’t inherently imbued with special capabilities that a function call wouldn’t be. They’re semantically interchangeable for this use case, if the function can access requisite information about the underlying stack.
I’m not sure it’s possible to extrapolate any lessons for Python from this Gleam language feature or the chosen syntax.
Gleam looks like a really nice language that I haven't had a place to use yet. Does anyone have experience using it as a replacement/alternative for TypeScript for (e.g.) CLI tools?
Well, there's nothing stopping the language from having builtin functions and constants in the standard library that are handled specially by the compiler, the same way this echo keyword is. That would've had the added benefit of being backwards compatible (which new keywords are not).
What's a good way to learn Gleam? In college I would learn new languages/libraries/concepts through projects, but these days I have too many projects already.
I don't expect I'll ever use Gleam at work, but the language does look very appealing to me and fun to use.
They're kind of solving different problems. It's a bit like TypeScript vs Elm or PureScript: one is a type system overlaid onto an existing language with its own rich ecosystem and set of idioms, and the other is a new language that targets the same underlying platform but has different idioms and semantics for static analysis.
If you already have lots of Elixir in production, or you enjoy Elixir's highly dynamic approach to solving problems and would like to get some additional safety for free then sticking with Elixir is a no-brainer!
If you'd like a simpler language with tighter static analysis guarantees while still being able to dip into the wider ecosystem then you might prefer Gleam.
Ultimately I think the two languages have very different philosophies and idioms, folks will naturally find themselves preferring one or the other ^.^
I'm not fully qualified but in a nutshell, Gleam doesn't support OTP out of the box. There is a separate package for it [0] but it doesn't offer everything, so it depends on your needs. If you're going to be doing heavy OTP stuff you'll need to stick with Elixir. If you want to transpile to JS, then Gleam is the better choice. Otherwise it's up to your tastes around type systems and syntax.
I find it unfortunate. The BEAM is so influential as a VM, that most languages on top of it will be very similar. I don't really like the situation where we have Erlang, Elixir, and Gleam all atop the same VM, and they're all basically the same language. It's a split that isn't needed.
Gleam is nothing like Erlang or Elixir (its copying of Rust is so slavish it even has a toml file driven build system) and Erlang and Elixir are not split (the only place where they even sorta are is rebar vs. mix).
I don't particularly want to gatekeep "Rust fans who just want to write lots of Rust" off OTP. Let them have Gleam. Maybe they'll figure out how to lifetime-annotate binaries?
Gleam and Rust are really not alike at all aside from the most superficial ways. A couple bits of syntax, and the use of toml are about all I can come up with.
As always Gleam’s lsp actions show just how much useful code generation can be done without the need for any gen ai so long as you have strong types. I continue to be amazed just how much the community cares about the developer experience of the language.
The language server has been improving at such a fast pace it's hard to keep up! Soon I'll be out of code actions to implement
Thank you for all your work on the language!
Time to move to the Extend phase :^]
Feels like Gleam is gaining a lot of steam and getting a lot of attention recently. It’s the language that I am most excited about right now. It’s hitting all the right notes.
I do not quite understand that it runs on BEAM and Javascript with runtime.
Most of the great things I like about Elixir is tied to feature native to BEAM. (I think).
And I would expect that BEAM has not been ported to a Javascript runtime?
I would also expect at Gleam for Javascript can use and interact with Javascript libraries and what not, not possible under the regular version.
I would also expect that it is possible to write useful code that mill work on both platforms. but with a lot of limitations.
Do I have this completely wrong?
Yeah this is one of the typical mistakes of guest languages, they start by offering something that the platform language is missing out on, and eventual in the pursue for greater mindstart try to expand elsewhere, however by doing so, they lose the capabilities that made the original target platform special, and eventually become their own thing, if they survive beyond the typical adoption curve.
Most Gleam code is backend agnostic, but code that does something BEAM specific like OTP or Erlang FFI is only available when targeting the BEAM and JS ffi is only available when targeting JS. You can also provide two implementations of a function, one for each backend if you want to target both.
I think it might help to start with a baseline assumption: newer high-ish level languages (or any such language looking to expand mindshare) will inevitably be asked “[how] can I run code written in this language in a browser?”
Yup that's right, you can't use Erlang code on JS runtimes or JS code on Erlang runtimes. Most library code doesn't use either, so it's usable on both.
Elixir is also quite a lovely language even when not using any BEAM specific functionality! I used it a lot for writing regular sequential programs.
It's useful because you can write back-end and front-end code with the same language. Code sharing should work, as long as you don't use runtime-specific features blindly. All basic language features seem to work the same regardless of runtime.
All the pain to get echo working was 100% worth it! What a great release
As a dyed-in-the-wool print debugging advocate, and a Gleam-curious Erlang/BEAM enthusiast, this is very interesting for me.
Thanks for all your work, great to see how well the language and tooling are maturing.
print debugging is the best debugging <3 Thank you for the kind comment!!
Nah it's just the easiest and most reliable way. Usually anyway; sometimes you have extreme timing or space constraints and can't even use that. On microcontrollers I sometimes have to resort to GPIO debug outputs and I've worked on USB audio drivers where printf isn't an option.
hello fellow print debugging enjoyer, rejoice!
Thinking back on how Python 3 broke nearly all existing Python beginner code because they made print a function instead of a statement feels ironic now.
Sure print being a function has slight benefits in certain cases but the Gleam team also makes very compelling arguments to implement echo as a special keyword.
So what do we learn from that? Maybe don't do breaking changes to your language. Maybe debugging and actually printing should be separate things, one a statement, the other a function? I don't know.
I don’t know enough about Gleam’s implementation to say how applicable this is, but from a more general language design perspective… a keyword isn’t inherently imbued with special capabilities that a function call wouldn’t be. They’re semantically interchangeable for this use case, if the function can access requisite information about the underlying stack.
I’m not sure it’s possible to extrapolate any lessons for Python from this Gleam language feature or the chosen syntax.
Gleam looks like a really nice language that I haven't had a place to use yet. Does anyone have experience using it as a replacement/alternative for TypeScript for (e.g.) CLI tools?
What is the point of making echo a special syntax and not just a function? And add another function to retrieve stack info.
The compiler can inject information at compile time so no runtime reflection is necessary.
Well, there's nothing stopping the language from having builtin functions and constants in the standard library that are handled specially by the compiler, the same way this echo keyword is. That would've had the added benefit of being backwards compatible (which new keywords are not).
Gleam reserved a handful of keywords in 1.0 (including echo), so it isn't a new keyword.
that is basically just a keyword with extra steps...
Call site can be inlined in compile time, without special syntax. Full stack trace would require runtime support anyway.
What's a good way to learn Gleam? In college I would learn new languages/libraries/concepts through projects, but these days I have too many projects already.
I don't expect I'll ever use Gleam at work, but the language does look very appealing to me and fun to use.
Gleam's interactive tour is a great place to start: https://tour.gleam.run/
There's also an Exercism track that has exercises contributed by Gleam's creator: https://exercism.org/tracks/gleam
As Elixir is getting its own type system, should one still pick Gleam over Elixir?
They're kind of solving different problems. It's a bit like TypeScript vs Elm or PureScript: one is a type system overlaid onto an existing language with its own rich ecosystem and set of idioms, and the other is a new language that targets the same underlying platform but has different idioms and semantics for static analysis.
If you already have lots of Elixir in production, or you enjoy Elixir's highly dynamic approach to solving problems and would like to get some additional safety for free then sticking with Elixir is a no-brainer!
If you'd like a simpler language with tighter static analysis guarantees while still being able to dip into the wider ecosystem then you might prefer Gleam.
Ultimately I think the two languages have very different philosophies and idioms, folks will naturally find themselves preferring one or the other ^.^
I'm not fully qualified but in a nutshell, Gleam doesn't support OTP out of the box. There is a separate package for it [0] but it doesn't offer everything, so it depends on your needs. If you're going to be doing heavy OTP stuff you'll need to stick with Elixir. If you want to transpile to JS, then Gleam is the better choice. Otherwise it's up to your tastes around type systems and syntax.
[0] https://github.com/gleam-lang/otp
I find it unfortunate. The BEAM is so influential as a VM, that most languages on top of it will be very similar. I don't really like the situation where we have Erlang, Elixir, and Gleam all atop the same VM, and they're all basically the same language. It's a split that isn't needed.
Gleam is nothing like Erlang or Elixir (its copying of Rust is so slavish it even has a toml file driven build system) and Erlang and Elixir are not split (the only place where they even sorta are is rebar vs. mix).
I don't particularly want to gatekeep "Rust fans who just want to write lots of Rust" off OTP. Let them have Gleam. Maybe they'll figure out how to lifetime-annotate binaries?
Gleam and Rust are really not alike at all aside from the most superficial ways. A couple bits of syntax, and the use of toml are about all I can come up with.