After reading the well written language tour, I have decided to give Gleam a try. I wanted to use it to build a single page application. Unfortunately, I was not able to figure out how to create and run a project with only a JavaScript runtime (is it possible?).
I have searched GitHub issues and discussions. I have found template-gleam-javascript which is archived and understandably does not work. Unfortunately, using Discord requires an account, so I could not ask questions there.
I think the language documentation is very good. I wish there was a document or an example application for starting with Gleam when you want to target a browser.
Hello! Thanks for trying Gleam. Unfortunately the documentation is all very fresh at the moment, more in depth tutorials are to come later. That template is no longer needed as we now have JavaScript support in the build tool itself.
To use the JavaScript target you can either add target = "javascript"
to your gleam.toml
or add --target javascript
to gleam run
, gleam test
, etc.
Here is an example SPA written in Gleam https://github.com/gleam-lang/developer-survey/tree/main/frontend
Other places you can go to talk to the community is the GitHub discussions page or StackOverflow using the gleam
tag.
Do you know of other open-source projects we can study?
A component I use a lot is the typeahead, like Twitter’s typeahead: async search, custom template for the results, etc. Would it be easy to hook into it or to replicate with Gleam? How would you approach that?
The Gleam v0.16 release announcement contains a few example HTML+JS widgets written in Gleam and running in the page. Perhaps that code + examining the page source is enough to get started? You’re definitely right that it’s a gap in the docs.
Most examples define 3 external fn
s that compile to JS’s document.querySelector, Reflect.get, and Reflect.set(on element, property, to value).
That looks super neat. I’d love to ditch JS for a dynamic client application. Do we know of bigger code bases we could learn from?
A UI component I use a lot is a typeahead, like twitter’s typeahead.js: async search, custom template for the results, etc. Would it be easy to hook into it or to replicate with Gleam?
Hi Ipil,
Is there a roadmap somewhere of what your are planning for Gleam and its ecosystem ?
I read elsewhere that you are going to work full time on Gleam, so I’m curious :)
Hello! Yes I’m now working full time on Gleam :)
The GitHub issue tracker has some information but most the detail is in the discussion on Discord.
Very confusing site. I spent 10 minutes clicking around, reading, and wondering what Gleam is.
Apparently you have to click the logo to go to the main page…
Sorry you found it confusing. Having the logo be a link to the homepage has been a web design standard for a long time so that was presumed sufficient. What could we do to make the navigation more intuitive for you?
Thanks for your reply and no need to apologize.
You’re right, lobste.rs has it as well so it might be just my old brain, but I would expect a ‘home’ section.
I think the main problem is if you want to stop use
ing something earlier than the end of the scope. For example I want to use a database connection to read some data then release connection and process the data.
I guess then you go back to explicit callbacks which isn’t a big problem.
Gleam is my favorite language that I haven’t actually tried yet (but I will as soon as I get home from my traveling).
I read the language tour on my phone one evening, and the next evening I was reading and understanding source code. That’s how approachable the language is!
use
is interesting because it’s a fairly complex feature, but it opens up so many options (as shown in the link). At first I was skeptical, but I think I agree. It’s worth the added complexity.
To give two examples of where Gleam has made (imo) interesting design decisions to keep the language simple:
Option[T]
, only Result[T, E]
. If you don’t want an error, just use Result[T, Nil]
. Is it more typing? Sure, but now you only have one type instead of two.type
(think struct
) can have multiple constructors, each with their own fields. This means they effectively double as enums. Have a look at the docs, they explain it better than I can.Anyway, congrats Louis! Very inspiring work :-)
A type (think struct) can have multiple constructors, each with their own fields. This means they effectively double as enums. Have a look at the docs, they explain it better than I can.
This sounds like it’s taken straight from Haskell. (Not a criticism, just background.)
It’s not specifically inspired by Haskell, it was mostly inspired by Erlang. I didn’t realise that Haskell had the same feature but now I read the documentation it seems very similar. Cool stuff!
I mean, Gleam does belong to the ML family of languages IMO, so we may as well say the feature is inspired by Standard ML! /s
Some examples of “ML-like” features include…
Sum types as a primary data modeling tool, in some cases even displacing records for small-ish data structures
First-class functions and some use of recursion, often used to constrain and thereby elucidate control flow. This is sometimes in lieu of imperative-/procedural-style constructs such as…
In languages like Javascript and Gleam, this extends to the use of a syntactic construct you may know as a callback function.
Type inference (usually Damas–Hindley–Milner type inference)
Other idioms that, like the above, help to obviate and/or discourage the use of global state in implementations as they scale
There are plenty of ML-like languages for different runtimes, including a few that are used for systems programming.† Languages often described as “ML-like” include…
Haskell is explicitly inspired by ML, but is often considered its own category due to the radical departures it makes in the directions of a) purely functional programming and b) requiring (in most cases) the use of monads to represent effects in the type system.
† My educated guess: This is largely because the core syntax and feature-set is relatively well understood at this point. As such syntactic sugar is rarely necessary in order to express intent directly in efficient code. This is unlike in “dynamic” languages such as Python, Ruby, and Elixir, which tend to make liberal use of metaprogramming in order to make the syntax more directly express intent. This can often make it unclear what is actually happening to make a given piece of code run.
I find it interesting that nothing on that list is inherent to functional languages. All these sweet goodies might as well exist in an imperative language, but outside of Rust, they don’t.
I’m still sad Go completely missed the boat on that one.
Yup. Maybe someday we’ll have an approach in between those of Go and Rust; that’s some of what I’m looking to Gleam for, even if it’s not primarily a systems programming language.† In the meantime, we have the sometimes-insightful, sometimes-regressive minimalism of Go; and the sometimes-insightful, sometimes-overwhelming maximalism of Rust.
† It is my broad understanding that the BEAM VM—on which I expect most* Gleam code will run—helps concurrent applications scale by denying granular control of threaded execution. This can be thought of as vaguely similar to the Go runtime’s decision to have a blessed implementation of cooperative multitasking, namely goroutines. In contrast, the Erlang ecosystem benefits from having a blessed provider and model (respectively) for all concurrent computation, thanks to the OTP supervision tree combined with the actor model of concurrent computation. It takes power away from the developer, but to the benefit of the system at large. Boy, is it ever exciting that we might actually have a statically-typed language built atop that excellent multitasking infrastructure!
From my PoV Go and Rust are incomparable since Go is a GC’d language and Rust is a non-GC’d language. So on this basis Gleam, too, can never compete with Rust but is for sure a strong contender in the space Go plays in.
If all that matters is the engine that runs your code, the sure. If a project is performance-sensitive, then its options for reasonable programming language are constrained anyway IMO. When I compare these languages, I have their developer experience in mind. At least, relative to how much performance they leave on the table.
It honestly depends what one even means by “functional language” lots of ML and ML-like things exist which are not particularly functional including possibly: SML, OCaml, Swift, Scala, Kotlin, Haxe
What’s not-functional about SML, OCaml, and Scala? Are you perhaps comparing them to the purely functional Haskell?
What’s functional about them? Every language I listed is equally functional and not-functional depending how you use it. They’re all ML variants after all.
Facebook’s Reason, which is sometimes even called ReasonML for clarity
Credit where credit is due: Reason is a syntax extension for OCaml. It’s not a whole cloth creation by Facebook.
I think it is an ML language in every way, although we moved away from the traditional ML syntax in the end.
I really wish the only community options weren’t Discord and GitHub – not even an unofficial Matrix.org room or IRC channel mention (seems IRC used to be supported). I was looking into the language recently as something with types on BEAM, but I felt like there was no option to ask questions toward the community if I had them so I didn’t feel it was worthwhile to read any further.
We did used to use IRC and we looked into Matrix but both lacked the anti-harassment and anti-abuse features that we need to run a community. Community is very important to Gleam so we need to ensure that we can deal with trolls and bigots should they arise.
As a nice unexpected bonus the active community exploded in size once we switched from IRC, it seemed it was a barrier to entry for many people.
Is there a downside for listing unofficial options for people to join at their own risk if they don’t feel comfortable giving their private data to Discord?
It’s tricky. So far the experience with unofficial projects (not unofficial community forums, afaik there are none) is that people still come to the Gleam core team when they want help with them or have a problem to report. It ends up creating additional work for us and we have quite limited time due not having corporate backing.
It would be good to list unofficial forums but we probably need to think carefully about the messaging and expectations around them.
I can understand it from an administrative and marketing standpoint; it’s just a shame that we, society, can’t seem to have the option that protects privacy and also attracts the masses (who are not aware of the privacy threats, or see the convenience as a worthwhile tradeoff). Instead, someone such as myself feels put off and I can’t help be echo the schism it creates noted by the Drew Devault in Please don’t use Discord for FOSS projects . It’s the reason I suggest at a minimum listing unofficial bastions as a compromise.
It’s just too much work I’m afraid. If we had more money we could, but right now I’m stretched thin.
As someone who works on community and chat systems I would love to hear which anti-harassment and anti-abuse features are most important to a community like yours.
Gleam seems like a really cool language! I really like the design of Elixir, but I would love something statically typed. Something with first-class concurrency like Go, without the corner cases, and with functional programming creature comforts like ADTs to allow for composable error handling. The BEAM seems to me like the most mature platform for concurrent & distributed programs, and being ML-like gives you much of the rest “for free”. Perhaps I’m misunderstanding what Gleam is at present, but I think the language has a lot of promise.
That being said, I’m not entirely sure what the roadmap is. I’ve looked through the website a couple times, and noticed the docs were somewhat incomplete and there weren’t yet a lot of facilities for creating & using generic types.
Is assistance with evolving the language design welcome? Alternatively, is there a roadmap somewhere to guide a prospective contributor to high-priority issues or good first issues?
Hello! Thanks for the support!
Perhaps I’m misunderstanding what Gleam is at present, but I think the language has a lot of promise.
Yes, I think you have an idea of the goals :)
That being said, I’m not entirely sure what the roadmap is.
The planned additions can be found in the issue tracker. We’re low on time so there’s not lots of detail in the tickets (most the discussion happens in Discord) but if anything catches your eye I’m happy to add extra info to specific tickets.
Tickets that are good to start with have been labelled as such, and more will be added in future.
Is assistance with evolving the language design welcome?
Drop by the Discord and get involved! That said the language has matured somewhat and there’s not going to be any large changes in future.
I’m “excited from afar” about Gleam, and it seems like maybe it’s mature enough for me to begin exploring. I haven’t used a BEAM language–besides networked services, what other use cases is Gleam a good fit for? I don’t think I’ve seen many CLI tools implemented in a BEAM language, for example. Even within the context of networked services, does just using Gleam pretty much get me all of the supervisor tree / reliability goodness that I hear about with Erlang, or do I need to opt into some framework? And if I use Gleam, will I effectively have to learn Erlang and/or Elixir? How much interop is there in the ecosystem, and how much is the user exposed to it?
I haven’t used a BEAM language–besides networked services, what other use cases is Gleam a good fit for? I don’t think I’ve seen many CLI tools implemented in a BEAM language, for example.
It’s a general purpose programming language with a virtual machine and a garbage collector, so all sorts really. I use it mostly for web services and little CLI tools that I use personally. I also have some frontend SPAs and widgets written in Gleam compiled to JavaScript.
If I were to make CLI tools that I wanted to ship to users I would probably compile the Gleam to JavaScript and bundle it into one file. It’s a bit easier to distribute it like that then to ask people to install the Erlang virtual machine.
Even within the context of networked services, does just using Gleam pretty much get me all of the supervisor tree / reliability goodness that I hear about with Erlang, or do I need to opt into some framework?
The Erlang framework that offers these properties is called OTP and you can use it from Gleam like any other BEAM language. We’ve got our own version called gleam_otp which is statically typed.
Most the time when writing web applications and such you can largely ignore it and the web server, database client, etc will all be written using the framework, giving you those properties.
And if I use Gleam, will I effectively have to learn Erlang and/or Elixir? How much interop is there in the ecosystem, and how much is the user exposed to it?
You don’t have to, but if you’re looking to use libraries we don’t have binding for it’ll help to learn some Erlang. Some Gleam users have never written any Erlang, others do a lot of it as they bring new APIs to Gleam. It largely depends on what you’re looking to do currently while the ecosystem is younger.
This is great news. Really excited that it sounds like a lot of the networked services ecosystem leverages OTP already (rather than it being more niche). Personally, I’d prefer to have self-contained binaries for CLI tools, but that’s not much of a big deal–I can probably use Go or similar if that’s really important to me. I’ll play around with it soon. 👍
Actors and messages are implemented in the gleam_erlang
and gleam_otp
libraries and they are statically checked.
Gleam looks like a very nice language: I hope to find time to give it a try this summer.
Is there a showcase of “stuff built with Gleam” out there ? I’m curious :)
There’s a list of libraries and projects here: https://github.com/gleam-lang/awesome-gleam
Could be useful. More to come in future!
You ought to add a play button to the videos. Firefox disables autoplay by default, I didn’t even realize they were videos at first.
Ah, I suppose “block audio” is the default. It would autoplay cause your videos don’t have sound. I have set autoplay to “block audio and video”.
Either ways, you can add the “controls” attribute in the video tag.
This all sounds really great, except this bit:
And on a related node, recently publish packages can be replaced with gleam publish –replace. This is useful for correcting any mistakes made during the process of releasing a package.
Does that mean the content of a particular version of a package can change? (Also I think there’s a typo “recent published packages”?)
This is a feature of Hex (a package manager for all BEAM modules (erlang, elixir, gleam, etc)). The time limits are quite short so there should be very little danger:
There are exceptions to the immutability rule, a package can be changed or unpublished within 60 minutes of the package version release or within 24 hours of initial release of the package.
https://hex.pm/docs/faq#can-packages-be-removed-from-the-repository
Packages also come with checksums so the tooling will identify a change compared to what is expected in the lockfile.
With this a .ts.d file will be generated for each Gleam module compiled. … Will produce this .ts.d file. … gleam.ts.d
Isn’t a TypeScript declaration file supposed to be .d.ts, not .ts.d? For example.
haha I was so confused by this and was thinking “what kind of workaround is this???” 😅 glad to know it was just a typo
It sounds like golang is not good for whatever it’s being used for, but even in the guy’s 4 blog posts there isn’t a ton of detail.
Golang is good (perhaps not great) for things where you’re mostly doing io on unixoid platforms and there are no really complicated algorithms. It also discourages cleverness by verbosity (unlike Java encouraging both cleverness and enforcing verbosity). Concurrency is less painful than most other languages.
Not every programming language is great for every use case.
Congrats! Gleam is super cool and I’m glad to see it keep getting better.
Nitpick: under “Compilation” you want “emitted” rather than “omitted”.
There’s no overhead compared to calling regular Erlang code, and the generated APIs are idiomatic Erlang.
Any Gleam packages published to Hex (the BEAM ecosystem package manager) now includes the project code compiled to Erlang. Once the various build tools of the other languages have been updated they will be able to depend on packages written in Gleam without having the Gleam compiler installed.
We want to fit into the wider ecosystem so smoothly that Erlang and Elixir programmers might not even know they’re using Gleam at all! All they need to know is that the library they are using is rock-solid and doesn’t fail on them.
This is awesome! It’s really a shame that Elixir never did this. All the Elixir libraries are really painful to use in Erlang projects. I intentionally use Erlang for the open source libraries I’ve created so they are usable from all languages built on the VM.
You feel exactly the same way I do! There’s so much good stuff in Elixir I wish the other languages could use.
What are some other notable languages on the BEAM runtime? I’m only aware of Elixir, Erlang, and Gleam.
Elixir and Erlang are the big ones but the other ones that get used in production that I’m aware of are LFE, Purerl, Hamler, and Luerl
It’s really a shame that Elixir never did this. All the Elixir libraries are really painful to use in Erlang projects.
Aside from needing an Elixir compiler in all cases, and not being able to use Elixir macros (not Elixir’s fault!), where is the pain point? I am on the Elixir side 99.9% of the time so I don’t see it.
There’s a few things:
'Elixir.Project.Module':'active?'(X)
.These are not huge barriers, but if you use a library written in Erlang (or in future Gleam) you don’t have to worry about any of this. You add it to your list of deps and that’s it.
I think you missed my point. It’s troublesome when you want to use Elixir libraries from Erlang, or from any other language on the Erlang VM. The overhead and hassle of retrofitting an existing project with support for Elixir compilation makes it not worth the effort. Thus I stick with Erlang because I need to write code that can be used from any language on the VM.
It could be (and probably is) pretty easy to use one of the existing rebar3 plugins for using Elixir from a Erlang project. Take https://github.com/barrel-db/rebar3_elixir_compile as an example integration. I haven’t used it, but it looks pretty straight forward. I still wonder how any configuration would be wired together, but that should be pretty reasonable to write if needed.
Beyond the build system, I imagine Elixir code doesn’t feel ergonomic in other languages. It’s function argument ordering differs from a lot of functional languages, the pervasive use of structs in library APIs, the use of capitalization for modules doesn’t read well, and the constant prefix of 'Elixir.AppModue':some_function().
all make it less appealing.
All together it’s just enough hassle to use outside of Elixir, and often that bit of work + usability issues isn’t worth it.
Question. What’s more to dependency resolution than constraint solving? Why not just use a solver like Z3?
There’s not huge amounts of difference. Pubgrub is based on the same field of research and is effectively a specialised constraint solver optimised for speed and clear error messages with this one particular problem.
The main difference is that with pubgrub we include an extra 2000 lines of Rust, while Z3 would mean distributing and linking to 600,000 lines of C++.
One aspect that I am not sure off the shelf constraint solvers handle automatically is the fact that after, say, upgrading a package some of its previous dependencies may no longer be necessary and could be dropped. But this in turn can change the set of constraints that the initial solution was based on meaning that it now has to be re-evaluated. Which in turn can lead to other packages being no longer necessary (or even previously thought to be unnecessary become necessary again). So there is this iterative refinement process to arrive at the optimum solution.
That paragraph seems like the author is justifying to themselves why they want to play with k8s. I think they’re super weak reasons, could delete the entire paragraph and improve the post.
eg, not sure I’d claim Mesos hasn’t gained critical mass given it underpins Netflix’s entire stack (Titus depends on Mesos & Zookeeper.) Nomad has equivalent large deployments, Cloudflare, Roblox and as you point out, is free (with paid-for extra features.)
Author here, thanks for the feedback. I meant Nomad is not free because some features are behind an “Enterprise” paywall.
Isn’t that also technically true of k8s? In the sense that cloud providers (google, amazon) have a special sauce that they don’t share with mere mortals?
You don’t bump into “Error - Enterprise only feature” messages when working with K8s. I’m sure Amazon and Google have their own tools for working with it, but their use case is very specific.
It was voted to the attic in April: https://lists.apache.org/thread/ysvw7bb1rd8p88fk32okkzr75mscdjo8
Are there plans for a first-class mix compiler? I see tooling commits that have been sitting at the top of the changelog for a while. I’d love to use gleam inside my elixir umbrella apps!
The gleam compile-package
API is perfect for use by mix etc, and it has been out for some time! Mostly we need someone to make a mix plugin that uses it. I’m focusing on the Gleam tooling and I’m not an Elixir user at present so I won’t be doing it myself any time soon.
Great focus on ergonomics! I deployed Gleam to production for the first time last week. Thanks so much for all the hard work!
Wow, that’s great! Congratulations. I’d love to hear more about how you’re using it if you’d be willing to share :)