Some thoughts so far: Installing gleam installed about 50 packages on my system (possibly all erlang/elixir related). But what if I just wanted to transpile to js? Perhaps this is a packaging issue on my system though.
What I really wish is that Lua would be considered as another transpilation target. I think gleam could shine for DSLs in other programs but embedding Lua is 3x easier than embedding a js runtime imo.
In general, I find the nicest thing so far the community. And I want to say that the quality of libraries and resources in the gleam community seems exceptionally high. It reminds me of the rust community insofar as that for most hard problems someone smarter than me has already worked on it and published a good solution (e.g. lustre, squirrel).
Then I would say you can also expect a lot of creativity and experimentation, the things that may fly under the radar in larger language ecosystems stand out here due to the growing and welcoming community.
IMHO the actor model is great until you need to share something across processes, then you have a distributed computing problem inside your program.
For developing fault tolerant multicore programs I think I'm better off using a functional effects system with software transactional memory like Scala/ZIO than Gleam/OTP. I can still use the actor model where appropriate. Plus the JVM software ecosystem and runtime observability / battle-testedness is far better than BEAM.
I think it's also worth mentioning - that hasn't been mentioned yet, Erlang (which Gleam is built atop) is ... *the* language that facilitated the nine nines (99.9999999%) uptime; and one of the major components of its ability to do that came with the robust supervising and cross-machine infrastructures that inspired the actor systems later on.
This is, quite literally, Erlang's job. It's one job. And it is proven *excellent* at it.
Can you give an example where you MUST share mutable data that cannot be passed as immutable data structures? The only thing I can think about is hardcore number crunching and yes that should not be written directly in elixir or Erlang or something like that but you could always write NIFs for that.
PureScript is a mature functional programming language with an Erlang back end, if you want another statically typed alternative for BEAM. It is basically a dialect of Haskell with strict evaluation and row polymorphism.
I’m fascinated by the sound of Erlang/BEAM but I’ve never found the time to actually try it. How are people using it in production? Do you write all your service logic using it or delegate specific parts to it?
gleam would be taken more seriously if they didnt plaster their strong political opinions on the project page..i do not understand why they need to talk about politics on a tech project page..this is not about agreeing or disagreeing with the viewpoints..just keep it out of your professional discourse if you want people to take you or your work seriously...otherwise it just deviates the discourse unnecessarily
For all you wonderful people using Gleam, do you use Phoenix? Or any other web frameworks? I really would love to do Gleam with something like Phoenix, but I have not had enough time to check out all the options yet. I'm in the process of building a new project with Python, but if there's options with Gleam worth looking into I just might try it out for this new project.
I learned some Gleam a while ago, my familarity with F# helped, but I didn't find a use case for it. Some while ago I wanted to play with raw sockets so I figured, why not Gleam, its binary parsing syntax will be handy so I looked into the erlang sockets module and attempted to write some ffi wrappers for the necessary functions. Turns out it is not as straight forward, especially that the definitions on erlang side are often complex, with many variants and the dynamic nature doesn't often map very well to Gleam. The documentation was also quite sparse for interop. Interop also involves a lot of Dynamic types so encoding/decoding back which is cumbersome. Sooner or later I hit a wall. By virtue of reading Erlang docs to write the ffi wrappers I eventually got familiar with Erlang syntax which at first was quite alien, but turns out it is rather simple with just some rules to remember. I settled on writing Erlang directly. I am not sure how Elixir compares, never tried it, but I was initially put off by the syntax resembling Ruby, which I have fond memories of, but was always very implicit which I didn't like. Writing pure gleam is pretty fun, but a lot of interesting things require either ffi interop or decoders/encoders even for simple things like json which takes away some of that fun.
No, the VM is functional and immutable so you cannot implement things like `while` on it efficiently. It is highly optimised for the functional immutable style of programming.
15 comments
[ 2.8 ms ] story [ 33.3 ms ] threadWorth trying if you’re on the fence, especially if you’re into static types, no nulls, functional, ML type languages. Plus beam of course.
Some thoughts so far: Installing gleam installed about 50 packages on my system (possibly all erlang/elixir related). But what if I just wanted to transpile to js? Perhaps this is a packaging issue on my system though.
What I really wish is that Lua would be considered as another transpilation target. I think gleam could shine for DSLs in other programs but embedding Lua is 3x easier than embedding a js runtime imo.
In general, I find the nicest thing so far the community. And I want to say that the quality of libraries and resources in the gleam community seems exceptionally high. It reminds me of the rust community insofar as that for most hard problems someone smarter than me has already worked on it and published a good solution (e.g. lustre, squirrel). Then I would say you can also expect a lot of creativity and experimentation, the things that may fly under the radar in larger language ecosystems stand out here due to the growing and welcoming community.
For developing fault tolerant multicore programs I think I'm better off using a functional effects system with software transactional memory like Scala/ZIO than Gleam/OTP. I can still use the actor model where appropriate. Plus the JVM software ecosystem and runtime observability / battle-testedness is far better than BEAM.
This is, quite literally, Erlang's job. It's one job. And it is proven *excellent* at it.