Gleam v1.9 | Hacker News Reader

Gleam v1.9

gleam.run

240 pointslpil71 comments

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 :^]

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?

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.

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.

Erlang FFI? Doesn’t the Erlang Virtual Machine run the Gleam code? How is calling Erlang functions FFI?

I just mean FFI in the general sense, that you're interfacing with a non-Gleam language. What's the word for that? Bindings?

I guess if you've transpiled Gleam to JS then is calling a JS function even FFI anymore?

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.

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.

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?”

The benefit is you can write JS by writing the same language as the rest of your app. I wish I could do that with Elixir. Not run the app on a javascript runtime but write frontend code that will transpile to JS.

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.

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!

Indeed, for me, the IDE debuggers became useless when we started writing multi threaded programs.

Printf is the only way to reliably debug multi threaded programs.

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.

That's the problem though: I think the thing that makes functions functions it that they operate on values alone (whatever “value” means in the context of the language — but it almost certainly doesn't include code or AST or anything like that), and don't care about, or even get to see, the particular expression that produced a given value. The thing that makes statements (or macros, or various other compile-time stuff) not-functions is that they don't just have access to values, but to the code as well, which lets them do stuff like print the expression that produced a value, which a function could never do (in most languages; I'm sure there are some out there, maybe a LISP or something, that attach the AST to expressions as metadata).

Right, and that strict definition of “function” is especially important in a language like Gleam. It may be less so in a language like Python where “function” is a much more malleable concept already. All the more reason I don’t think one could reasonably extrapolate lessons about the latter from syntax design decisions in the former.

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...

> That would've had the added benefit of being backwards compatible (which new keywords are not).

except it’s not a new keyword. and is your argument that you could easily define python print() to something else in a way that having a “print” keyword disallows? no wonder python 2=>3 was such a bear…

What you're describing is what `echo` is in terms of functionality and implemented, and it's not a new keyword so it is backwards compatible.

There are disadvantages of blurring the lines of what a function is an can do. Gleam values clarity above all things, so we don't have back-doors or special-cases. Everything plays by the same rules.

Call site can be inlined in compile time, without special syntax. Full stack trace would require runtime support anyway.

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 ^.^

Gleam is about as simple as Go but with a more expressive type system and Elm style guarantees that your app won’t crash if you stay in its ecosystem.

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.

> Maybe they'll figure out how to lifetime-annotate binaries?

What do you mean by this, I know how lifetimes work in rust, but how would you do it on the binary level ?

Binary is Erlangese for Vec<u8>, hope that helps

There are no lifetimes in gleam though right ? or did i miss the memo.

maybe they can add them to guard against copying large binaries too much

No lifetimes, absolutely no plans to add anything similar. We’re nothing like rust!

Hi, I'm the designer of Gleam!

Beyond being functional and sharing a runtime I don't think Elixir and Gleam have much in common at all. Our recent developer survey showed that the majority of Gleam programmers were not Elixir users and largely were not attracted to that language.

My question is: is how one approaches writing programs in Erlang, Elixir, and Gleam fundamentally different from one another? And is the difference enough for the split in the ecosystem?

> Our recent developer survey showed that the majority of Gleam programmers ... largely were not attracted to that language.

I must admit that I find that fairly bizarre. What do you imagine the source of that lack of desire is?

For context, my favorite language is F# and ML-dialects in general, but I also like what I call "principled" dynamically typed languages like Scheme, Racket, Erlang, and Elixir.

Yes, they are very different. It's not splitting the ecosystem though as the vast majority of Gleam programmers are not former Elixir, Erlang, or LFE programmers, it's people coming from other ecosystems.

Gleam grows the BEAM ecosystem by bringing people in from elsewhere who were not interested in writing Elixir, Erlang, or LFE.

> I must admit that I find that fairly bizarre. What do you imagine the source of that lack of desire is?

They're just very different languages to work with. The programming experience is very different.

There are TONS of JVM languages and nobody is complaining about that. BEAM is much smaller and a very nice target IMO. I learned Erlang but found it too weird for my tastes. Elixir lacked a type system when I evaluated it, and that steered me away from it. Gleam feels kind of like Elm felt. Small, simple, and safe. It feels very intentional and designed for a particular purpose and audience. I did their online tutorial and felt comfortable with the language in one sitting. Can’t say that for many other languages.

Who is choosing anything but Kotlin for new projects on the JVM?

The point is that beyond some basic typing things, programs written in Erlang, Elixir, and Gleam will all have the same core structure. Immutable data plus pattern matching plus BEAM processes has a pretty strong affect on any BEAM language.

> Who is choosing anything but Kotlin for new projects on the JVM?

I dunno... Scala, Clojure, and Groovy users? Small user bases, but the languages are not dead.

That's kind of my point. Does the JVM really need four different general purpose languages with their own ecosystems to split the JVM ecosystem and userbase?

Why not? There's like 483 different application frameworks for the JVM too. The more choices the better - it lets ideas cross-pollinate, and the best ideas get borrowed/stolen. Some people like different syntax, bindings, etc.

I find the opposite more troubling, actually. Take the C# ecosystem and see how there's one de-facto application framework (.NET), one logging lib, one etc... It's usually Microsoft's way or the highway, and 3rd party libraries and frameworks struggle to get any adoption. Consequently, that ecosystem is much smaller, less diverse, and less innovative.

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

Gleam isn't different from Erlang or Elixir in this case, all three languages implement OTP in "user land" rather than being part of the language. The only difference is how this OTP code gets distributed from the core team to you. In Gleam the BEAM ecosystem package manager is used, Elixir and Erlang leave it up to the operating system package manager, a docker container, or some other solution.

> all three languages implement OTP in "user land" rather than being part of the language

I understand that, but why then is OTP then limited on Gleam? Is interop to Erlang different than it is in Elixir? Elixir doesn't offer Elixir versions of a *lot* of OTP, but its Erlang interop feels quite natural (though not seamless). Can you just farm out to Erlang in Gleam? Does Gleam's static typing hinder this at all? Of course I can look this up for myself, but figured I'd asked here for the benefit of others since you're the author of Gleam :)

