Gleam is my new obsession(ericcodes.io)
ericcodes.io
Gleam is my new obsession
https://ericcodes.io/blog/gleam-my-new-obsession.html
27 comments
I have to fully agree. They have a discussion on their GitHub [0] about tabs/identation stating that the design goal is to have a non-configurable formatter.
I get the idea behind having a streamlined formatting style, but I’m really not a fan of denying users the flexibility to adjust it to their needs. Consistency across projects is nice, yet forcing everyone into a single indentation style feels unnecessarily rigid. A little configurability would go a long way :)
[0] https://github.com/gleam-lang/gleam/discussions/3633
I get the idea behind having a streamlined formatting style, but I’m really not a fan of denying users the flexibility to adjust it to their needs. Consistency across projects is nice, yet forcing everyone into a single indentation style feels unnecessarily rigid. A little configurability would go a long way :)
[0] https://github.com/gleam-lang/gleam/discussions/3633
https://github.com/gleam-lang/gleam/discussions/3633
About the only argument I find remotely convincing from language devs (Nim is another similar lang) is that they don't want to maintain anything extra. Fair enough. The other arguments they roll out are always specious. The stuff in the issue above is comical: default GH tab width is 8, don't want Gleam to look weird to people looking at Gleam on GH, so force 2 spaces.. lol. Sometimes it seems like lang maintainers get a little too far up their own arses about this stuff. Your v0.x just-past-toy lang with a weak std lib and barely any ecosystem isn't turning off potential adopters because of how default indentation looks on one - arguably the worst - forge.. it's turning adopters away because of these silly hills you choose to die on. Nearly all mainstream langs handle spaces or tabs; forcing 2 spaces is just more "perceived strangeness", as a maintainer on that issue put it. It's your lang, do as you like with it, but if you want growth, don't be arbitrarily rigid.
About the only argument I find remotely convincing from language devs (Nim is another similar lang) is that they don't want to maintain anything extra. Fair enough. The other arguments they roll out are always specious. The stuff in the issue above is comical: default GH tab width is 8, don't want Gleam to look weird to people looking at Gleam on GH, so force 2 spaces.. lol. Sometimes it seems like lang maintainers get a little too far up their own arses about this stuff. Your v0.x just-past-toy lang with a weak std lib and barely any ecosystem isn't turning off potential adopters because of how default indentation looks on one - arguably the worst - forge.. it's turning adopters away because of these silly hills you choose to die on. Nearly all mainstream langs handle spaces or tabs; forcing 2 spaces is just more "perceived strangeness", as a maintainer on that issue put it. It's your lang, do as you like with it, but if you want growth, don't be arbitrarily rigid.
> The stuff in the issue above is comical: default GH tab width is 8, don't want Gleam to look weird to people looking at Gleam on GH
This is indeed comical. At the same time, it's an odd choice for GH to display eight spaces for a tab nowadays. Perhaps a punishment that the source code uses tab characters at all?
This is indeed comical. At the same time, it's an odd choice for GH to display eight spaces for a tab nowadays. Perhaps a punishment that the source code uses tab characters at all?
This is why tabs are better IF indentation is forced (luke in Go, with gofmt).
Maybe you could just use tabs and save and read them as 2 spaces but display as 4.
I think Idea IDEs have that flexibility... Not sure.
I think Idea IDEs have that flexibility... Not sure.
I agree. YAML does this too. It's dumb.
I'll accept that tabs unfortunately lost the tabs/spaces war (too complicated for many people I guess), but let's at least stick to 4 spaces please.
I'll accept that tabs unfortunately lost the tabs/spaces war (too complicated for many people I guess), but let's at least stick to 4 spaces please.
Gleam is really interesting to me, because it's built on top of the BEAM runtime, but as far as I can tell, it does very little with the actor model that is the star attraction of BEAM/Erlang. There's a (non-built-in?) package that exposes some of the OTP and concurrency tools available, but it doesn't look widely used or recommended on the website. The linked recommends a talk that I hadn't seen before (and unfortunately can't watch right now on my phone!) but other than that there seems to be very sparse documentation available. Searching for "gleam OTP" mainly seems to produce a myriad of alternative OTP implementations and not much in the way of explanations or examples of common patterns or anything like that.
Some of this is obviously going to be the newness of Gleam, but I remember when Elixir was still brand new, and the OTP integration was one of the biggest selling points there, and a big part of their documentation and the ecosystem in general. Whereas with gleam, it almost seems like they're embarrassed of the runtime's distributed heritage? Whereas to me it seems like the OTP and the actors model in general would be the biggest selling point for a language like this.
Does anyone have any insight into why this is, or what concurrency practically feels like in gleam?
Some of this is obviously going to be the newness of Gleam, but I remember when Elixir was still brand new, and the OTP integration was one of the biggest selling points there, and a big part of their documentation and the ecosystem in general. Whereas with gleam, it almost seems like they're embarrassed of the runtime's distributed heritage? Whereas to me it seems like the OTP and the actors model in general would be the biggest selling point for a language like this.
Does anyone have any insight into why this is, or what concurrency practically feels like in gleam?
The OTP package is not built-in because that would prevent Gleam being compiled to other targets, namely Javascript. This is a big draw for the language, and it's worth pulling out BEAM-specific stuff into packages for this reason.
I think Louis and the Gleam community are very serious about supporting OTP, but there are still open research questions around typing parts of OTP.
The parts of OTP that Gleam supports are still very useful, compatible with Erlang/Elixir, and very much used. And they have the benefit of being statically typed [1].
There's no embarrasement about Gleam's primary runtime being the BEAM, it's right there on the front page, above the fold! [2]
[1] https://github.com/bcpeinhardt/learn_otp_with_gleam [2] https://gleam.run/
I think Louis and the Gleam community are very serious about supporting OTP, but there are still open research questions around typing parts of OTP.
The parts of OTP that Gleam supports are still very useful, compatible with Erlang/Elixir, and very much used. And they have the benefit of being statically typed [1].
There's no embarrasement about Gleam's primary runtime being the BEAM, it's right there on the front page, above the fold! [2]
[1] https://github.com/bcpeinhardt/learn_otp_with_gleam [2] https://gleam.run/
Because Gleam compiles to Erlang, it can seamlessly integrate with the larger BEAM ecosystem, including existing Erlang and Elixir OTP applications and libraries.
@external decorator: This escape hatch allows Gleam code to call functions defined in Erlang or Elixir modules. While it bypasses Gleam's type checks for the function call, it provides a powerful way to leverage the full capabilities of the existing OTP ecosystem.
I believe the biggest reason it's hard to replicate OTP fully and quickly is Gleam's type system (but I could be wrong).
@external decorator: This escape hatch allows Gleam code to call functions defined in Erlang or Elixir modules. While it bypasses Gleam's type checks for the function call, it provides a powerful way to leverage the full capabilities of the existing OTP ecosystem.
I believe the biggest reason it's hard to replicate OTP fully and quickly is Gleam's type system (but I could be wrong).
From my understanding distributed (cross machine) typed message passing is hard.
Doesn't Erlang/Elixir solve this by having every function do its own parsing (via pattern matching) and then failing fast if something goes wrong? That seems intuitively like a good approach to take — you can't make any real guarantees across machine boundaries, but you can use structural typing at the edges to ensure that the data coming across the boundaries has the right shape.
They want to keep otherlangs as a compile target
Okay, you convinced me. I will try it. It seems like something I would really enjoy.
I like rust but it takes too long to write. Go is usually my go to language because its simple I adore erlang and can write some elixir but I also dislike dynamic typing.
I have been looking at gleam for a while and I think now you inspired me to create a small project to learn more about it.
I like rust but it takes too long to write. Go is usually my go to language because its simple I adore erlang and can write some elixir but I also dislike dynamic typing.
I have been looking at gleam for a while and I think now you inspired me to create a small project to learn more about it.
Elixir is gradually typed: https://news.ycombinator.com/item?id=38914407
...and is gradually getting more gradually typed: https://elixirforum.com/t/elixir-v1-19-0-rc-0-released/71190...
...and is gradually getting more gradually typed: https://elixirforum.com/t/elixir-v1-19-0-rc-0-released/71190...
> I'd often joke, "I love Rust, but what I really want is a simpler Haskell with a C-like syntax" or "I love Rust, but if it had a garbage collector, Rust would be my perfect language".
OCaml is a simpler Haskell, but I don't think it has a C-like syntax. However, rescript[0], the JavaScript like syntax for OCaml based Hindley Milner typed language might actually fit well for small and personal projects.
[0] https://rescript-lang.org/docs/manual/v8.0.0/introduction
OCaml is a simpler Haskell, but I don't think it has a C-like syntax. However, rescript[0], the JavaScript like syntax for OCaml based Hindley Milner typed language might actually fit well for small and personal projects.
[0] https://rescript-lang.org/docs/manual/v8.0.0/introduction
Reason (https://reasonml.github.io/) is the JS like syntax for OCaml.
ReScript is a fork that explicitly removes the connection to OCaml and focuses on JavaScript output.
yes, correct, but ReasonML is abandoned, while there is still some traction in Rescript and it offers the same type safety.
Related:
My first impressions of Gleam
https://news.ycombinator.com/item?id=45231852
My first impressions of Gleam
https://news.ycombinator.com/item?id=45231852
Once you throw out the BEAM and OTP, why not OCaml?
Seriously, I find the OCaml syntax way less obtuse than, for example, all the trait and macro idioms that I have to chop through with Rust. Sure, Rust has braces, but that doesn't make its syntax easy by any means.
Nevertheless, I am happy to see this Cambrian Explosion of programming languages. Eventually, we may get a good one.
Seriously, I find the OCaml syntax way less obtuse than, for example, all the trait and macro idioms that I have to chop through with Rust. Sure, Rust has braces, but that doesn't make its syntax easy by any means.
Nevertheless, I am happy to see this Cambrian Explosion of programming languages. Eventually, we may get a good one.
OCaml is a good one but many find it too hard. It can be a bit alien and there are not enough jobs to justify learning it for work.
As a note, before being bootstraped, Rust was written in OCaml iirc
That’s correct.
Gleam is pretty cool. I could see switching to it if meta programming is added.
Btw there is a reason behind the pink design for the language website
So.. share with the class.
I like the whimsical website. Never attributed it to anything, but “we’re all having fun here”.
I like the whimsical website. Never attributed it to anything, but “we’re all having fun here”.
What is the reason?
Please stop.