BEAM's bright future with Gleam (and JavaScript?) - Peter Saxton | Code BEAM Lite Stockholm 2024

[@lpil]

Great talk as always Peter!!

[@okk2094]

What a nice talk!

[@StefanErwinBaumer]

I feel conflicted about Gleam. I do like the idea of static typing, but: - it fundamentally conflicts with the BEAM's hot code reloading and overall deployment patterns; you can get a message or subtype you don't expect because another node (or even module) is running a more recent version of the software than your node or reduction - Elixir, the language with the far more powerful ecosystem, is making huge strides in typing, which is really diminishing the added benefits of Gleam with every single release though I do suppose the JS interop is somewhat nice, but i'm not entirely convinced that this actually saves you having to add the mental overhead of an extra language into your project; in my experience you still have to understand JS well enough to the point that you could just write JS

[@سنابل-الفردوس]

you can compile to js so you can have client side typesafe apps or components also you can have the equviliant of Liveview in Lustre framework you can choose what components are server side and which are client side which you can't do in Liveview where everything is server side which can cause things to be slow if its an interractive part of your website

[@lpil]

Elixir's type system has very little in common with Gleam's type system. They provide completely different experiences, and one isn't really an alternative to the other. The two languages so different and so different to write that folks will generally have a preference for one and not have much interest for the other. In Gleam's recent community poll it was discovered that only 8% of Gleam folks were Elixir programmers when they started with Gleam.

[@Metruzanca]

Gleam using result types and pattern matching for everything solves most the problems of hot code w/ values you don't expect. Not to mention, Gleam's time system is technically optional. Theres a very good talk out there by Dylan (forgot his last name) who shows that adding only a few types (records) makes your codebase as able to be statically checked because gleam can infer most of it by how you're using the code. Elixir is definitely a more powerful ecosystem, considering the v1 was released on 2014 and Gleam's v1 was this year (2024). 10 years tends to be somewhat, of an advantage. However that being said, Gleam does bring lots of new ideas to the table, not just static types. Gleam compiles to javascript, and quite unlike Typescript, offers true static types. In TS theres a few scenarios where something unexpected might happen, e.g. some function throws an error. With Gleam, thats all handled to the gleam.mjs runtime. What you write in Gleam, will happen exactly in javascript. You don't have to think about "what JS is this spitting out?" Will you still need to know about browser APIs? Of course, though I do believe the plan is for the libraries that give you full FFI access to all browser functions, to only be used internally of other packages in the ecosystem and instead exposing my Gleam idiomatic functions. And similarly to when people write React native code, they need to sometimes dropdown and write kotlin/swift code, though with React native being very mature, those dropdowns happen more infrequently. Gleam is also much more opinionated. Theres truly only 1 way to do things in Gleam, which some people enjoy. And Gleam's sysntax is much unlike erland/elixir's, which other people like. Infact, the creator of Gleam has stated multiple times that he created Gleam so that he could have a C-like syntax for BEAM, initially, then started picking the best parts from languages he enjoyed. Gleam is also bringing loads of people to BEAM. Gleam discord did a poll recently asking where everyone was coming from and 90% of them were coming from non-beam languages. So Gleam is a great neighbor, bring more community.

[@StefanErwinBaumer]

@@Metruzanca How exactly does it solve the problem of dealing with values you don't expect? You put types there so the compiler *tells* you that you're covering all edge cases And then in production you get a type you didn't account for anyway because you received a value from a newer version of the software If your function is returning Error1 or Error2 right now and you match on those and the compiler tells you that's okay, it still doesn't protect you from returning Error 3 in the future, taking care of that case too, but then returning that new return type to a node that doesn't cover error 3 yet - gleam doesn't prevent this, in fact it's mathematically impossible for it to do so

[@سنابل-الفردوس]

​@@StefanErwinBaumerthat's a problem with the beam not with gleam Ericsson said they spent more time doing tests after they did a hot code reload than the time they spent writting the code