It’s not limited in Gleam. All existing Erlang and Elixir OTP modules are usable in Gleam, and there’s also an additional set of Gleam OTP modules which provide type safety guarantees for a subset of OTP functionality.

I think what they mean that the Gleam OTP implementation has some caveats - the two that jump out at me is not supporting named processes and not supporting all OTP system messages. Named processes, though, could be implemented like Elixir's Registry, but gleamically. Something that takes a type and returns a PID. Then the process gets named with a via-tuple that calls Gleam's registry.

Aye, but this is the same as Elixir; it doesn't have full support for OTP and you are expected to use Erlang modules when you want the rest.

RE named processes, that's coming in the next release, and there's already multiple registry modules implemented in Gleam, including one funded by the Erlang Ecosystem Foundation.

> Aye, but this is the same as Elixir; it doesn't have full support for OTP and you are expected to use Erlang modules when you want the rest.

Ya that's what I was asking about, mostly the interop. But I can just look it up :). Thanks, Louis!

Didn't even think to check for registry modules. The impression I got from the Gleam OTP readme is "can't use this yet", but that was overly pessimistic of me. I really need to give it a try in my next foray out of my comfort zone.

It’s certainly ready for use! The HTTP server made with it is used in production and was the fastest server available on the BEAM for some time, though Elixir’s Bandit has overtaken since then.

I've written OTP and distributed code using gleam. Type checking inter system messages was rough, but its not like it didnt work.

I have used gleam and my own FFI, calling erlang from gleam isn't difficult.

I tried to find out why I would try gleam, what I would use it for.

What I found convinced me it wasn’t for me.

1. Language behavior depends on the back end. Int doesn’t necessarily mean Int.

> When running on the Erlang virtual machine ints have no maximum and minimum size. When running on JavaScript runtimes ints are represented using JavaScript's 64 bit floating point numbers.

2. If it’s not an Int it’s a Float. Short numeric tower. I guess that’s ok. No BigInt with a guarantee it will not overflow? No exact Rational?

3. Type annotations [are optional and] “don’t change how the program runs”.

Ok this sounds like Python. Supposedly there are guarantees indicating “if it compiles it runs” but I’m worried. How do you even know the inferred type of your function is what you really think it should be? (I’m familiar with inference gone crazy from Haskell.)

> How do you even know the inferred type of your function is what you really think it should be?

By adding a type annotation? Am I missing something?

It's not anything like Python. The language that it is most like is probably F# or OCaml.

Python's type checkers are optional. They only verify code with annotations.

Gleam's type checker is mandatory, so it is impossible to compile code without type checking being performed. Type inference and checking are always fully performed, and adding type annotations doesn't make the compiler perform any extra checking.

> How do you even know the inferred type of your function is what you really think it should be? (I’m familiar with inference gone crazy from Haskell.)

Gleam doesn't have subtyping so this is typically trivial, but idiomatic code has all functions annotated for clarity. You can also hover in your editor, or read the documentation Gleam generates and publishes from code automatically.

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

Just wanted to thank you for this comment! I've been learning Gleam with Exercism and it's been so fun! It reminds me of when I was in college haha.

Whatever happened to the Erlang wasm backend?

Are you thinking of this, formerly known as Lumen?

https://github.com/GetFirefly/firefly

AFAIK it's been mothballed and one of the major contributors seems to have left the BEAM ecosystem altogether. They're doing Ethereum-ish smart-contract-ish stuff now. The other top contributor looks to have pulled way back from OSS dev of any kind.

Reply on news.ycombinator.com