Coming from Elixir, I gave Gleam a try for a couple of days over the holidays. Reasons I decided not to pursue:
- No ad-hoc polymorphism (apart from function overloading IIRC) means no standard way of defining how things work.
There are not many conventions yet in place so you won’t know if your library supports eg JSON deserialization for its types
- Coupled with a lack of macros, this means you have to implement even most basic functionality like JSON (de)serialization yourself - even for stdlib and most popular libs’ structs
- When looking on how to access the file system, I learned the stdlib does not provide fs access as the API couldn’t be shared between the JS and Erlang targets. The most popular fs package for erlang target didn’t look of high quality at all. Something so basic and important.
- This made me realise that in contrast to elixir which not only runs on the BEAM („Erlang“) but also runs with seamless Erlang interop, Gleam doesn’t have access to most of the Erlang / Elixir ecosystem out of the box.
There are many things I liked, like the algebraic data types, the Result and Option types, pattern matching with destructuring.
Which made me realize what I really want is Rust. My ways lead to Rust, I guess.
> Gleam doesn’t have access to most of the Erlang / Elixir ecosystem out of the box.
Gleam has access to the entire ecosystem out of the box, because all languages on the BEAM interoperate with one another. For example, here's a function inside the module for gleam_otp's static supervisor:
It's ok if you don't vibe with Gleam – no ad-hoc poly and no macros are usually dealbreakers for certain types of developer – but it's wrong to say you can't lean on the wider BEAM ecosystem!
Isn’t this the proof of my point - How does the need of writing „@external“ annotations by hand not contradict the point of being „out of the box“ usable?
Hayleigh, when I asked on the discord about how to solve my JSON problem in order to get structured logging working, you replied that I’m the first one to ask about this.
Now reading this:
> It's ok if you don't vibe with Gleam – no ad-hoc poly and no macros are usually dealbreakers for certain types of developer
Certainly makes me even more feel like gatekeeping.
I don't think Hayleigh was trying to gatekeep, just noting that some developers prefer features that Gleam intentionally omits.
As for the @external annotations, I think you're both right to a degree. Perhaps we can all agree to say: Gleam can use most libraries from Erlang/Elixir, but requires some minimal type-annotated FFI bindings to do so (otherwise it couldn't claim to be a type-safe language).
How does it contradict it? Without any modification/installation you can interop with Erlang/Javascript. How is that not out of the box usability of the Erlang/JS ecosystem? Syntax isn't as seamless as Elixir, but we need a way to tell Gleam what types are being passed around.
Why do you feel like a gatekeeper? Your opinion is valid, it's just that the interop statement was wrong.
That's FFI bindings. I need to provide the function signature of every API, because Erlang isn't statically typed. It's okay if some library provides it (like the linked , but I don't want to write this by hand if I can avoid it. And it's definitely not out of box, someone has to write the bindings for it to work
It would be different if I didn't have to write bindings and Gleam integrated automatically with foreign APIs. For Erlang that's probably not possible, but for the Javascript ecosystem it could make use of Typescript signatures maybe. (it would be very hard though)
Yeah, it's there out of the box but it's certainly not seamless. For an Elixir dev, it is more friction than you're used to. It is the cost of static types.
This is the same as Elixir, you need to specify what Erlang function to use in that language if you want to use Erlang code. The only difference is that Gleam has a more verbose syntax for it.
The runtime behaviour and cost of calling an Erlang function is the same in Elixir and Gleam, however the syntax is more verbose in Gleam as it asks for type information, while in Elixir this is optional.
The same point holds of interfaces. And it’s not clear what the alternative is. No type system I’m aware of would force you to change all occurrences of this business logic pattern, with or without ad hoc polymorphism.
But at least ad hoc polymorphism lets you search for all instances of that business logic easily.
ML languages have a "types, modules, types-of-modules, and functors" approach to ad-hoc poly. It's a bit strange compared to what other languages do. I am wondering whether it's ever been seen outside of SML and OCaml.
For JSON deserialisation, you would declare a module-type called "JSON-deserialiser", and you would define a bunch of modules of that module-type.
The unusual thing is that a JSON-deserialiser would no longer be tied to a type (read: type, not module-type). Types in ML-like languages don't have any structure at all. I suppose you can now define many different JSON-serialisers for the same type?
The article provides a contrived example and doesn't prove that ad-hoc polymorphism reduces type-safety. Even when `Maybe [a]` is being folded via `Foldable f` the claimed type-safety isn't reduced, it's the context of the folding that's being changed from `[a]` to `Maybe a`, and everything is type-safe. Secondly, if you really want to distinguish between the empty list and disabled allow-lists within your type-system you do define your own data type with that representation, and you don't declare it foldable, because the folding algebra doesn't make sense for any practical use-case of the disabled allow-lists. The language actually provides you with the means to reduce evaluation contexts your types can be part of.
I’ve been doing Elixir for 9 years, 5 professionally. Nobody cares about ad-hoc polymorphism. The community doesn’t use protocols except “for data”. Whatever that means. Global singleton processes everywhere. I’m really discouraged by the practices I observe but it’s the most enjoyable language for me still.
>I’ve been doing Elixir for 9 years, 5 professionally. Nobody cares about ad-hoc polymorphism.
That’s true for Elixir as practiced, but it’s the wrong conclusion for Gleam.
Elixir doesn’t care about ad-hoc polymorphism because in Elixir it’s a runtime convention, not a compile-time guarantee. Protocols don’t give you universal quantification, exhaustiveness, coherence, or refactoring safety. Missing cases become production crashes, not compiler errors. So teams sensibly avoid building architecture on top of them.
In a statically typed language, ad-hoc polymorphism is a different beast entirely. It’s one of the primary ways you encode abstraction safely. The compiler enforces that implementations exist, pushes back on missing cases, and lets you refactor without widening everything into explicit pattern matches.
That’s exactly why people who like static types do care about it.
Pointing to Elixir community norms and concluding “nobody cares” is mixing up ecosystem habits with language design. Elixir doesn’t reward those abstractions, so people don’t use them. Gleam is explicitly targeting people who want the compiler to carry more of the burden.
If Gleam is “Elixir with types,” fine, lack of ad-hoc polymorphism is consistent.
If it’s “a serious statically typed language on the BEAM,” then the absence is a real limitation, not bikeshedding.
Static types aren’t about catching typos. They’re about moving failure from runtime to compile time. Ad-hoc polymorphism is one of the main tools for doing that without collapsing everything into concrete types.
That’s why the criticism exists, regardless of how Elixir codebases look today.
It's an education problem on two fronts. People inside the ecosystem need to know about it. And also people too deep in the elixir ecosystem who don't know how ad-hoc polymorphism is supposed to be used in a statically typed language.
Both overcome it by admitting they don't know and need to learn.
I’m trying Gleam out right now, and having most recently been writing Go, I’m really loving:
- No nil, instead Option and Result
- ADTs
- Pattern matching + destructuring
- Immutable everything by default
- `use` syntactic sugar (weird at first, but once you’re used to it it’s pretty elegant)
- LSP server works great for such a young language
But most of all I think the overall simplicity of the language is really what’s standing out to me. So far I think the lack of ad-hoc poly and macros are a plus - it really reduces the impulse to write “magical” code, or code with lots of indirections. In the past I’ve definitely been guilty of over-abstracting things, and I’m really trying to keep things as simple as possible now. Though I’ve yet to try Gleam with a large project - maybe I’ll miss the abstractions as project complexity increases.
I suspect Gleam will be a great language for small to medium sized projects written with LLM assistance (NOT vibecoded) - the small language, strong typing and immutability gives good guardrails for LLM-generated code, and encourages a simple, direct style of programming where a human programmer can keep the whole structure in their head. Letting an LLM run free and not understanding what it’s written is I think where projects run into big problems.
In a language that is otherwise as simple as it could possibly get away with (no `if`!), `use <-` initially feels like magic and somewhat out of place.
But take look at nested callback code, the pyramid of doom, and you see why it's pragmatically necessary. It's a brilliant design that incorporates just enough metaprogramming magic to make it ergonomic. The LSP even lets you convert back and forth between nested callback style and `use`, so you can strip away the magic in one code action if you need to unravel it.
I am in love with Gleam! As a young computer science student, I found that Gleam brought back the joy of programming just when I felt like I was seriously burning out. I was never a fan of functional programming languages. I had tried other BEAM languages like Elixir and Erlang before, but Gleam is the one I’ve enjoyed the most :)
F# seem to be in abandon-ware state
the creator of F# moved to another job as his primary work
the forum and community are very dry
Nothing interesting being created in F#
As much as I had high hopes for F#
I think its safe at this point, to not pursuit it any further
.Net is C#
If you want an Ocaml like language, that is not Ocaml, your best bet is Rescript
and that being said, Rescript is probably more of a competitor to gleam, since gleam also have javascript as a target
The language is still ahead of C#, and still receiving features and keeping up by and large with the .NET ecosystem. Tbh I don't get the sheer negativity; the same thing could be said for Gleam or any other functional language these days tbh especially with AI coming along w.r.t long term support. Eventually things just work and are mostly complete; things don't have to get reinvented or get better forever.
> As much as I had high hopes for F# I think its safe at this point, to not pursuit it any further
I find this attitude interesting; you wanted it to be more than it was. I don't have high hopes for any language; other than it building my software which it and many others can do. Right tool for right job. I'm not attached to my code, other than if it can be maintained, changed, has sane defaults/guardrails to introduce less defects, etc. F# can do this, as many others. Interestingly I've seen the same attitude eventually happen to all languages of this class other than Rust; Scala, OCaml, etc are in similar positions.
Funnily enough Opus/CC has a number of times for my projects has suggested Rust, and if that doesn't work (too much for the team) went F# even over Java based langs assuming domain modelling code and the need for more perf (e.g. value types, and other stuff) without explicit prompting. Its then generated fsx scripts to run experiments, etc that seem to be more reliable than the default Python ones it runs (package errors and static typing fixes mostly). `dotnet fsi` fits well into the agentic workflow.
> Rescript and that being said, Rescript is probably more of a competitor to gleam
Depends on your target. F# at least has a backdoor into the C# ecosystem - from a risk perspective that makes it more palatable. New languages have an initial "excitement" about them; but generally they are just tools.
Pick something that fits your team and build. F# does work, and so do many other tools. In the age of AI IMO the ecosystem and guardrails for the AI matter more than the language and its syntax IMO other than readability. In this regard F# still is "less risky" with its .NET interop.
Wake up and smell the coffee: fsharp is dead. Look at the release notes of fsharp. It's laughable for a major version update. It's maintained by like 5 people working in eastern Europe and they only do maintenance updates basically. C# is getting all its features and DotNet is basically c# oriented anyway. So even in the past you had to learn C# to program in F#
I would assert that Microsoft's management always behaved as if they repented to have added F# to VS 2010, with all the maintenance guarantees it implies, throughout the years they have searched how to sell it.
Nowadays CLR has effectively changed meaning to C# Language Runtime, and ironically the JVM is more lively as the original goal of the CLR back in 2001.
My “intro to gleam” was a lustre form for my blog, where people could submit feedback. So I was able to create a neatly separated client module in Gleam and compile it to JavaScript so I can insert it in my static blog page. The server part was a separate gleam module with erlang as a target. They shared models and some constants with a “shared” module - just like the tutorial.
I find this kind of explicit separation very powerful. It also removes some of the anxiety if something will end up in a client bundle when it’s supposed to be server only.
JS/TS isn't my favourite language, but it's pretty decent these days. If I'm picking a different language and targeting the web, it's probably because I want to run the same code natively as well.
Gleam is technically as suitable for distributed computing as Erlang: since it compiles to Erlang, it can do anything that Erlang can. You can use Erlang and Elixir libraries and write FFI code to do things that would be unergonomic to do in Gleam. Sure the experience is different and if you want to embrace the guarantees of static typing, then the APIs will look different, like gleam_otp.
If you compile it to JS, then the guarantees change to JS's guarantees.
Personally I've felt that the JS target is a big plus and hasn't detracted from Gleam. Writing a full stack app with both sides being in Gleam and sharing common code is something I've enjoyed a lot. The most visible impact is that there's no target specific functions in the stdlib or the language itself, so Erlang related things are in gleam_erlang and gleam_otp, and e.g. filesystem access is a package instead of being in the stdlib. If you're just into Erlang, you don't need to interact with the JS target at all.
Same here, I've only been using it for a bit and have 100% been ignoring the JS part and the only time where I felt I needed to think about it for a moment was when I was writing a patch for someone else's code that did not ignore it, so basically when contributing to a library you might have to do extra work.
Of course I can't say if anyone ever made any decisions based on the other target that would have repercussions for me only using the BEAM.
Biggest issue with this language. But... fairly trivial to implement codegen with gleam/glance[0]. No good libraries do this well right now (e.g. support for discriminated unions).
I remember playing with Alpaca a few years ago, and it was fun though I didn’t find the resulting code to significantly less error-prone than when I wrote regular Erlang. It’s inelegant, but I find that Erlang’s quasi-runtime-typing with pattern matching gets you pretty far and it falls into Erlang’s “let it crash” philosophy nicely.
Honestly, and I realize that this might get me a bit of flack here and that’s obviously fine, but I find type systems start losing utility with distributed applications. Ultimately everything being sent over the wire is just bits. The wire doesn’t care about monads or integers or characters or strings or functors, just 1’s and 0’s, and ultimately I feel like imposing a type system can often get in the way more than it helps. There’s so much weirdness and uncertainty associated with stuff going over the wire, and pretty types often don’t really capture that.
I haven’t tried Gleam yet, and I will give it a go, and it’s entirely possible it will change my opinion on this, so I am willing to have my mind changed.
I don’t understand this comment, yes everything going over the wire is bits, but both endpoints need to know how to interpret this data, right? Types are a great tool to do this. They can even drive the exact wire protocol, verification of both data and protocol version.
So it’s hard to see how types get in the way instead of being the ultimate toolset for shaping distributed communication protocols.
Bits get lost, if you don’t have protocol verification you get mismatched types.
Types naively used can fall apart pretty easily. Suppose you have some data being sent in three chunks. Suppose you get chunk 1 and chunk 3 but chunk 2 arrives corrupted for whatever reason. What do you do? Do you reject the entire object since it doesn’t conform to the type spec? Maybe you do, maybe you don’t, or maybe you structure the type around it to handle that.
But let’s dissect that last suggestion; suppose I do modify the type to encode that. Suddenly pretty much every field more or less just because Maybe/Optional. Once everything is Optional, you don’t really have a “type” anymore, you have a a runtime check of the type everywhere. This isn’t radically different than regular dynamic typing.
There are more elaborate type systems that do encode these things better like session types, and I should clarify that I don’t think that those get in the way. I just think that stuff like the C type system or HM type systems stop being useful, because these type systems don’t have the best way to encode the non-determinism of distributed stuff.
You can of course ameliorate this somewhat with higher level protocols like HTTP, and once you get to that level types do map pretty well and you should use them. I just have mixed feelings for low-level network stuff.
> But let’s dissect that last suggestion; suppose I do modify the type to encode that. Suddenly pretty much every field more or less just because Maybe/Optional. Once everything is Optional, you don’t really have a “type” anymore, you have a a runtime check of the type everywhere. This isn’t radically different than regular dynamic typing.
Of course it’s different. You have a type that accurately reflects your domain/data model. Doing that helps to ensure you know to implement the necessary runtime checks, correctly. It can also help you avoid implementing a lot of superfluous runtime checks for conditions you don’t expect to handle (and to treat those conditions as invariant violations instead).
No, it really isn’t that different. If I had a dynamic type system I would have to null check everything. If I have declare everything as a Maybe, I would have to null check everything.
For things that are invariants, that’s also trivial to check against with `if(!isValid(obj)) throw Error`.
Sure. The difference is that with a strong typing system, the compiler makes sure you write those checks. I know you know this, but that’s the confusion in this thread. For me too, I find static type systems give a lot more assurance in this way. Of course it breaks down if you assume the wrong type for the data coming in, but that’s unavoidable. At least you can contain the problem and ensure good error reports.
The point of a type system isn’t ever that you don’t have to check the things that make a value represent the type you intend to assign it. The point is to encode precisely the things that you need to be true for that assignment to succeed correctly. If everything is in fact modeled as an Option, then yes you have to check each thing for Some before accessing its value.
The type is a way to communicate (to the compiler, to other devs, to future you) that those are the expected invariants.
The check for invariants is trivial as you say. The value of types is in expressing what those invariants are in the first place.
I don’t think I did. I am one of the very few people who have had paying jobs doing Scala, Haskell, and F#. I have also had paying jobs doing Clojure and Erlang: dynamic languages commonly used for distributed apps.
I like HM type systems a lot. I’ve given talks on type systems, I was working on trying to extend type systems to deal with these particular problems in grad school. This isn’t meant to a statements on types entirely. I am arguing that most systems don’t encode for a lot of uncertainty that you find when going over the network.
You're conflating types with the encoding/decoding problem. Maybe your paying jobs didn't provide you with enough room to distinguish between these two problems. Types can be encoded optimally with a minimally-required bits representation (for instance: https://hackage.haskell.org/package/flat), or they can be encoded redundantly with all default/recovery/omission information, and what you actually do with that encoding on the wire in a distributed system with or without versioning is up to you and it doesn't depend on the specific type system of your language, but the strong type system offers you unmatched precision both at program boundaries where encoding happens, and in business logic. Once you've got that `Maybe a` you can (<$>) in exactly one place at the program's boundary, and then proceed as if your data has always been provided without omission. And then you can combine (<$>) with `Alternative f` to deal with your distributed systems' silly payloads in a versioned manner. What's your dynamic language's null-checking equivalent for it?
With all due respect, you really do not understand these protocols if you think “just use TCP and ECC” addresses my complaints.
Again, it’s not that I have an issue with static types “not protecting you”, I am saying that you have to encode for this uncertainty regardless of the language you use. The way you typically encode for that uncertainty is to use an algebraic data type like Maybe or Optional. Checking against a Maybe for every field ends up being the same checks you would be doing with a dynamic language.
I don’t really feel the need to list out my full resume, but I do think it is very likely that I understand type systems better than you do.
Fair enough, though I feel so entirely differently that your position baffles me.
Gleam is still new to me, but my experience writing parsers in Haskell and handling error cases succinctly through functors was such a pleasant departure from my experiences in languages that lack typeclasses, higher-kinded types, and the abstractions they allow.
The program flowed happily through my Eithers until it encountered an error, at which point that was raised with a nice summary.
Part of that was GHC extensions though they could easily be translated into boilerplate, and that only had to be done once per class.
Gleam will likely never live to that level of programmer joy; what excites me is that it’s trying to bring some of it to BEAM.
It’s more than likely your knowledge of type systems far exceeds mine—I’m frankly not the theory type. My love for them comes from having written code both ways, in C, Python, Lisp, and Haskell. Haskell’s types were such a boon, and it’s not the HM inference at all.
I know everyone says that this is a huge issue, and I am sure you can point to an example, but I haven’t found that types prevented a lot of issues like this any better than something like Erlang’s assertion-based system.
While I don't agree with the OP about type systems, I understand what they mean about erlang. When an erlang node joins a cluster, it can't make any assumptions about the other nodes, because there is no guarantee that the other nodes are running the same code. That's perfectly fine in erlang, and the language is written in a way that makes that situation possible to deal with (using pattern matching).
Interesting! I don't share that view at all — I mean, everything running locally is just bits too, right? Your CPU doesn't care about monads or integers or characters or strings or functors either. But ultimately your higher level code does expect data to conform to some invariants, whether you explicitly model them or not.
IMO the right approach is just to parse everything into a known type at the point of ingress, and from there you can just deal with your language's native data structures.
I know everything reduces to bits eventually, but modern CPUs and memory aren’t as “lossy” as the network is, meaning you can make more assumptions about the data being and staying intact (especially if you have ECC).
Once you add distribution you have to encode for the fact that the network is terrible.
You absolutely can parse at ingress, but then there are issues with that. If the data you got is 3/4 good, but one field is corrupted, do you reject everything? Sometimes, but often Probably not, network calls are too expensive, so you encode that into the type with a Maybe. But of course any field could be corrupt so you have to encode lots of fields as Maybes. Suddenly you have reinvented dynamic typing but it’s LARPing as a static type system.
I think you can avoid most issues by not doing what you're describing! Ensuring data arrives uncorrupted is usually not an application-level concern, and if you use something like TCP you get that functionality for free.
TCP helps but only to a certain extent; it only guarantees specific ordering of bits during its session. Suppose you have to construct an object out of three separate transmissions, like some kind of multipart style thing. If one of the transmissions gets corrupted or gets errors out from TCP, then you still fall into that maybe trap.
I get what your saying, but can't you have the same issue if instead you have 3 local threads that you need to get the objects from, one can throw an exception and you only receive 2, same problem
Sometimes, but I am arguing that you need to encode for this uncertainty if you want to make distributed apps work correctly. If you can do transactions for what you’re doing then great, not every app can do that.
When you have to deal with large amounts of uncertainty, static types often reduce to a bunch of optionals, forcing you to null check every field. This is what you end up having to do with dynamic typing as well.
I don’t think types buy you much in cases with extreme uncertainty, and I think they create noise as a result.
It’s a potentially similar issue with threads as well, especially if you’re not sharing data between them, which has similar issues as a distributed app.
A difference is that it’s much cheaper to do retries within a single process compared to doing it over a network, so if something gets borked locally then a retry is (comparatively) free.
> static types often reduce to a bunch of optionals, forcing you to null check every field
On one end, you write / generate / assume a deserialisator that checks whether incoming data satisfies all required invariants, eg all fields are present. On the other end, you specify a type that has all the required fields in required format.
If deserialisation fails to satisfy type requirements, it produces an error which you can handle by eg falling back to a different type, rejecting operation or re-requesting data.
If deserialisation doesn't fail – hooray, now you don't have to worry about uncertainty.
The important thing here is that uncertainty is contained in a very specific place. It's an uncertainty barrier, if you wish: before it there's raw data, after it it's either an error or valid data.
If you don't have a strict barrier like that – every place in the program has to deal with uncertainty.
So it's not necessarily about dynamic / static. It's about being able to set barriers that narrow down uncertainty, and growing number of assumptions. The good thing about ergonomic typing system is that it allows you to offload these assumptions from your mind by encoding them in the types and let compiler worry about it.
It's basically automatization of assumptions book keeping.
But your program HAS to have some invariants. If those are not held, simply reject all the data!
What the hell is really the alternative here? Do you just pretend your process can accept any kind of data, and just never do anything with it??
If you need an integer and you get a string, you just don't work. This has nothing to do with types. There's no solution here, it's just no thank you, error, panic, 500.
> Honestly, and I realize that this might get me a bit of flack here and that’s obviously fine, but I find type systems start losing utility with distributed applications. Ultimately everything being sent over the wire is just bits.
Actually Gleam somewhat shares this view, it doesn't pretend that you can do typesafe distributed message passing (and it doesn't fall into the decades-running trap of trying to solve this). Distributed computing in Gleam would involve handling dynamic messages the same way handling any other response from outside the system is done.
This is a bit more boilerplate-y but imo it's preferable to the other two options of pretending its type safe or not existing.
the dynamic messages have to have static properties to be relevant for the receiving program, the properties are known upfront, and there's no "decades-running trap of trying to solve this".
> there's no "decades-running trap of trying to solve this".
I’m not as certain. The fact that we’ve gone from ASN.1 to COBRA/SOAP to protobuf to Cap’n’web and all the million other items I didn’t list says something. The fact that, even given a very popular alternative in that list, or super tightly integrated RPC like sending terms between BEAMs, basic questions like “should optionality/absence be encoded differently than unset default values?” and “how should we encode forward compatibility?” have so may different and unsatisfactory answers says something.
> I’m not as certain. The fact that we’ve gone from ASN.1 to COBRA/SOAP to protobuf to Cap’n’web and all the million other items I didn’t list says something.
> It absolutely is a decades old set of problems that have never been solved to the satisfaction of most users.
ASN.1 wasn't in the same problem space with CORBA/DCOM, both CORBA and DCOM/OLE were heavily invested in a general-purpose non-domain-specific object model representation that would suppot arbitrary embeddings within an open-ended range of software. I suspect this is the unsolvable problem indeed, but I also believe that's not what you meant with your comment either, since all the known large-scale BEAM deployments (the comment I originally replied to implied BEAM deployments) operate within bounded domain spaces such as telecom and messaging, where distributed properties of the systems are known upfront: there are existing formats, protocols of exchange, and the finite number of valid interactions between entities/actors of the network, the embeddings are either non-existent or limited to a finite set of media such as static images, videos, maps, contacts etc. All of these can be encoded by a compile-time specification that gets published for all parties upfront.
> basic questions like “should optionality/absence be encoded differently than unset default values?”
However you like, any monoid would work here. I would argue that [a] and [] always win over (Option a) and especially over (Option [a]).
> and “how should we encode forward compatibility?”
You seem to have a fundamental misunderstanding about type systems. Most (the best?) typesystems are erased. This means they only have meaning "on compile time", and makes sure your code is sound and preferrably without UB.
The "its only bits" thing makes no sense in the world of types. In the end its machine code, that humans never (in practice) write or read.
I know, but a type system works by encoding what you want the data to do. Types are a metaphor, and their utility is only as good as how well the metaphor holds.
Within a single computer that’s easy because a single computer is generally well behaved and you’re not going to lose data and so yeah your type assumptions hold.
When you add distribution you cannot make as many assumptions, and as such you encode that into the type with a bunch of optionals. Once you have gotten everything into optionals, you’re effectively doing the same checks you’d be doing with a dynamic language everywhere anyway.
I feel like at that point, the types stop buying you very much, and your code doesn’t end up looking or acting significantly different than the equivalent dynamic code, and at that point I feel like the types are just noise.
I like HM type systems, I have written many applications in Haskell and Rust and F#, so it’s not like I think type systems are bad in general or anything. I just don’t think HM type systems encode this kind of uncertainty nicely.
For anyone opening the link and wondering why the expected "gleam.toml" is missing: the project contains 2 Gleam sub-projects. The server/ directory is the BEAM server (no framework) and the client/ directory is the gleam-compiled-js client (lustre framework).
Unfortunately, there are many tests for the server, and none for the client.
One of the best things about erlang/elixir is the repl driven development/manual testing.
Gleam has no `interpreted` story, right? Something like clojure, common lisp, etc.
I think this matters because debugging on beam is not THAT great, there are tools in erlang/elixir to facilitate debugging, like inspect() or dbg().
If anyone has experience in this language, what is the mindset with gleam? How you guys debug?
> If anyone has experience in this language, what is the mindset with gleam? How you guys debug?
There is the echo keyword now, which is comparable to elixir's dbg(), I use that a lot.
Lacking a REPL, what I normally do is make a dev module, like 'dev/playground.gleam' where I'm testing things out (this is something that the gleam compiler supports, /dev is similar to /test) and then run it with 'gleam run -m playground'.
Sometimes I also use the Erlang shell. You can get an Erlang shell with all the gleam modules from your project loaded in with the 'gleam shell' command. You just need to know the Erlang syntax, and how Gleam modules are named when compiled to Erlang (they use an '@' separator, so gleam/json becomes 'gleam@json').
Gleam is nice. However it is still very lacking in the stdlib. You will need lots of dependencies to build something usable. I kind of wish Gleam could target something like Go, then you would have the option to go native without a "heavy" VM like the BEAM.
I still suspect the effectiveness of plugging in a type system patch to a complete system, like typescript to javascript. We still observe so many `as any` or `as unknown as` at every corner.
Despite of the suspicion, Gleam provides a better and elegant syntax for those who are not familiar with Erlang or functional programming languages, which I loved most.
That doesn’t really apply to Gleam, it’s not a type syntax for another language that can be stripped, it’s its own language that compiles to Erlang and JS
Or the contrary, the kind of people finding this cool is usually the people you don't want in your community. Nice to have clarity about who doesn't want to even bother to deal with whom.
This is a terrible take. Just because your personal opinions / morals / values don't align with others in a community, doesn't automatically make you an asshole. If people can't handle others having differing opinions, they have some growing up to do and shouldn't be leading a community.
Someone not being a BLM supporter, doesn't equate to them holding the opinion that anyone should be oppressed. Only someone who views everything through a binary lens / is trapped in dualistic thinking, would suggest such a thing. One shouldn't automatically claim someone else is an asshole for not agreeing to think the exact same way they do.
let me clarify the intent of my comment then. Human rights is not a "two-sides" issue to be debated. If you attempt to reduce an affirmation of human rights for all people to a "political agenda", I will call out your conservative dogwhistle. I don't care how that's received.
How is it insane to only welcome people to a community that act respectful towards other people? That seems like a really good way to build a solid community.
That's not the case with the Gleam community though. Unless you're willing to adopt their opinions / values / moral stance on certain issues, you won't be treated respectfully - you will be ostracized for having an unpopular opinion or view on a given issue.
It is a totally insane way to run a project, and it's quite obvious the Gleam community is run by persons who are unable to handle people with opinions that differ from their own.
It does sound like a great way to build an echo chamber.
Ah yes, because not automatically supporting grifts like the BLM movement (which enriched the founders and did very little for the black community at large), makes someone a racist - I totally forgot!
Black Lives Matter is objectively not a grift. There is an argument to be made regarding "BLM Global Network", but calling them BLM is like saying all vegans support PETA.
Regardless, that's irrelevant to the discussion at hand. You don't have to change your beliefs to be part of the Gleam community, you just have to not be an asshole about them. If you're the kind of person that starts an argument any time BLM is mentioned, is it understandable why they wouldn't want you in their community?
There we go again. I think that you people would gain if you'd read what does it mean if something is objective and also the meaning of "subjective". Either you live in social bubbles or you're intentionally ignoring anything that's not in line with your ideology. I'm actually not surprised this is the case, since you're not allowing people outside of your bubbles in your community spaces. You cherish diversity, yet in reality you're the most ideologically closed social group that I know. Letting people in only if it's easy for you is very far from "welcoming".
You're accusing the parent of being an asshole, yet you dismiss his arguments based on false "objectivity". And because of your "objectivity", which is clearly subjective, you reinforce the argument that parent is not welcome in your community. How is this welcoming?
I explicitly did not call them an asshole, it was very much conditional on the way they choose to act inside these communities.
Regarding your accusation of subjectivity, I was addressing the misnomer that BLMGN is equivalent to the BLM movement - it's not. BLMGN might be a grift for all I know, but that cannot be used to call the entire BLM movement a grift. By definition a grifter is aware that they're grifting, do you believe that every BLM protest was organised by someone looking to make a profit? If not, BLM is objectively not a grift.
On the topic of being 'welcoming', clearly you don't understand the paradox of tolerance. Is it intolerant to exclude Nazis from a community? Obviously not, despite what the Nazis would claim, because Nazis make the communities they're involved in intolerable to anyone that's not a Nazi.
Thus, if you want to create an inclusive community, you have no choice but to exclude certain groups of people.
It's actually pretty simple to figure out which groups should be excluded: - Transphobes are constantly imposing their beliefs on trans people, trans people want equal rights. - White supremacists are constantly imposing their beliefs on black people, black people want equal rights. - Homophobes are constantly imposing their beliefs on gay people, gay people want equal rights. Do I need to continue?
To be clear, I barely interact with these "safe" communities - pretty much only when I need some help with my code. It's very easy to hide your beliefs if you want to participate, I could be a raging homophobe for all they know because I've never talked about gay people in there.
You say the they don't tolerate anyone outside their bubbles, but anyone is free to join and start getting support, there's no purity test. So do you mean they don't tolerate people questioning trans rights in a support channel? Because obviously they don't. If you want to start an argument there are plenty of appropriate places to do so, places that don't make people feel unsafe.
> What happens if you don't use the correct pronouns someone has declared for themselves? Is this not "imposing beliefs" on other people?
That's a false equivalence. All that's asked of you is to not misgender or deadname them, whereas transphobes are actively making it impossible for trans people to freely live as themselves.
It's also about not being a dickhead. If you met an autistic kid, and were told that he becomes incredibly distressed if you don't refer to him as 'Mr.', would you at least make an effort to call him that?
It doesn't matter how ridiculous you think calling a kid 'Mr.' is, he isn't imposing his beliefs on you by asking that of you.
If someone decides that their community will be a safe place for the kid to be, then of course they're justified in removing you if you refuse to call him 'Mr'.
Regardless of whether you believe trans people are mentally ill or just a normal part of humanity, not misgendering them is a simple courtesy to avoid causing a fellow human distress.
> "Feeling unsafe" is an outstanding weapon to crush behavior one doesn't like. Doesn't even require logic: it's literally a feeling.
How is this relevant to a programming language community? Who, in your scenario, is doing the crushing?
For the sake of simplicity, and to detach our feelings from this subject, let's assume that Ω-GN is a grift. Ω is a superset of Ω-GN. We cannot conclude that Ω is a grift solely because a subset (Ω-GN) is a grift. However, can we objectively say that Ω is not a grift just because there are some instances within Ω that are not grifts? Clearly, there are also instances within Ω that are grifts, since Ω-GN (a subset of Ω) is a grift by our assumption. Therefore, the existence of both grift and non-grift instances in Ω means we cannot categorically label Ω as either a grift or not a grift based solely on its subsets.
Yet you say that objectively it's not a grift because there is at least 1 instance of a non-grifting event in Ω. Even Kenneth Copeland _sometimes_ is right about _something_, can we say that objectively he's not a liar because _there was at least 1 instance of him telling the truth_? I think not.
Also, you people use this word, "nazi", but do you actually know what are Nazis? German National-Socialists. Even the name "NAZI" is taken from German language. So if you ask me "what is wrong with disliking nazis", yet you use some artificial and historically wrong definition of a nazi, then I'm telling you that the problem is with you people using "nazis" for others who disagrees with you. I probably am a Nazi in someone's eyes, because I'm opposed to trans-women participating in women's sports. In reality, my grandfather fought with the actual nazis which existed in real world, not in your imagination.
> Thus, if you want to create an inclusive community, you have no choice but to exclude certain groups of people.
Yeah, this is how I understand it as well. People want easy inclusivity, a mono-themed style of thinking, and diversity only within their own strictly defined boundaries. I interpret this as a contradiction and a lie: diversity among selected groups is not true diversity, and inclusivity limited to chosen pools is not genuine inclusivity. For me there is absolutely no difference between this and a situation where whites stick to whites, blacks stick to blacks, etc.
If something is marked as "LGBTQ+ friendly" then I'm all fine -- it's very understandable and I know what I'm dealing with. But if something is "inclusive" then I automatically know I'm not in the target audience, because the sole definition of "include" is already loaded. The language already contains words with different meanings. For me this means "we're so closed, we even use our own definition of 'inclusion' to not think about the outside world".
You seem quite passionate about this, which I find difficult to understand, maybe because I’m not as deeply immersed in American political culture as you (I had no idea people see BLM as an organisation rather than a movement / ethical stance) but I’m curious: Is it really just about language for you?
If the section was phrased as “We are LGBTQ+ friendly and do not tolerate transphobia or racism” that would feel more welcoming to you?
At the end of the day, it’s a programming language community. If you join and ask a question about how to call functions from Erlang, you’ll definitely get an answer. If you join and bring up your feelings about trans women in sports you’ll most likely be asked to stop or removed, as it’s just not a space where that kind of discussion is welcome.
> If the section was phrased as “We are LGBTQ+ friendly and do not tolerate transphobia or racism” that would feel more welcoming to you?
It's very, very easy to turn ideas into "racism" or "transphobia."
> it’s just not a space where that kind of discussion is welcome
These folks believe no space exists where this type of discussion is welcome and will deny participation to anyone not towing the party line in all forums - not just their little fiefdom.
It's not American, it's global. I'm not American, yet I'm judged by the these political culture quirks. The creator of Gleam is not American, he's from UK. Trans-movements aren't American, they're in my country too, and I'm interested somewhat in the politics of my own country. Also parent posts differentiated between BLM and BLM-GN, where one is a "movement", and the other one is supposedly a marxist organization, so I guess there's a difference too.
> Is it really just about language for you?
No. I mean, I'm not a murderer. I'm not a thief. I only do to others what I want others to do to me. I don't want to be treated differently because of my race or my gender, therefore I don't want to treat others differently because of those things. Yet, I actually am treated differently because of it; and it's mostly by those people who "fight racism" and "fight transphobia". Who are virtue signalling left and right how tolerant they are. How inclusive they are. When a black director says "I'll never hire a white main actor" then it's OK. But when I point out he said it, then I'm a racist -- this is how it works today. So:
> If the section was phrased as “We are LGBTQ+ friendly and do not tolerate transphobia or racism” that would feel more welcoming to you?
No, because it's too easy to frame my views as transphobic or racist, like I've written in my previous paragraph. And this is the language part. Using "master" branch in git today is a manifestation of racism. People fork "rubocop" projects because it has a "cop" in the name; and they want to defund the police. I think that police is needed because without it the law wouldn't exist? Then I'm a nazi. When I'm asking questions about whether someone's wheels were spinning during sudden acceleration, I'm being called an ICE-lover.
You might see me being passionate, but I'm merely a product of current political polarity.
> If you join and bring up your feelings about trans women in sports you’ll most likely be asked to stop or removed, as it’s just not a space where that kind of discussion is welcome. But why should it be?
No, I will be removed only when I say that it's not OK. I will be upvoted when I'll say that it's OK. But more generally, that's a good question, but I don't know the answer, ask Ipil, he sees the necessity. I do think that there's no reason why it should be a place for discussion of trans-rights and racism and I wouldn't want to discuss it there (not even here to be honest). So why it's being manifested on the main page, before the language tour and before the newsletter, since it's clearly not a place for these topics?
Take it to mean a literal straight out of 1942 National Socialist if you like, it doesn't change what I was trying to convey.
If you want a historical comparison to BLM, how about the suffragettes. I can guarantee that there were grifters looking to make money off the movement, which would be a subset of it, but I think it's quite fair to say the suffragettes were objectively not grifters.
I would also say that Christianity is objectively not a grift, despite the fact that there are many grifters within the faith. If the core ideas of a movement are spread by people that truly believe in them, and are not controlled by any individual, then how exactly could it qualify as a grift?
Legitimately, I don't understand how a decentralised set of ideas could be a grift. Do you have any examples?
"Diversity only within their own strictly defined boundaries" is exactly right, but you don't seem to understand that those boundaries are what let's diversity thrive. Without rules against bigotry, LGBTQ+ people are far less able to express themselves due to the increased scrutiny from people that refuse to accept them.
When there are people in a community that denegrate others for being themselves it creates a toxic environment where being different makes you a target, so everyone either falls in line or leaves.
It's really funny, because that's how I portray inclusive people. They're nice until they bring friends. And later friends require changing the vocabulary and I don't even know how to communicate with them. But I'm not calling them soviets.
I've literally said in my previous message that in my opinion it can't be said that BLM is a grift, and can't be said that it is not a grift. It's not even about a grift, it's about objective statements.
I guess we have to agree to disagree, since it's apparent we're not even reading ourselves properly.
By the way, one date of importance when it comes to nazism for me is 1st September 1939. German nazis marked a whole country for extermination, but you're having a good time by comparing children with computers from a Reddit story to nazis.
I don't think Gleam has a problem if Kenneth Copeland is using their software, either. The problem arises when you mistreat community members in community spaces; I can't speak for DRH, but I'm reasonably sure if someone waltzed into SQLite's forum denigrating the devs and their religious beliefs, there wouldn't be much hesitation in removing that person from said forum.
> I don't think Gleam has a problem if Kenneth Copeland is using their software, either.
I wouldn't be so sure. In leftist projects, there are countless of examples why someone is not welcome based on their personal beliefs, and because of this I'm cautiously suspicious about Gleam.
If I'm wrong then the Internet is a better place than I think it is, which would be a good thing. If I'm right, then at least I'll dodge another bullet. Either way I win I guess.
It is, however, unfortunate that a single statement on the Gleam homepage generates this exact conversation every time Gleam trends somewhere.
It's your project, and your community, of course, and I fully respect that. However it doesn't seem good that this statement creates so much friction and controversy for Gleam over and over.
After all, none of the statement's topics would be "on-topic" for any of the Gleam community hangouts. For instance, it would be equally off-topic for someone to discuss supporting or hating Nazis.
Perhaps moving the statement to a formal Code of Conduct page would be a "have cake and eat it too" type thing.
The Gleam community is wonderful, and you've done an incredible job building it. But I don't suspect the homepage statement had anything to do with that.
As with many languages that compile to a VM, I always ask myself: that’s all nice, but how do I interact with anything OUTSIDE of my program?
Can I do networking? Can I do system calls to my OS? Display graphics and sound? Can I import a C library that will do all that and call its functions? And if so, how? I just can’t see it from any documentation. Yes, I can call functions from other BEAM-based languages, but then I’m going in circles.
I am really interested in whether anyone has evaluated the performance of Gleam? The language is simple, easy to understand, like `Go` for example, but is it really performant like Go, or does it have any performance cost since it runs on top of a VM?
1. It runs on the BEAM - exceptionally slow compared to Go, but infinitely scalable by default in a way that Go is not - in practice, very rarely matters.
2. They will argue the slowness doesn't matter -> if ~97% of time is spent waiting on I/O -> you can be 10x slower and that means you're only ~30% for typical applications -> it's easier to scale more machines on the BEAM than it is to scale a single machine -> this is true, but largely irrelevant in Go's core market -> it's almost as if Go was built by smart people.
3. The reality is that predictability is much harder to guarantee once you start moving components to different machines. Correct, predictable distributed computing makes correct, predictable concurrent programming look easy.
4. The BEAM does not allow shared memory, Go does (unsafely). There are many cases where the performance impact of this is night and day (why Go ultimately allowed unsafety).
I assume Gleam claims to make this just work. But as someone working in this space, this seems like trying to abstract away the difference between taking a boat to Europe or a plane.
Gleam may be nice if you're building something for the BEAM (massively scalable single app that just makes sense with the actor model, typically chat / telecom).
Though I question why you would use it over Elixir.
Go's syntax kind of blows, but it is so INCREDIBLY good at what it does, that you are not going to beat Go by just having better syntax and being "infinitely scalable" by default.
In practice, Go is easily scalable enough for almost anyone. If it isn't congrats, you're a $10B+ company. You can afford to rearchitect and optimize your hot paths.
I would look at benchmarks for Erlang and Elixir to get a rough idea of how Gleam performs at runtime. It's faster than Python generally, but not by a lot. It's for this reason that I really wish Gleam had a LLVM or Golang backend instead of JS / BEAM.
Glean is interesting from language nerd point of view, however I never had a reason to use Erlang at work, and probably never will, and I suspect that relates to most folks.
It’s funny how we avoid the technologies we can’t complain about much. Seeing an Elixir projects on production I always wonder „why we are not using it more often”. More talking about Elixir here.
For Elixir I saw a simple distributed job scheduler - it was dead simple in code and was ripped, because it didn’t require maintenance for ~8 years just working without issue and people who knew anything about it left company or switched part of company and acted as they forgot everything.
The other example is medium sized (in terms of features and code) web app - maintained by <30 people now, delivering more than 800 people at the other company, no stress, no issues and with great DX because of the BEAM (other company is drowning in JVM based nano-services).
I think the problem is that there is Erlang, the syntax, then Erlang, the features, and then there's OTP. It's a bit much all in one if you might have not done FP before, and then only with C-like syntax languages (e.g. Java).
When I joined an Erlang project I also had some aha moments with the syntax and how stuff is structured, and I found Elixir much nicer to work with (without any real Ruby experience). I don't want to say Erlang is not modern enough, but some things felt like they were around half the work (and more enjoyable) with some Elixir libraries (vastly bigger ecosystem than pure Erlang), for example handling XML.
It might be a bit simplistic, but I don't think you really lose anything meaningful when using Gleam or Elixir over pure Erlang. Just like you don't lose anything when using Clojure or Kotlin over pure Java.
I suspect you've also had zero reason to use the vast majority of programming languages at work in any meaningful capacity outside of the normal top ones. That's normally how tech decisions work. That certainly doesn't negate the possible benefits of other languages.
Others use Erlang and Elixir quite effectively and successfully in several billion dollar businesses apart from nerd aspects. It will be interesting to me personally if Gleam also has its day in the sun.
I'm now working on a real world legacy Elixir project in my day job and man oh man do I miss well defined types. Coming from Go, it makes a huge difference to my productivity when I'm able to click through fields and find usages of things, which comes down to the excellence of the Go language server. I know that the Elixir language server can infer some of this, but the language server in my experience is very fickle and flat out doesn't work if you have an older Elixir project.
I'm paying keen attention to Gleam to see if it can provide a robust development experience in this way, in the longer term.
Do the big updates to Elixir's type system help at all? afaik the most recent update added a huge amount of coverage that should extend to older code automatically.
I don't want to go into details of my work project too much, but the fundamental issue is that ElixirLS only supports 1.12+ (at least last time I checked).
Well. Coming from TS, Gleam just wasn't/isn't my jam. It's a nice programming language research project, but it just goes against the grain for me a little too much. All the made-up rules early returning always being weird `use` call, the type boilerplate—no inline object types as I remember. Lot of inventions that just makes me go "why?" Like the opposite ideology of Go. And yes I've used Haskell before (didn't like it) and Rust (kinda like it) and others in smaller quantity.
I am more excited about making things rather than fetishizing about some language paradigms so, I acknowledge that Gleam just isn't for me. I did give me the insight that for me, it might be the best to stick with the common denominator languages for the foreseeable future.
I have worked extensively on Elixir in the past and had a decent enough time, some warts aside. How different is programming in Gleam in the day-to-day apart from type safety?
lol - I had the temerity to raise the "how about a new logo" topic last week and it's going to time time for me to (hopefully) convince the community of the need to let go
I love coding in Raku - and I am sure that Gleam is nice too. But I get the feeling that Raku is underappreciated / dismissed by many due to the perl5 / perl6 history. So my thinking is, when I see a new language showcase an example on their website, presumably a carefully chosen snippet that showcases their language at its best, I like to see how Raku compares to that.
You know the take-aways from the comparison are quite instructive:
- do I need to import the io lib? (shouldn't this just be included)
- do I need a main() in every script? (does this rule out one liners like `> raku -e "say 'hi'"`)
- is `io.println` quite an awkward way to spell `print`?
I am not making the case that these are right or wrong language design decisions, but I do think that they are instructive of the goals of the designers. In the case of raku its "batteries included" and a push for "baby raku" to be as gentle on new coders as eg. Python.
The differences you mentioned are advantageous for Gleam depending on what you want. Like, having to namespace symbols instead of implicitly importing symbols makes it explicit where things come from which is good. Needing main, same thing. But the big differences are that Gleam is both functional, so everything is immutable, and fully typed safe. Completely the opposite of Perl/Haku so comparing these languages makes zero sense. If you don’t need types or functional programming you probably would just never use Gleam.
I think comparing 'printing hello world' programs isn't particularly useful, except that from how you describe it, Raku sounds more like a scripting language, which Gleam is not.
In comparison with Gleam, I would be more interested to see how good Raku is at helping the programmer prevent errors through static analysis, how easy it is to build with concurrency, how much value the language puts into being easy to understand and reason about, and whether it can run on the server as well as compile to JS.
I have no negative predisposition, I don't really care about the history of pearl or whatever, I have looked at Raku before but I find the syntax very foreign, and the fact that it seems to (maybe optionally?) incorporate glyphs that I can't easily type with a keyboard.
I love the butterfly though, so I'd love to get to know the language more.
role Fish { has Str $.name }
class Starfish does Fish { has Str $.favourite-colour; }
class Jellyfish does Fish { has Bool $.jiggly }
sub handle-fish(Fish $fish) {
given $fish {
when Starfish { say .favourite-colour }
when Jellyfish { say .name }
}
}
handle-fish Starfish.new: :name("Lucy"), :favourite-colour("Pink");
I would probably reach for multi-dispatch...
role Fish { has Str $.name }
class Starfish does Fish { has Str $.favourite-colour; }
class Jellyfish does Fish { has Bool $.jiggly }
multi sub handle-fish(Starfish $fish) { say $fish.favourite-colour }
multi sub handle-fish(Jellyfish $fish) { say $fish.name }
handle-fish Starfish.new: :name("Lucy"), :favourite-colour("Pink");
Here's the other Gleam concurrency example in Raku for good measure:
my @promises;
sub MAIN() {
# Run loads of green threads, no problem
for ^200_000 {
spawn-greeter($++);
}
await Promise.allof(@promises);
}
sub spawn-greeter($i) {
@promises.push: start {
say "Hello from $i";
}
}
Now here's a type-safe functional programming language I recently bumped into, which with their focus on simplicity, ease of use, and developer experience, and compiling to either Erlang or Javascript, is really tempting to delve in deeper.
Coming from Elixir, I gave Gleam a try for a couple of days over the holidays. Reasons I decided not to pursue:
- No ad-hoc polymorphism (apart from function overloading IIRC) means no standard way of defining how things work. There are not many conventions yet in place so you won’t know if your library supports eg JSON deserialization for its types
- Coupled with a lack of macros, this means you have to implement even most basic functionality like JSON (de)serialization yourself - even for stdlib and most popular libs’ structs
- When looking on how to access the file system, I learned the stdlib does not provide fs access as the API couldn’t be shared between the JS and Erlang targets. The most popular fs package for erlang target didn’t look of high quality at all. Something so basic and important.
- This made me realise that in contrast to elixir which not only runs on the BEAM („Erlang“) but also runs with seamless Erlang interop, Gleam doesn’t have access to most of the Erlang / Elixir ecosystem out of the box.
There are many things I liked, like the algebraic data types, the Result and Option types, pattern matching with destructuring. Which made me realize what I really want is Rust. My ways lead to Rust, I guess.
> Gleam doesn’t have access to most of the Erlang / Elixir ecosystem out of the box.
Gleam has access to the entire ecosystem out of the box, because all languages on the BEAM interoperate with one another. For example, here's a function inside the module for gleam_otp's static supervisor:
As another example, I chose a package[0] at random that implements bindings to the Elixir package blake2[1]. It's ok if you don't vibe with Gleam – no ad-hoc poly and no macros are usually dealbreakers for certain types of developer – but it's wrong to say you can't lean on the wider BEAM ecosystem![0]: https://github.com/sisou/nimiq_gleam/blob/main/gblake2/src/g...
[1]: https://hex.pm/packages/blake2
Isn’t this the proof of my point - How does the need of writing „@external“ annotations by hand not contradict the point of being „out of the box“ usable?
Hayleigh, when I asked on the discord about how to solve my JSON problem in order to get structured logging working, you replied that I’m the first one to ask about this.
Now reading this: > It's ok if you don't vibe with Gleam – no ad-hoc poly and no macros are usually dealbreakers for certain types of developer
Certainly makes me even more feel like gatekeeping.
I don't think Hayleigh was trying to gatekeep, just noting that some developers prefer features that Gleam intentionally omits.
As for the @external annotations, I think you're both right to a degree. Perhaps we can all agree to say: Gleam can use most libraries from Erlang/Elixir, but requires some minimal type-annotated FFI bindings to do so (otherwise it couldn't claim to be a type-safe language).
How does it contradict it? Without any modification/installation you can interop with Erlang/Javascript. How is that not out of the box usability of the Erlang/JS ecosystem? Syntax isn't as seamless as Elixir, but we need a way to tell Gleam what types are being passed around.
Why do you feel like a gatekeeper? Your opinion is valid, it's just that the interop statement was wrong.
That's FFI bindings. I need to provide the function signature of every API, because Erlang isn't statically typed. It's okay if some library provides it (like the linked , but I don't want to write this by hand if I can avoid it. And it's definitely not out of box, someone has to write the bindings for it to work
It would be different if I didn't have to write bindings and Gleam integrated automatically with foreign APIs. For Erlang that's probably not possible, but for the Javascript ecosystem it could make use of Typescript signatures maybe. (it would be very hard though)
Yeah, it's there out of the box but it's certainly not seamless. For an Elixir dev, it is more friction than you're used to. It is the cost of static types.
This is the same as Elixir, you need to specify what Erlang function to use in that language if you want to use Erlang code. The only difference is that Gleam has a more verbose syntax for it.
In Elixir you just call the Erlang function directly. It's basically the same as calling an Elixir function, just with a different naming convention.
In Gleam, you first have to declare the function type and THEN you can call the function directly.
This is probably the lightest way you can bridge between statically and dynamically typed languages, but it's not the same as Elixir.
Sorry, I've been unclear.
The runtime behaviour and cost of calling an Erlang function is the same in Elixir and Gleam, however the syntax is more verbose in Gleam as it asks for type information, while in Elixir this is optional.
I'm a bit torn on ad-hoc polymorphism. You can definitely do cool things with it. But, as others have pointed out, it does reduce type safety:
https://cs-syd.eu/posts/2023-08-25-ad-hoc-polymorphism-erode...
The same point holds of interfaces. And it’s not clear what the alternative is. No type system I’m aware of would force you to change all occurrences of this business logic pattern, with or without ad hoc polymorphism.
But at least ad hoc polymorphism lets you search for all instances of that business logic easily.
ML languages have a "types, modules, types-of-modules, and functors" approach to ad-hoc poly. It's a bit strange compared to what other languages do. I am wondering whether it's ever been seen outside of SML and OCaml.
For JSON deserialisation, you would declare a module-type called "JSON-deserialiser", and you would define a bunch of modules of that module-type.
The unusual thing is that a JSON-deserialiser would no longer be tied to a type (read: type, not module-type). Types in ML-like languages don't have any structure at all. I suppose you can now define many different JSON-serialisers for the same type?
The article provides a contrived example and doesn't prove that ad-hoc polymorphism reduces type-safety. Even when `Maybe [a]` is being folded via `Foldable f` the claimed type-safety isn't reduced, it's the context of the folding that's being changed from `[a]` to `Maybe a`, and everything is type-safe. Secondly, if you really want to distinguish between the empty list and disabled allow-lists within your type-system you do define your own data type with that representation, and you don't declare it foldable, because the folding algebra doesn't make sense for any practical use-case of the disabled allow-lists. The language actually provides you with the means to reduce evaluation contexts your types can be part of.
I’ve been doing Elixir for 9 years, 5 professionally. Nobody cares about ad-hoc polymorphism. The community doesn’t use protocols except “for data”. Whatever that means. Global singleton processes everywhere. I’m really discouraged by the practices I observe but it’s the most enjoyable language for me still.
>I’ve been doing Elixir for 9 years, 5 professionally. Nobody cares about ad-hoc polymorphism.
That’s true for Elixir as practiced, but it’s the wrong conclusion for Gleam.
Elixir doesn’t care about ad-hoc polymorphism because in Elixir it’s a runtime convention, not a compile-time guarantee. Protocols don’t give you universal quantification, exhaustiveness, coherence, or refactoring safety. Missing cases become production crashes, not compiler errors. So teams sensibly avoid building architecture on top of them.
In a statically typed language, ad-hoc polymorphism is a different beast entirely. It’s one of the primary ways you encode abstraction safely. The compiler enforces that implementations exist, pushes back on missing cases, and lets you refactor without widening everything into explicit pattern matches.
That’s exactly why people who like static types do care about it.
Pointing to Elixir community norms and concluding “nobody cares” is mixing up ecosystem habits with language design. Elixir doesn’t reward those abstractions, so people don’t use them. Gleam is explicitly targeting people who want the compiler to carry more of the burden.
If Gleam is “Elixir with types,” fine, lack of ad-hoc polymorphism is consistent. If it’s “a serious statically typed language on the BEAM,” then the absence is a real limitation, not bikeshedding.
Static types aren’t about catching typos. They’re about moving failure from runtime to compile time. Ad-hoc polymorphism is one of the main tools for doing that without collapsing everything into concrete types.
That’s why the criticism exists, regardless of how Elixir codebases look today.
Well, for the specific example I gave (JSON serialization), you certainly do care whether Jason.Encoder is implemented for a struct.
Yes, I just ranted, sorry. I share your view about Gleam.
IMHO this is an education problem.
Problem which plagues 90% of the people? How to overcome it?
It's an education problem on two fronts. People inside the ecosystem need to know about it. And also people too deep in the elixir ecosystem who don't know how ad-hoc polymorphism is supposed to be used in a statically typed language.
Both overcome it by admitting they don't know and need to learn.
I’m trying Gleam out right now, and having most recently been writing Go, I’m really loving: - No nil, instead Option and Result - ADTs - Pattern matching + destructuring - Immutable everything by default - `use` syntactic sugar (weird at first, but once you’re used to it it’s pretty elegant) - LSP server works great for such a young language
But most of all I think the overall simplicity of the language is really what’s standing out to me. So far I think the lack of ad-hoc poly and macros are a plus - it really reduces the impulse to write “magical” code, or code with lots of indirections. In the past I’ve definitely been guilty of over-abstracting things, and I’m really trying to keep things as simple as possible now. Though I’ve yet to try Gleam with a large project - maybe I’ll miss the abstractions as project complexity increases.
I suspect Gleam will be a great language for small to medium sized projects written with LLM assistance (NOT vibecoded) - the small language, strong typing and immutability gives good guardrails for LLM-generated code, and encourages a simple, direct style of programming where a human programmer can keep the whole structure in their head. Letting an LLM run free and not understanding what it’s written is I think where projects run into big problems.
The use <- syntax is even more crazy when you realize that it's a programmer-friendly way of doing continuation-passing style.
In a language that is otherwise as simple as it could possibly get away with (no `if`!), `use <-` initially feels like magic and somewhat out of place.
But take look at nested callback code, the pyramid of doom, and you see why it's pragmatically necessary. It's a brilliant design that incorporates just enough metaprogramming magic to make it ergonomic. The LSP even lets you convert back and forth between nested callback style and `use`, so you can strip away the magic in one code action if you need to unravel it.
I prefer kotlins trailing lambdas, which do mostly the same. But the way they are written allows code to almost look like JSON/some declarative DSL.
But use is nicer to avoid callback hell and all the indentations/scoping.
I am in love with Gleam! As a young computer science student, I found that Gleam brought back the joy of programming just when I felt like I was seriously burning out. I was never a fan of functional programming languages. I had tried other BEAM languages like Elixir and Erlang before, but Gleam is the one I’ve enjoyed the most :)
Have you tried F#? That usually gets a lot of praise in FP discussions.
F# seem to be in abandon-ware state the creator of F# moved to another job as his primary work the forum and community are very dry
Nothing interesting being created in F#
As much as I had high hopes for F# I think its safe at this point, to not pursuit it any further
.Net is C#
If you want an Ocaml like language, that is not Ocaml, your best bet is Rescript and that being said, Rescript is probably more of a competitor to gleam, since gleam also have javascript as a target
The language is still ahead of C#, and still receiving features and keeping up by and large with the .NET ecosystem. Tbh I don't get the sheer negativity; the same thing could be said for Gleam or any other functional language these days tbh especially with AI coming along w.r.t long term support. Eventually things just work and are mostly complete; things don't have to get reinvented or get better forever.
> As much as I had high hopes for F# I think its safe at this point, to not pursuit it any further
I find this attitude interesting; you wanted it to be more than it was. I don't have high hopes for any language; other than it building my software which it and many others can do. Right tool for right job. I'm not attached to my code, other than if it can be maintained, changed, has sane defaults/guardrails to introduce less defects, etc. F# can do this, as many others. Interestingly I've seen the same attitude eventually happen to all languages of this class other than Rust; Scala, OCaml, etc are in similar positions.
Funnily enough Opus/CC has a number of times for my projects has suggested Rust, and if that doesn't work (too much for the team) went F# even over Java based langs assuming domain modelling code and the need for more perf (e.g. value types, and other stuff) without explicit prompting. Its then generated fsx scripts to run experiments, etc that seem to be more reliable than the default Python ones it runs (package errors and static typing fixes mostly). `dotnet fsi` fits well into the agentic workflow.
> Rescript and that being said, Rescript is probably more of a competitor to gleam
Depends on your target. F# at least has a backdoor into the C# ecosystem - from a risk perspective that makes it more palatable. New languages have an initial "excitement" about them; but generally they are just tools.
Pick something that fits your team and build. F# does work, and so do many other tools. In the age of AI IMO the ecosystem and guardrails for the AI matter more than the language and its syntax IMO other than readability. In this regard F# still is "less risky" with its .NET interop.
Wake up and smell the coffee: fsharp is dead. Look at the release notes of fsharp. It's laughable for a major version update. It's maintained by like 5 people working in eastern Europe and they only do maintenance updates basically. C# is getting all its features and DotNet is basically c# oriented anyway. So even in the past you had to learn C# to program in F#
I would assert that Microsoft's management always behaved as if they repented to have added F# to VS 2010, with all the maintenance guarantees it implies, throughout the years they have searched how to sell it.
Nowadays CLR has effectively changed meaning to C# Language Runtime, and ironically the JVM is more lively as the original goal of the CLR back in 2001.
I'd rather them stick with ONE: JS or BEAM. Everytime a project claims it can do multiple things at once, it can't do either very well.
It's confusing too. Is Gleam suitable for distributed computing like Elixir/Erlang on BEAM? Would that answer change if I compile it to JS?
My “intro to gleam” was a lustre form for my blog, where people could submit feedback. So I was able to create a neatly separated client module in Gleam and compile it to JavaScript so I can insert it in my static blog page. The server part was a separate gleam module with erlang as a target. They shared models and some constants with a “shared” module - just like the tutorial.
I find this kind of explicit separation very powerful. It also removes some of the anxiety if something will end up in a client bundle when it’s supposed to be server only.
How is it hosted if you don't mind saying
I've used gleam for a toy project in uni, and AoC
My main friction point is that the Int type maps to different concepts in erlang and js
In erlang it's a arbitrary precision Int
In js it the js number type, which is a 64bit float iirc.
Also recursion can hit limits way sooner in js.
For me, my code rarely ran in both js and erlang. But could be skillissue
Fair, but you usually don't run your project on both, unless you're writing a library.
Pick the target that makes sense for your project and stick with it :)
JS/TS isn't my favourite language, but it's pretty decent these days. If I'm picking a different language and targeting the web, it's probably because I want to run the same code natively as well.
Gleam is technically as suitable for distributed computing as Erlang: since it compiles to Erlang, it can do anything that Erlang can. You can use Erlang and Elixir libraries and write FFI code to do things that would be unergonomic to do in Gleam. Sure the experience is different and if you want to embrace the guarantees of static typing, then the APIs will look different, like gleam_otp.
If you compile it to JS, then the guarantees change to JS's guarantees.
Personally I've felt that the JS target is a big plus and hasn't detracted from Gleam. Writing a full stack app with both sides being in Gleam and sharing common code is something I've enjoyed a lot. The most visible impact is that there's no target specific functions in the stdlib or the language itself, so Erlang related things are in gleam_erlang and gleam_otp, and e.g. filesystem access is a package instead of being in the stdlib. If you're just into Erlang, you don't need to interact with the JS target at all.
Same here, I've only been using it for a bit and have 100% been ignoring the JS part and the only time where I felt I needed to think about it for a moment was when I was writing a patch for someone else's code that did not ignore it, so basically when contributing to a library you might have to do extra work.
Of course I can't say if anyone ever made any decisions based on the other target that would have repercussions for me only using the BEAM.
I really like the idea of gleam but I don't want to hand implement serialization for every type (even with an LSP action) in 2026.
Biggest issue with this language. But... fairly trivial to implement codegen with gleam/glance[0]. No good libraries do this well right now (e.g. support for discriminated unions).
[0] https://hexdocs.pm/glance/glance.html
Indeed. Gleam is a sort-of mix between Elixir and Rust, yet you don't have to explicitly implement serialization for either of them.
It's definitely something they should figure out.
I rarely serialise every type in my gleam code, My quick back of the napkin math is less than 5%.
But 100 percent of projects writing the same stuff
I don't think anyone is serializing exactly the same stuff that i'm doing.
Dart has the same glaring issue (yes, yes, you can use a codegen library but it's not the same).
I remember playing with Alpaca a few years ago, and it was fun though I didn’t find the resulting code to significantly less error-prone than when I wrote regular Erlang. It’s inelegant, but I find that Erlang’s quasi-runtime-typing with pattern matching gets you pretty far and it falls into Erlang’s “let it crash” philosophy nicely.
Honestly, and I realize that this might get me a bit of flack here and that’s obviously fine, but I find type systems start losing utility with distributed applications. Ultimately everything being sent over the wire is just bits. The wire doesn’t care about monads or integers or characters or strings or functors, just 1’s and 0’s, and ultimately I feel like imposing a type system can often get in the way more than it helps. There’s so much weirdness and uncertainty associated with stuff going over the wire, and pretty types often don’t really capture that.
I haven’t tried Gleam yet, and I will give it a go, and it’s entirely possible it will change my opinion on this, so I am willing to have my mind changed.
I don’t understand this comment, yes everything going over the wire is bits, but both endpoints need to know how to interpret this data, right? Types are a great tool to do this. They can even drive the exact wire protocol, verification of both data and protocol version.
So it’s hard to see how types get in the way instead of being the ultimate toolset for shaping distributed communication protocols.
Bits get lost, if you don’t have protocol verification you get mismatched types.
Types naively used can fall apart pretty easily. Suppose you have some data being sent in three chunks. Suppose you get chunk 1 and chunk 3 but chunk 2 arrives corrupted for whatever reason. What do you do? Do you reject the entire object since it doesn’t conform to the type spec? Maybe you do, maybe you don’t, or maybe you structure the type around it to handle that.
But let’s dissect that last suggestion; suppose I do modify the type to encode that. Suddenly pretty much every field more or less just because Maybe/Optional. Once everything is Optional, you don’t really have a “type” anymore, you have a a runtime check of the type everywhere. This isn’t radically different than regular dynamic typing.
There are more elaborate type systems that do encode these things better like session types, and I should clarify that I don’t think that those get in the way. I just think that stuff like the C type system or HM type systems stop being useful, because these type systems don’t have the best way to encode the non-determinism of distributed stuff.
You can of course ameliorate this somewhat with higher level protocols like HTTP, and once you get to that level types do map pretty well and you should use them. I just have mixed feelings for low-level network stuff.
> But let’s dissect that last suggestion; suppose I do modify the type to encode that. Suddenly pretty much every field more or less just because Maybe/Optional. Once everything is Optional, you don’t really have a “type” anymore, you have a a runtime check of the type everywhere. This isn’t radically different than regular dynamic typing.
Of course it’s different. You have a type that accurately reflects your domain/data model. Doing that helps to ensure you know to implement the necessary runtime checks, correctly. It can also help you avoid implementing a lot of superfluous runtime checks for conditions you don’t expect to handle (and to treat those conditions as invariant violations instead).
No, it really isn’t that different. If I had a dynamic type system I would have to null check everything. If I have declare everything as a Maybe, I would have to null check everything.
For things that are invariants, that’s also trivial to check against with `if(!isValid(obj)) throw Error`.
Sure. The difference is that with a strong typing system, the compiler makes sure you write those checks. I know you know this, but that’s the confusion in this thread. For me too, I find static type systems give a lot more assurance in this way. Of course it breaks down if you assume the wrong type for the data coming in, but that’s unavoidable. At least you can contain the problem and ensure good error reports.
The point of a type system isn’t ever that you don’t have to check the things that make a value represent the type you intend to assign it. The point is to encode precisely the things that you need to be true for that assignment to succeed correctly. If everything is in fact modeled as an Option, then yes you have to check each thing for Some before accessing its value.
The type is a way to communicate (to the compiler, to other devs, to future you) that those are the expected invariants.
The check for invariants is trivial as you say. The value of types is in expressing what those invariants are in the first place.
You missed the entire point of the strong static typing.
I don’t think I did. I am one of the very few people who have had paying jobs doing Scala, Haskell, and F#. I have also had paying jobs doing Clojure and Erlang: dynamic languages commonly used for distributed apps.
I like HM type systems a lot. I’ve given talks on type systems, I was working on trying to extend type systems to deal with these particular problems in grad school. This isn’t meant to a statements on types entirely. I am arguing that most systems don’t encode for a lot of uncertainty that you find when going over the network.
You're conflating types with the encoding/decoding problem. Maybe your paying jobs didn't provide you with enough room to distinguish between these two problems. Types can be encoded optimally with a minimally-required bits representation (for instance: https://hackage.haskell.org/package/flat), or they can be encoded redundantly with all default/recovery/omission information, and what you actually do with that encoding on the wire in a distributed system with or without versioning is up to you and it doesn't depend on the specific type system of your language, but the strong type system offers you unmatched precision both at program boundaries where encoding happens, and in business logic. Once you've got that `Maybe a` you can (<$>) in exactly one place at the program's boundary, and then proceed as if your data has always been provided without omission. And then you can combine (<$>) with `Alternative f` to deal with your distributed systems' silly payloads in a versioned manner. What's your dynamic language's null-checking equivalent for it?
With all due respect, you can use all of those languages and their type systems without recognizing their value.
For ensuring bits don't get lost, you use protocols like TCP. For ensuring they don't silently flip on you, you use ECC.
Complaining that static types don't guard you against lost packets and bit flips is missing the point.
With all due respect, you really do not understand these protocols if you think “just use TCP and ECC” addresses my complaints.
Again, it’s not that I have an issue with static types “not protecting you”, I am saying that you have to encode for this uncertainty regardless of the language you use. The way you typically encode for that uncertainty is to use an algebraic data type like Maybe or Optional. Checking against a Maybe for every field ends up being the same checks you would be doing with a dynamic language.
I don’t really feel the need to list out my full resume, but I do think it is very likely that I understand type systems better than you do.
Fair enough, though I feel so entirely differently that your position baffles me.
Gleam is still new to me, but my experience writing parsers in Haskell and handling error cases succinctly through functors was such a pleasant departure from my experiences in languages that lack typeclasses, higher-kinded types, and the abstractions they allow.
The program flowed happily through my Eithers until it encountered an error, at which point that was raised with a nice summary.
Part of that was GHC extensions though they could easily be translated into boilerplate, and that only had to be done once per class.
Gleam will likely never live to that level of programmer joy; what excites me is that it’s trying to bring some of it to BEAM.
It’s more than likely your knowledge of type systems far exceeds mine—I’m frankly not the theory type. My love for them comes from having written code both ways, in C, Python, Lisp, and Haskell. Haskell’s types were such a boon, and it’s not the HM inference at all.
> ends up being the same checks you would be doing with a dynamic language
Sure thing. Unless dev forgets to do (some of) these checks, or some code downstream changes and upstream checks become gibberish or insufficient.
I know everyone says that this is a huge issue, and I am sure you can point to an example, but I haven’t found that types prevented a lot of issues like this any better than something like Erlang’s assertion-based system.
When you say "any better than" are you referring to the runtive vs comptime difference?
While I don't agree with the OP about type systems, I understand what they mean about erlang. When an erlang node joins a cluster, it can't make any assumptions about the other nodes, because there is no guarantee that the other nodes are running the same code. That's perfectly fine in erlang, and the language is written in a way that makes that situation possible to deal with (using pattern matching).
Interesting! I don't share that view at all — I mean, everything running locally is just bits too, right? Your CPU doesn't care about monads or integers or characters or strings or functors either. But ultimately your higher level code does expect data to conform to some invariants, whether you explicitly model them or not.
IMO the right approach is just to parse everything into a known type at the point of ingress, and from there you can just deal with your language's native data structures.
I know everything reduces to bits eventually, but modern CPUs and memory aren’t as “lossy” as the network is, meaning you can make more assumptions about the data being and staying intact (especially if you have ECC).
Once you add distribution you have to encode for the fact that the network is terrible.
You absolutely can parse at ingress, but then there are issues with that. If the data you got is 3/4 good, but one field is corrupted, do you reject everything? Sometimes, but often Probably not, network calls are too expensive, so you encode that into the type with a Maybe. But of course any field could be corrupt so you have to encode lots of fields as Maybes. Suddenly you have reinvented dynamic typing but it’s LARPing as a static type system.
I think you can avoid most issues by not doing what you're describing! Ensuring data arrives uncorrupted is usually not an application-level concern, and if you use something like TCP you get that functionality for free.
TCP helps but only to a certain extent; it only guarantees specific ordering of bits during its session. Suppose you have to construct an object out of three separate transmissions, like some kind of multipart style thing. If one of the transmissions gets corrupted or gets errors out from TCP, then you still fall into that maybe trap.
so you need transactions?
I get what your saying, but can't you have the same issue if instead you have 3 local threads that you need to get the objects from, one can throw an exception and you only receive 2, same problem
Sometimes, but I am arguing that you need to encode for this uncertainty if you want to make distributed apps work correctly. If you can do transactions for what you’re doing then great, not every app can do that.
When you have to deal with large amounts of uncertainty, static types often reduce to a bunch of optionals, forcing you to null check every field. This is what you end up having to do with dynamic typing as well.
I don’t think types buy you much in cases with extreme uncertainty, and I think they create noise as a result.
It’s a potentially similar issue with threads as well, especially if you’re not sharing data between them, which has similar issues as a distributed app.
A difference is that it’s much cheaper to do retries within a single process compared to doing it over a network, so if something gets borked locally then a retry is (comparatively) free.
> static types often reduce to a bunch of optionals, forcing you to null check every field
On one end, you write / generate / assume a deserialisator that checks whether incoming data satisfies all required invariants, eg all fields are present. On the other end, you specify a type that has all the required fields in required format.
If deserialisation fails to satisfy type requirements, it produces an error which you can handle by eg falling back to a different type, rejecting operation or re-requesting data.
If deserialisation doesn't fail – hooray, now you don't have to worry about uncertainty.
The important thing here is that uncertainty is contained in a very specific place. It's an uncertainty barrier, if you wish: before it there's raw data, after it it's either an error or valid data.
If you don't have a strict barrier like that – every place in the program has to deal with uncertainty.
So it's not necessarily about dynamic / static. It's about being able to set barriers that narrow down uncertainty, and growing number of assumptions. The good thing about ergonomic typing system is that it allows you to offload these assumptions from your mind by encoding them in the types and let compiler worry about it.
It's basically automatization of assumptions book keeping.
Why couldn't you fix this by validating at the point of ingress? If one of the three transmissions fails, retry and/or alert the user.
But your program HAS to have some invariants. If those are not held, simply reject all the data!
What the hell is really the alternative here? Do you just pretend your process can accept any kind of data, and just never do anything with it??
If you need an integer and you get a string, you just don't work. This has nothing to do with types. There's no solution here, it's just no thank you, error, panic, 500.
You handle that in the validation layer, like millions of people have done with dynamic languages in the past.
> Honestly, and I realize that this might get me a bit of flack here and that’s obviously fine, but I find type systems start losing utility with distributed applications. Ultimately everything being sent over the wire is just bits.
Actually Gleam somewhat shares this view, it doesn't pretend that you can do typesafe distributed message passing (and it doesn't fall into the decades-running trap of trying to solve this). Distributed computing in Gleam would involve handling dynamic messages the same way handling any other response from outside the system is done.
This is a bit more boilerplate-y but imo it's preferable to the other two options of pretending its type safe or not existing.
> handling dynamic messages
the dynamic messages have to have static properties to be relevant for the receiving program, the properties are known upfront, and there's no "decades-running trap of trying to solve this".
> there's no "decades-running trap of trying to solve this".
I’m not as certain. The fact that we’ve gone from ASN.1 to COBRA/SOAP to protobuf to Cap’n’web and all the million other items I didn’t list says something. The fact that, even given a very popular alternative in that list, or super tightly integrated RPC like sending terms between BEAMs, basic questions like “should optionality/absence be encoded differently than unset default values?” and “how should we encode forward compatibility?” have so may different and unsatisfactory answers says something.
Not as an appeal to authority or a blanket endorsement, but I think Fowler put it best: https://martinfowler.com/articles/distributed-objects-micros...
It absolutely is a decades old set of problems that have never been solved to the satisfaction of most users.
> I’m not as certain. The fact that we’ve gone from ASN.1 to COBRA/SOAP to protobuf to Cap’n’web and all the million other items I didn’t list says something.
> It absolutely is a decades old set of problems that have never been solved to the satisfaction of most users.
ASN.1 wasn't in the same problem space with CORBA/DCOM, both CORBA and DCOM/OLE were heavily invested in a general-purpose non-domain-specific object model representation that would suppot arbitrary embeddings within an open-ended range of software. I suspect this is the unsolvable problem indeed, but I also believe that's not what you meant with your comment either, since all the known large-scale BEAM deployments (the comment I originally replied to implied BEAM deployments) operate within bounded domain spaces such as telecom and messaging, where distributed properties of the systems are known upfront: there are existing formats, protocols of exchange, and the finite number of valid interactions between entities/actors of the network, the embeddings are either non-existent or limited to a finite set of media such as static images, videos, maps, contacts etc. All of these can be encoded by a compile-time specification that gets published for all parties upfront.
> basic questions like “should optionality/absence be encoded differently than unset default values?”
However you like, any monoid would work here. I would argue that [a] and [] always win over (Option a) and especially over (Option [a]).
> and “how should we encode forward compatibility?”
If you'd like to learn if there's a spec-driven typed way of achieving that, you can start your research from this sample implementation atop json: https://github.com/typeable/schematic?tab=readme-ov-file#mig...
Interesting. Them being honest about this stuff is a point in their favor.
I might give it a look this weekend.
You seem to have a fundamental misunderstanding about type systems. Most (the best?) typesystems are erased. This means they only have meaning "on compile time", and makes sure your code is sound and preferrably without UB.
The "its only bits" thing makes no sense in the world of types. In the end its machine code, that humans never (in practice) write or read.
I know, but a type system works by encoding what you want the data to do. Types are a metaphor, and their utility is only as good as how well the metaphor holds.
Within a single computer that’s easy because a single computer is generally well behaved and you’re not going to lose data and so yeah your type assumptions hold.
When you add distribution you cannot make as many assumptions, and as such you encode that into the type with a bunch of optionals. Once you have gotten everything into optionals, you’re effectively doing the same checks you’d be doing with a dynamic language everywhere anyway.
I feel like at that point, the types stop buying you very much, and your code doesn’t end up looking or acting significantly different than the equivalent dynamic code, and at that point I feel like the types are just noise.
I like HM type systems, I have written many applications in Haskell and Rust and F#, so it’s not like I think type systems are bad in general or anything. I just don’t think HM type systems encode this kind of uncertainty nicely.
> When you add distribution you cannot make as many assumptions
You absolutely can make all assumptions relevant to the handling/dispatching logic expressed at type-level.
> and as such you encode that into the type with a bunch of optionals.
Not necessarily, it can be `Alternative f` of non-optional compound types that define the further actions downstream.
> Once you have gotten everything into optionals, you’re effectively doing the same checks you’d be doing with a dynamic language everywhere anyway.
Not true, your business logic can be dispatched based on a single pattern comparison of the result of the `Alternative f`.
For a fairly advanced example project I can recommend looking at Quickslice, a dev toolkit for making AT protocol applications.
https://tangled.org/slices.network/quickslice
For anyone opening the link and wondering why the expected "gleam.toml" is missing: the project contains 2 Gleam sub-projects. The server/ directory is the BEAM server (no framework) and the client/ directory is the gleam-compiled-js client (lustre framework).
Unfortunately, there are many tests for the server, and none for the client.
One of the best things about erlang/elixir is the repl driven development/manual testing.
Gleam has no `interpreted` story, right? Something like clojure, common lisp, etc. I think this matters because debugging on beam is not THAT great, there are tools in erlang/elixir to facilitate debugging, like inspect() or dbg().
If anyone has experience in this language, what is the mindset with gleam? How you guys debug?
> If anyone has experience in this language, what is the mindset with gleam? How you guys debug?
There is the echo keyword now, which is comparable to elixir's dbg(), I use that a lot.
Lacking a REPL, what I normally do is make a dev module, like 'dev/playground.gleam' where I'm testing things out (this is something that the gleam compiler supports, /dev is similar to /test) and then run it with 'gleam run -m playground'.
Sometimes I also use the Erlang shell. You can get an Erlang shell with all the gleam modules from your project loaded in with the 'gleam shell' command. You just need to know the Erlang syntax, and how Gleam modules are named when compiled to Erlang (they use an '@' separator, so gleam/json becomes 'gleam@json').
Cool, thanks! I really like Erlang syntax, will try that in the afternoon.
You can use all the BEAM debuggers and tracing tools, and Gleam has a print debugging keyword.
Unfortunately there is not yet a plugin for the BEAM debuggers for them to use Gleam syntax.
Gleam is nice. However it is still very lacking in the stdlib. You will need lots of dependencies to build something usable. I kind of wish Gleam could target something like Go, then you would have the option to go native without a "heavy" VM like the BEAM.
Surely the BEAM is one of the major selling points.
Not for executables. Not everything needs an runtime.
In a world with package management there’s no practical difference between the core modules being in one package or multiple packages.
[dead]
A recent post about using Gleam for Advent of Code:
https://news.ycombinator.com/item?id=46255991
I still suspect the effectiveness of plugging in a type system patch to a complete system, like typescript to javascript. We still observe so many `as any` or `as unknown as` at every corner.
Despite of the suspicion, Gleam provides a better and elegant syntax for those who are not familiar with Erlang or functional programming languages, which I loved most.
There’s no “unknown” or “any” in Gleam, it’s not possible to cheat the type system that way
That doesn’t really apply to Gleam, it’s not a type syntax for another language that can be stripped, it’s its own language that compiles to Erlang and JS
One of programming languages with political agenda.
The type of people complaining about this are usually the people you don't want in your community to begin with, so I doubt Gleam is missing out here.
Or the contrary, the kind of people finding this cool is usually the people you don't want in your community. Nice to have clarity about who doesn't want to even bother to deal with whom.
[dead]
This is a perfect example of what your club understands as "friendly" and "inviting".
It always ends the same way, always.
Since when not being an asshole is a political agenda?
This is a terrible take. Just because your personal opinions / morals / values don't align with others in a community, doesn't automatically make you an asshole. If people can't handle others having differing opinions, they have some growing up to do and shouldn't be leading a community.
When one of those “differing opinions” is “you should be oppressed”, then yeah, that kind of does automatically make someone an asshole.
Someone not being a BLM supporter, doesn't equate to them holding the opinion that anyone should be oppressed. Only someone who views everything through a binary lens / is trapped in dualistic thinking, would suggest such a thing. One shouldn't automatically claim someone else is an asshole for not agreeing to think the exact same way they do.
It didn't say BLM supporter. It says black lives matter. If you take offence to that, that's a you problem
[dead]
human rights are not politics
Every "right" is politics.
A set of "rights" comes from current law.
And Code of Law is an invention like everything else.
let me clarify the intent of my comment then. Human rights is not a "two-sides" issue to be debated. If you attempt to reduce an affirmation of human rights for all people to a "political agenda", I will call out your conservative dogwhistle. I don't care how that's received.
red flag for future drama that might cause problems, one of the reasons I walked away
[dead]
All open source projects are political by their very nature.
But not every open source project has a political agenda.
All open source projects have a political agenda. That's the purpose of the licence, to force certain behaviour.
Behavior related to the project maybe, but not behavior how should users behave every day in areas that are completely unrelated.
"You are welcome to our community only if your hair is long and you drive a yellow car, if you're not then you're not welcome." is pretty insane IMO.
How is it insane to only welcome people to a community that act respectful towards other people? That seems like a really good way to build a solid community.
That's not the case with the Gleam community though. Unless you're willing to adopt their opinions / values / moral stance on certain issues, you won't be treated respectfully - you will be ostracized for having an unpopular opinion or view on a given issue.
It is a totally insane way to run a project, and it's quite obvious the Gleam community is run by persons who are unable to handle people with opinions that differ from their own.
It does sound like a great way to build an echo chamber.
Unpopular opinion like... being racist?
Ah yes, because not automatically supporting grifts like the BLM movement (which enriched the founders and did very little for the black community at large), makes someone a racist - I totally forgot!
Black Lives Matter is objectively not a grift. There is an argument to be made regarding "BLM Global Network", but calling them BLM is like saying all vegans support PETA.
Regardless, that's irrelevant to the discussion at hand. You don't have to change your beliefs to be part of the Gleam community, you just have to not be an asshole about them. If you're the kind of person that starts an argument any time BLM is mentioned, is it understandable why they wouldn't want you in their community?
> Black Lives Matter is objectively not a grift.
There we go again. I think that you people would gain if you'd read what does it mean if something is objective and also the meaning of "subjective". Either you live in social bubbles or you're intentionally ignoring anything that's not in line with your ideology. I'm actually not surprised this is the case, since you're not allowing people outside of your bubbles in your community spaces. You cherish diversity, yet in reality you're the most ideologically closed social group that I know. Letting people in only if it's easy for you is very far from "welcoming".
You're accusing the parent of being an asshole, yet you dismiss his arguments based on false "objectivity". And because of your "objectivity", which is clearly subjective, you reinforce the argument that parent is not welcome in your community. How is this welcoming?
I mean I know the answer.
I explicitly did not call them an asshole, it was very much conditional on the way they choose to act inside these communities.
Regarding your accusation of subjectivity, I was addressing the misnomer that BLMGN is equivalent to the BLM movement - it's not. BLMGN might be a grift for all I know, but that cannot be used to call the entire BLM movement a grift. By definition a grifter is aware that they're grifting, do you believe that every BLM protest was organised by someone looking to make a profit? If not, BLM is objectively not a grift.
On the topic of being 'welcoming', clearly you don't understand the paradox of tolerance. Is it intolerant to exclude Nazis from a community? Obviously not, despite what the Nazis would claim, because Nazis make the communities they're involved in intolerable to anyone that's not a Nazi.
Thus, if you want to create an inclusive community, you have no choice but to exclude certain groups of people.
It's actually pretty simple to figure out which groups should be excluded: - Transphobes are constantly imposing their beliefs on trans people, trans people want equal rights. - White supremacists are constantly imposing their beliefs on black people, black people want equal rights. - Homophobes are constantly imposing their beliefs on gay people, gay people want equal rights. Do I need to continue?
To be clear, I barely interact with these "safe" communities - pretty much only when I need some help with my code. It's very easy to hide your beliefs if you want to participate, I could be a raging homophobe for all they know because I've never talked about gay people in there.
You say the they don't tolerate anyone outside their bubbles, but anyone is free to join and start getting support, there's no purity test. So do you mean they don't tolerate people questioning trans rights in a support channel? Because obviously they don't. If you want to start an argument there are plenty of appropriate places to do so, places that don't make people feel unsafe.
> Transphobes are constantly imposing their beliefs on trans people, trans people want equal rights
What happens if you don't use the correct pronouns someone has declared for themselves?
Is this not "imposing beliefs" on other people?
This goes far beyond "tolerance": you must be an active, enthusiastic participant or face punishment.
> It's very easy to hide your beliefs if you want to participate
That's the point: only one set of ideas are allowed, everyone else must hide, regardless of forum.
> anyone is free to join and start getting support
Try espousing ideals contrary to theirs in completely unrelated venues and see how much support you get sans anonymity.
> places that don't make people feel unsafe.
"Feeling unsafe" is an outstanding weapon to crush behavior one doesn't like. Doesn't even require logic: it's literally a feeling.
> What happens if you don't use the correct pronouns someone has declared for themselves? Is this not "imposing beliefs" on other people?
That's a false equivalence. All that's asked of you is to not misgender or deadname them, whereas transphobes are actively making it impossible for trans people to freely live as themselves.
It's also about not being a dickhead. If you met an autistic kid, and were told that he becomes incredibly distressed if you don't refer to him as 'Mr.', would you at least make an effort to call him that? It doesn't matter how ridiculous you think calling a kid 'Mr.' is, he isn't imposing his beliefs on you by asking that of you. If someone decides that their community will be a safe place for the kid to be, then of course they're justified in removing you if you refuse to call him 'Mr'.
Regardless of whether you believe trans people are mentally ill or just a normal part of humanity, not misgendering them is a simple courtesy to avoid causing a fellow human distress.
> "Feeling unsafe" is an outstanding weapon to crush behavior one doesn't like. Doesn't even require logic: it's literally a feeling.
How is this relevant to a programming language community? Who, in your scenario, is doing the crushing?
> not misgender or deadname them
In other words: be an active, enthusiastic participant in someone's beliefs regardless of your own.
> How is this relevant to a programming language community?
Easy example: "I feel unsafe because DHH doesn't like that his country has been overrun by immigrants, he must be removed!"
For the sake of simplicity, and to detach our feelings from this subject, let's assume that Ω-GN is a grift. Ω is a superset of Ω-GN. We cannot conclude that Ω is a grift solely because a subset (Ω-GN) is a grift. However, can we objectively say that Ω is not a grift just because there are some instances within Ω that are not grifts? Clearly, there are also instances within Ω that are grifts, since Ω-GN (a subset of Ω) is a grift by our assumption. Therefore, the existence of both grift and non-grift instances in Ω means we cannot categorically label Ω as either a grift or not a grift based solely on its subsets.
Yet you say that objectively it's not a grift because there is at least 1 instance of a non-grifting event in Ω. Even Kenneth Copeland _sometimes_ is right about _something_, can we say that objectively he's not a liar because _there was at least 1 instance of him telling the truth_? I think not.
Also, you people use this word, "nazi", but do you actually know what are Nazis? German National-Socialists. Even the name "NAZI" is taken from German language. So if you ask me "what is wrong with disliking nazis", yet you use some artificial and historically wrong definition of a nazi, then I'm telling you that the problem is with you people using "nazis" for others who disagrees with you. I probably am a Nazi in someone's eyes, because I'm opposed to trans-women participating in women's sports. In reality, my grandfather fought with the actual nazis which existed in real world, not in your imagination.
> Thus, if you want to create an inclusive community, you have no choice but to exclude certain groups of people.
Yeah, this is how I understand it as well. People want easy inclusivity, a mono-themed style of thinking, and diversity only within their own strictly defined boundaries. I interpret this as a contradiction and a lie: diversity among selected groups is not true diversity, and inclusivity limited to chosen pools is not genuine inclusivity. For me there is absolutely no difference between this and a situation where whites stick to whites, blacks stick to blacks, etc.
If something is marked as "LGBTQ+ friendly" then I'm all fine -- it's very understandable and I know what I'm dealing with. But if something is "inclusive" then I automatically know I'm not in the target audience, because the sole definition of "include" is already loaded. The language already contains words with different meanings. For me this means "we're so closed, we even use our own definition of 'inclusion' to not think about the outside world".
You seem quite passionate about this, which I find difficult to understand, maybe because I’m not as deeply immersed in American political culture as you (I had no idea people see BLM as an organisation rather than a movement / ethical stance) but I’m curious: Is it really just about language for you?
If the section was phrased as “We are LGBTQ+ friendly and do not tolerate transphobia or racism” that would feel more welcoming to you?
At the end of the day, it’s a programming language community. If you join and ask a question about how to call functions from Erlang, you’ll definitely get an answer. If you join and bring up your feelings about trans women in sports you’ll most likely be asked to stop or removed, as it’s just not a space where that kind of discussion is welcome.
But why should it be?
> If the section was phrased as “We are LGBTQ+ friendly and do not tolerate transphobia or racism” that would feel more welcoming to you?
It's very, very easy to turn ideas into "racism" or "transphobia."
> it’s just not a space where that kind of discussion is welcome
These folks believe no space exists where this type of discussion is welcome and will deny participation to anyone not towing the party line in all forums - not just their little fiefdom.
It's not American, it's global. I'm not American, yet I'm judged by the these political culture quirks. The creator of Gleam is not American, he's from UK. Trans-movements aren't American, they're in my country too, and I'm interested somewhat in the politics of my own country. Also parent posts differentiated between BLM and BLM-GN, where one is a "movement", and the other one is supposedly a marxist organization, so I guess there's a difference too.
> Is it really just about language for you?
No. I mean, I'm not a murderer. I'm not a thief. I only do to others what I want others to do to me. I don't want to be treated differently because of my race or my gender, therefore I don't want to treat others differently because of those things. Yet, I actually am treated differently because of it; and it's mostly by those people who "fight racism" and "fight transphobia". Who are virtue signalling left and right how tolerant they are. How inclusive they are. When a black director says "I'll never hire a white main actor" then it's OK. But when I point out he said it, then I'm a racist -- this is how it works today. So:
> If the section was phrased as “We are LGBTQ+ friendly and do not tolerate transphobia or racism” that would feel more welcoming to you?
No, because it's too easy to frame my views as transphobic or racist, like I've written in my previous paragraph. And this is the language part. Using "master" branch in git today is a manifestation of racism. People fork "rubocop" projects because it has a "cop" in the name; and they want to defund the police. I think that police is needed because without it the law wouldn't exist? Then I'm a nazi. When I'm asking questions about whether someone's wheels were spinning during sudden acceleration, I'm being called an ICE-lover.
You might see me being passionate, but I'm merely a product of current political polarity.
> If you join and bring up your feelings about trans women in sports you’ll most likely be asked to stop or removed, as it’s just not a space where that kind of discussion is welcome. But why should it be?
No, I will be removed only when I say that it's not OK. I will be upvoted when I'll say that it's OK. But more generally, that's a good question, but I don't know the answer, ask Ipil, he sees the necessity. I do think that there's no reason why it should be a place for discussion of trans-rights and racism and I wouldn't want to discuss it there (not even here to be honest). So why it's being manifested on the main page, before the language tour and before the newsletter, since it's clearly not a place for these topics?
I used 'Nazi' in reference to the series of tweets about a polite Nazi. (Forgive the Reddit link) https://www.reddit.com/r/TalesFromYourServer/comments/hsiisw...
Take it to mean a literal straight out of 1942 National Socialist if you like, it doesn't change what I was trying to convey.
If you want a historical comparison to BLM, how about the suffragettes. I can guarantee that there were grifters looking to make money off the movement, which would be a subset of it, but I think it's quite fair to say the suffragettes were objectively not grifters.
I would also say that Christianity is objectively not a grift, despite the fact that there are many grifters within the faith. If the core ideas of a movement are spread by people that truly believe in them, and are not controlled by any individual, then how exactly could it qualify as a grift?
Legitimately, I don't understand how a decentralised set of ideas could be a grift. Do you have any examples?
"Diversity only within their own strictly defined boundaries" is exactly right, but you don't seem to understand that those boundaries are what let's diversity thrive. Without rules against bigotry, LGBTQ+ people are far less able to express themselves due to the increased scrutiny from people that refuse to accept them.
When there are people in a community that denegrate others for being themselves it creates a toxic environment where being different makes you a target, so everyone either falls in line or leaves.
It's really funny, because that's how I portray inclusive people. They're nice until they bring friends. And later friends require changing the vocabulary and I don't even know how to communicate with them. But I'm not calling them soviets.
I've literally said in my previous message that in my opinion it can't be said that BLM is a grift, and can't be said that it is not a grift. It's not even about a grift, it's about objective statements.
I guess we have to agree to disagree, since it's apparent we're not even reading ourselves properly.
By the way, one date of importance when it comes to nazism for me is 1st September 1939. German nazis marked a whole country for extermination, but you're having a good time by comparing children with computers from a Reddit story to nazis.
Well it's not insane to only welcome people that act respectful towards other people.
We'll see if this will be a solid community I guess.
It already is :)
How you behave in community spaces is 100% related to the project.
I agree, that would be very silly. I don't think you can compare not tolerating racists to mandating a particular car colour.
SQLite promotes Christian values but I don't think that they have a problem that a satanist is using their software.
It depends on your definition of racism I guess.
I don't think Gleam has a problem if Kenneth Copeland is using their software, either. The problem arises when you mistreat community members in community spaces; I can't speak for DRH, but I'm reasonably sure if someone waltzed into SQLite's forum denigrating the devs and their religious beliefs, there wouldn't be much hesitation in removing that person from said forum.
> I don't think Gleam has a problem if Kenneth Copeland is using their software, either.
I wouldn't be so sure. In leftist projects, there are countless of examples why someone is not welcome based on their personal beliefs, and because of this I'm cautiously suspicious about Gleam.
If I'm wrong then the Internet is a better place than I think it is, which would be a good thing. If I'm right, then at least I'll dodge another bullet. Either way I win I guess.
Gleam is the same as SQLite, we have some community values on the website but the licence doesn’t exclude anyone from using the software.
It is, however, unfortunate that a single statement on the Gleam homepage generates this exact conversation every time Gleam trends somewhere.
It's your project, and your community, of course, and I fully respect that. However it doesn't seem good that this statement creates so much friction and controversy for Gleam over and over.
After all, none of the statement's topics would be "on-topic" for any of the Gleam community hangouts. For instance, it would be equally off-topic for someone to discuss supporting or hating Nazis.
Perhaps moving the statement to a formal Code of Conduct page would be a "have cake and eat it too" type thing.
The Gleam community is wonderful, and you've done an incredible job building it. But I don't suspect the homepage statement had anything to do with that.
It only happens on hacker news. Elsewhere it is not mentioned or it is praised.
Gleam does have a formal code of conduct.
Not having a crappy app is my political agenda.
As with many languages that compile to a VM, I always ask myself: that’s all nice, but how do I interact with anything OUTSIDE of my program?
Can I do networking? Can I do system calls to my OS? Display graphics and sound? Can I import a C library that will do all that and call its functions? And if so, how? I just can’t see it from any documentation. Yes, I can call functions from other BEAM-based languages, but then I’m going in circles.
If you mean specifically on the BEAM (ignoring JS runtimes), the two options are ports and NIFs, both of which unfortunately have their drawbacks.
The Erlang docs on this are here: https://www.erlang.org/doc/system/overview.html
Thank you for the docs and explanation.
I am really interested in whether anyone has evaluated the performance of Gleam? The language is simple, easy to understand, like `Go` for example, but is it really performant like Go, or does it have any performance cost since it runs on top of a VM?
I'm working on a similar language.
The facts about Gleam:
1. It runs on the BEAM - exceptionally slow compared to Go, but infinitely scalable by default in a way that Go is not - in practice, very rarely matters.
2. They will argue the slowness doesn't matter -> if ~97% of time is spent waiting on I/O -> you can be 10x slower and that means you're only ~30% for typical applications -> it's easier to scale more machines on the BEAM than it is to scale a single machine -> this is true, but largely irrelevant in Go's core market -> it's almost as if Go was built by smart people.
3. The reality is that predictability is much harder to guarantee once you start moving components to different machines. Correct, predictable distributed computing makes correct, predictable concurrent programming look easy.
4. The BEAM does not allow shared memory, Go does (unsafely). There are many cases where the performance impact of this is night and day (why Go ultimately allowed unsafety).
I assume Gleam claims to make this just work. But as someone working in this space, this seems like trying to abstract away the difference between taking a boat to Europe or a plane.
Gleam may be nice if you're building something for the BEAM (massively scalable single app that just makes sense with the actor model, typically chat / telecom).
Though I question why you would use it over Elixir.
Go's syntax kind of blows, but it is so INCREDIBLY good at what it does, that you are not going to beat Go by just having better syntax and being "infinitely scalable" by default.
In practice, Go is easily scalable enough for almost anyone. If it isn't congrats, you're a $10B+ company. You can afford to rearchitect and optimize your hot paths.
I would look at benchmarks for Erlang and Elixir to get a rough idea of how Gleam performs at runtime. It's faster than Python generally, but not by a lot. It's for this reason that I really wish Gleam had a LLVM or Golang backend instead of JS / BEAM.
Here's some webserver benchmarks that cover a handful of popular languages: https://stressgrid.com/blog/webserver_benchmark/
I believe BEAM got a JIT compiler built into the runtime not too long ago (after that post, iirc), so it might perform a bit better now.
Gleam is ready and is amazing. We use gleam as the main language in our company
What's the product/use case?
We are a web agency, so client projects that are open to use a new language and our products like:
https://news.ycombinator.com/item?id=46530011
Glean is interesting from language nerd point of view, however I never had a reason to use Erlang at work, and probably never will, and I suspect that relates to most folks.
It’s funny how we avoid the technologies we can’t complain about much. Seeing an Elixir projects on production I always wonder „why we are not using it more often”. More talking about Elixir here.
For Elixir I saw a simple distributed job scheduler - it was dead simple in code and was ripped, because it didn’t require maintenance for ~8 years just working without issue and people who knew anything about it left company or switched part of company and acted as they forgot everything.
The other example is medium sized (in terms of features and code) web app - maintained by <30 people now, delivering more than 800 people at the other company, no stress, no issues and with great DX because of the BEAM (other company is drowning in JVM based nano-services).
The way many of us get work assignments is:
- Have to deploy product XYZ (because we don't write everything from scratch)
- Need to extend said product
- Use one of the official SDKs, because we aren't yak shaving for new platforms
Thus that is how we end up using the languages we kind of complain about.
To be fair, languages like Elixir and Gleam do exist, because too many complain about Erlang, which me with my Prolog background see no issues with.
I think the problem is that there is Erlang, the syntax, then Erlang, the features, and then there's OTP. It's a bit much all in one if you might have not done FP before, and then only with C-like syntax languages (e.g. Java).
When I joined an Erlang project I also had some aha moments with the syntax and how stuff is structured, and I found Elixir much nicer to work with (without any real Ruby experience). I don't want to say Erlang is not modern enough, but some things felt like they were around half the work (and more enjoyable) with some Elixir libraries (vastly bigger ecosystem than pure Erlang), for example handling XML.
It might be a bit simplistic, but I don't think you really lose anything meaningful when using Gleam or Elixir over pure Erlang. Just like you don't lose anything when using Clojure or Kotlin over pure Java.
I suspect you've also had zero reason to use the vast majority of programming languages at work in any meaningful capacity outside of the normal top ones. That's normally how tech decisions work. That certainly doesn't negate the possible benefits of other languages.
Others use Erlang and Elixir quite effectively and successfully in several billion dollar businesses apart from nerd aspects. It will be interesting to me personally if Gleam also has its day in the sun.
I'm now working on a real world legacy Elixir project in my day job and man oh man do I miss well defined types. Coming from Go, it makes a huge difference to my productivity when I'm able to click through fields and find usages of things, which comes down to the excellence of the Go language server. I know that the Elixir language server can infer some of this, but the language server in my experience is very fickle and flat out doesn't work if you have an older Elixir project.
I'm paying keen attention to Gleam to see if it can provide a robust development experience in this way, in the longer term.
Do the big updates to Elixir's type system help at all? afaik the most recent update added a huge amount of coverage that should extend to older code automatically.
I don't want to go into details of my work project too much, but the fundamental issue is that ElixirLS only supports 1.12+ (at least last time I checked).
Well. Coming from TS, Gleam just wasn't/isn't my jam. It's a nice programming language research project, but it just goes against the grain for me a little too much. All the made-up rules early returning always being weird `use` call, the type boilerplate—no inline object types as I remember. Lot of inventions that just makes me go "why?" Like the opposite ideology of Go. And yes I've used Haskell before (didn't like it) and Rust (kinda like it) and others in smaller quantity.
I am more excited about making things rather than fetishizing about some language paradigms so, I acknowledge that Gleam just isn't for me. I did give me the insight that for me, it might be the best to stick with the common denominator languages for the foreseeable future.
learning curve isn’t always a bad thing
to effectively critique a language you must understand the design trade offs made
Saw a great talk about Gleam last year at the Carolina Code Conference.
https://youtu.be/vyEWc0-kbkw?si=AayavKhhoqO5Mydh
I have worked extensively on Elixir in the past and had a decent enough time, some warts aside. How different is programming in Gleam in the day-to-day apart from type safety?
I think they have an issue on homepage: there is no "download/get start" link. All big buttons link to a tour page, and stopped there.
I was able to find that in the Docs https://gleam.run/documentation/ ( from gleam.run )
tbf https://gleam.run/ -> https://gleam.run/documentation/ -> https://gleam.run/getting-started/installing/ is two clicks, maybe it should only be one
although the playground is a much gentler introduction than installing gleam+erlang+rebar3
I've always thought this would be an excellent language for coding agents.
To use to write coding agents or for coding agents to write code in?
thought I’d try the showcase example in Raku (https://raku.org), so this Gleam
becomes this Raku well maybe you really want to have a main() so you can pass in name from the command lineOh God, they actually put that awful logo front and center.
I'd always thought it would be a go-like thing where the put the mascot away for everything except for the minor hero section or buried in the footer.
RIP Perl.
lol - I had the temerity to raise the "how about a new logo" topic last week and it's going to time time for me to (hopefully) convince the community of the need to let go
Raku looks sweet, but what is the point of this comparison? :)
I love coding in Raku - and I am sure that Gleam is nice too. But I get the feeling that Raku is underappreciated / dismissed by many due to the perl5 / perl6 history. So my thinking is, when I see a new language showcase an example on their website, presumably a carefully chosen snippet that showcases their language at its best, I like to see how Raku compares to that.
You know the take-aways from the comparison are quite instructive:
- do I need to import the io lib? (shouldn't this just be included)
- do I need a main() in every script? (does this rule out one liners like `> raku -e "say 'hi'"`)
- is `io.println` quite an awkward way to spell `print`?
I am not making the case that these are right or wrong language design decisions, but I do think that they are instructive of the goals of the designers. In the case of raku its "batteries included" and a push for "baby raku" to be as gentle on new coders as eg. Python.
The differences you mentioned are advantageous for Gleam depending on what you want. Like, having to namespace symbols instead of implicitly importing symbols makes it explicit where things come from which is good. Needing main, same thing. But the big differences are that Gleam is both functional, so everything is immutable, and fully typed safe. Completely the opposite of Perl/Haku so comparing these languages makes zero sense. If you don’t need types or functional programming you probably would just never use Gleam.
I think comparing 'printing hello world' programs isn't particularly useful, except that from how you describe it, Raku sounds more like a scripting language, which Gleam is not.
In comparison with Gleam, I would be more interested to see how good Raku is at helping the programmer prevent errors through static analysis, how easy it is to build with concurrency, how much value the language puts into being easy to understand and reason about, and whether it can run on the server as well as compile to JS.
I have no negative predisposition, I don't really care about the history of pearl or whatever, I have looked at Raku before but I find the syntax very foreign, and the fact that it seems to (maybe optionally?) incorporate glyphs that I can't easily type with a keyboard.
I love the butterfly though, so I'd love to get to know the language more.
> But I get the feeling that Raku is underappreciated / dismissed by many due to the perl5 / perl6 history.
Yes that would be me! If you like making these comparisons, can you write the following pattern matching in Raku?
sure...
I would probably reach for multi-dispatch...Here's the other Gleam concurrency example in Raku for good measure:
Again, thanks!
That doesn't look half bad - thank you!
[dead]
Now here's a type-safe functional programming language I recently bumped into, which with their focus on simplicity, ease of use, and developer experience, and compiling to either Erlang or Javascript, is really tempting to delve in deeper.