Shine with Gleam(rockyj-blogs.web.app)
rockyj-blogs.web.app
Shine with Gleam
https://rockyj-blogs.web.app/2024/08/31/shine-with-gleam.html
51 comments
Great programming lang article, starts with premises then shows examples, iterations, and final words. Gleam looks really interesting, though personally I’ll stick with TypeScript because it’s “good enough” and I understand where mutability can sneak in sometimes well enough these days.
I rewrote my webapp, Nestful[0], in Gleam.
I use it in Vue components with Vleam[1]. About half of the frontend is rewritten at the moment, and it is a joy to use.
I'd do it again just for the error handling.
[0] https://nestful.app
[1] https://github.com/vleam/vleam
I use it in Vue components with Vleam[1]. About half of the frontend is rewritten at the moment, and it is a joy to use.
I'd do it again just for the error handling.
[0] https://nestful.app
[1] https://github.com/vleam/vleam
I'm currently a Java developer working on a large code base. This is where Java's object oriented nature really shows its weaknesses. Reading other people's code becomes a huge pain, since everything is mutable and you can never be sure what state your program is in after a function call. Even C++ is better in that regard, at least you can pass values by copy or const reference.
Gleam looks really nice at first glance. The problem of course is, as long as there is no industry support, it doesn't make sense to invest into it. It may be ok for small side projects, but I wouldn't dare starting a major application in something like that. Sooner or later you come across something you need and there is no library for it. Then you are forced to start messing around with FFI and whatnot.
> everything is mutable
That’s the real problem, not OOP. There is a functional-ish OOP style where most objects are immutable. Classes are used to capture invariants (in the sense of https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...), or for local-only mutations (like building a collection in a local scope, which is passed on as immutable after building).
The defining characteristics of OOP are encapsulation and subtyping, not mutability.
That’s the real problem, not OOP. There is a functional-ish OOP style where most objects are immutable. Classes are used to capture invariants (in the sense of https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...), or for local-only mutations (like building a collection in a local scope, which is passed on as immutable after building).
The defining characteristics of OOP are encapsulation and subtyping, not mutability.
And Java doesn’t properly support immutability :(
Encapsulation is a whole other issue, to which the ‘solution’ is almost always more encapsulation. The nice thing about immutability is that it is not really compatible with how we do encapsulation, so if you are strict about immutability then you are suddenly free from the whole quagmire as a side-effect.
Encapsulation is a whole other issue, to which the ‘solution’ is almost always more encapsulation. The nice thing about immutability is that it is not really compatible with how we do encapsulation, so if you are strict about immutability then you are suddenly free from the whole quagmire as a side-effect.
I disagree on both accounts. It’s not difficult to code truly immutable classes in Java. And encapsulation is beneficial regardless of mutability.
There's a difference between something being possible vs supported. In C/C++ you can have a type, and a const version of that type. In Java you can't define a class and automatically be able make a reference to a const object of that class. You can make a final reference, but that only means you're always referencing the same (mutable) object. You could you use final fields for the entire object, but then you have to make another type for the mutable kind, or builders to go from one to an other. Another example is Unmodifiable collections, which are only views on modifiable ones, so you can't be sure it's not modified. A language that supported immutability would come with some of these batteries included.
There are places to use encapsulation with mutability, such as simulations, but having hidden mutable states is not desirable property when constructing rapidly changing applications.
I do my best to keep things sane when working with a Java or Ruby or what have you codebase, but I don't pretend it's something it's not. Just do the best that the codebase and organization can tolerate.
There are places to use encapsulation with mutability, such as simulations, but having hidden mutable states is not desirable property when constructing rapidly changing applications.
I do my best to keep things sane when working with a Java or Ruby or what have you codebase, but I don't pretend it's something it's not. Just do the best that the codebase and organization can tolerate.
Right, you can’t turn a mutable object into an immutable object when other references to the mutable interface already exists. Const as in C/C++ is certainly a useful feature that Java lacks, but it’s quite a leap from that to claiming that Java doesn’t support true immutability. I develop Java applications with immutability as the default, and it works quite well. The lack of the abive-mentioned feature is not a critical obstacle.
Regarding your point about collection views, const references are often also just views on mutable objects, and this poses no particular difficulty. And you can implement truly immutable collections in Java if you really insist on it.
Regarding your point about collection views, const references are often also just views on mutable objects, and this poses no particular difficulty. And you can implement truly immutable collections in Java if you really insist on it.
It’s difficult in the sense that somebody consuming your class will sooner or later start relying on reflection to do something with it they shouldn’t (because they can), and then when you make a change in the future it will cause breakage downstream. Records solved this for some cases at least.
More important imo is that the standard collection classes can’t even be set to immutable with the final keyword. Sure you can use something else, but professionally you are going to have to deal with them most of the time still.
More important imo is that the standard collection classes can’t even be set to immutable with the final keyword. Sure you can use something else, but professionally you are going to have to deal with them most of the time still.
Yeah they seem to be trying to force the conversation into encapsulation == mutability when that flatly is just not true. There are tons of immutable objects that benefit from encapsulation and there is plenty of internal immutable state that you would want to encapsulate and not just give out.
OOP is encapsulation, inheritance, and polymorphism. Polymorphism maps to behaviour which is type-based, but usually also based on the objects internal/mutable state. This is no surprise since OOP came out of Simula for doing simulations.
Referring to my GP comment, subtyping subsumes inheritance and polymorphism. It is orthogonal to mutability. As an illustrative example, the Java Collection Framework makes significant use of inheritance and polymorphism, but could as well be reduced to immutable collections.
I really disagree. You don’t need polymorphism or inheritance. The core of OOP is objects and encapsulation. Putting behaviour next to the data. It has nothing to do with mutability.
Regarding your first point, OOP without subtyping has typically been referred to as object-based rather than object-oriented.
Sure, I just think that’s being pedantic.
> Sooner or later you come across something you need and there is no library for it. Then you are forced to start messing around with FFI and whatnot.
I agree that it's always a little risky to bet on a young language. But I think Gleam is doing a good job of positioning itself as a smaller risk by sitting on the tried-and-true BEAM virtual machine and Javascript runtimes. If worst comes to worst you could export your compiled Gleam as Erlang or JS and it's quite readable.
And Gleam's FFI with Erlang, Elixir and Javascript is pretty good. I don't think it will take long for a wide variety of packages from those platforms to become available on the Gleam package manager. Doing your own FFI is hardly intimidating - it's essentially just writing type definitions for the functions you need.
Another factor giving me hope is that the language appears to be mostly 'done'. The author has carefully considered a minimal feature set and appears to be sticking to it, making it one of the simplest (typed) languages I've ever used syntax-wise. I think this bodes well for future growth, stability and maintainability.
I agree that it's always a little risky to bet on a young language. But I think Gleam is doing a good job of positioning itself as a smaller risk by sitting on the tried-and-true BEAM virtual machine and Javascript runtimes. If worst comes to worst you could export your compiled Gleam as Erlang or JS and it's quite readable.
And Gleam's FFI with Erlang, Elixir and Javascript is pretty good. I don't think it will take long for a wide variety of packages from those platforms to become available on the Gleam package manager. Doing your own FFI is hardly intimidating - it's essentially just writing type definitions for the functions you need.
Another factor giving me hope is that the language appears to be mostly 'done'. The author has carefully considered a minimal feature set and appears to be sticking to it, making it one of the simplest (typed) languages I've ever used syntax-wise. I think this bodes well for future growth, stability and maintainability.
Half-OT: Is there any effort on getting BEAM on WebAssembly? There was Lumen/Firefly, but the repo got archived a few months ago.
> the "flattening" above seems unnecessary but I could not avoid it since "Result#map" wraps the Result in another Result (I could not find a flat_map).
In Gleam, this is called `result.try`[1]
[1] https://hexdocs.pm/gleam_stdlib/gleam/result.html#try
In Gleam, this is called `result.try`[1]
[1] https://hexdocs.pm/gleam_stdlib/gleam/result.html#try
A perfect hands-on introduction. Gleam is on the paper the "Simpler Rust". Yet very powerful. But it's so incredible hard to become relevant in the programming language world. As others have said: Typescript (esp. with Deno) is not that bad. Yes, error handling is miles away from Gleam, but is this enough for people to make the switch?
Gleam is on the paper the "Simpler Rust"
I've heard this sentiment expressed a lot, but I don't understand it.
Rust is unique because it is a relatively high-level language that at the same time does constrain you in the least possible ways. It doesn't require a runtime, it has no mandatory garbage collector, it runs on a wide variety of hardware platforms and operating systems. Rust is not only suitable to write embedded software, operating systems, web applications and web frontends, it is good at each - it might not be perfect or the best in each category, but it is astonishingly good. And finally it manages to be like that, being a relatively boring language even - familiar syntax, modern features but from a research perspective nothing fancy.
There will always be new languages that have their niche, but to be a "Rust, just X" it will have to be as general purpose as Rust already is.
I've heard this sentiment expressed a lot, but I don't understand it.
Rust is unique because it is a relatively high-level language that at the same time does constrain you in the least possible ways. It doesn't require a runtime, it has no mandatory garbage collector, it runs on a wide variety of hardware platforms and operating systems. Rust is not only suitable to write embedded software, operating systems, web applications and web frontends, it is good at each - it might not be perfect or the best in each category, but it is astonishingly good. And finally it manages to be like that, being a relatively boring language even - familiar syntax, modern features but from a research perspective nothing fancy.
There will always be new languages that have their niche, but to be a "Rust, just X" it will have to be as general purpose as Rust already is.
It’s pretty easy to understand. The syntax is similar and it uses a lot of the same patterns, but it’s a lot lighter weight.
Glad you love Rust, but it is not remotely straightforward or “boring” — there’s a lot of hidden magic behind idiomatic Rust. And I wouldn’t call it “astonishingly good” for many of the use cases you mention. It can do all those things, but often not easily.
Glad you love Rust, but it is not remotely straightforward or “boring” — there’s a lot of hidden magic behind idiomatic Rust. And I wouldn’t call it “astonishingly good” for many of the use cases you mention. It can do all those things, but often not easily.
Yes, Gleam and Rust are very different in the use-cases they address, performance etc. They share superficial syntax, which is why people think they're similar. The other main similarity is a focus on sum-types and pattern matching, which people associate with Rust but is really an ML borrowing. That's really where the similarities end.
I enjoy both. Rust for its performance and close-to-metalness, Gleam for its delightful simplicity. It really is a tiny language, and very tastefully designed.
I enjoy both. Rust for its performance and close-to-metalness, Gleam for its delightful simplicity. It really is a tiny language, and very tastefully designed.
As an elixir developer I'm so jealous at Gleam (but stay with Elixir because ecosystem and phoenix)
You can use Gleam from Elixir. I wanted to use lpil's jot library and it was pretty seamless.
https://blog.appsignal.com/2024/07/23/enhancing-your-elixir-...
https://blog.appsignal.com/2024/07/23/enhancing-your-elixir-...
As always put together perfectly. Not only fun to read, but also a new item on my todo list.
It seems to me that Scala has all the features that Gleam has. And they both run in VM's. Scala is not very popular and Gleam is less popular that that. Someone must really love learning a new language to learn Gleam. I respect it very much.
Scala is known for being multi-paradigm and quite complex, with competing factions promoting different Best Ways of Doing Things. Gleam is designed to be small and simple with a single clear path for getting things done. Apart from that, Gleam leans heavily on Erlang's actor model, which IMO is one of the greatest successes of language design to date.
> Scala is ... quite complex
Do you mean the Scala language is complex or the Scala libraries (not the Scala API) that people created (e.g. Cats, Akka ...) are complex? If you say that the Scala language is complex, could you give an example?
> Erlang's actor model ... is one of the greatest successes of language design to date IMO, if you work within 1 VM, the thread model is closest to us as almost all languages have it. How many languages the actor model is implemented in? I know Erlang, Scala. What else?
> Erlang's actor model ... is one of the greatest successes of language design to date IMO, if you work within 1 VM, the thread model is closest to us as almost all languages have it. How many languages the actor model is implemented in? I know Erlang, Scala. What else?
I worked with Scala professionally once and agree it’s very similar. Honestly what put me off Scala the most were the atrocious compile times, it was like working with big complex C++ projects in that respect. Sorry but my time is more valuable than that.
Gleam compiles very fast - I believe the language has been designed in part to enable this. No context-dependent grammar, etc.
Compile times, lots of backwards compatibility breaking, and the forced functional everything from the community even though it was designed to be a blend of OO and FP.
Gleam is great. I think adoption will highly depend on developer tooling, LSP, ide integration etc.
The experience is alright now but it has to get better to go mainstream (if that's even desired). If I had time I'd love to contribute.
The experience is alright now but it has to get better to go mainstream (if that's even desired). If I had time I'd love to contribute.
[deleted]
From https://gleam.run :
> Black lives matter. Trans rights are human rights. No nazi bullsh*t.
I agree, but I do not agree with painting people that disagree as 'Nazi'.
*edit: that quote was from the Gleam website, not the website linked.
> Black lives matter. Trans rights are human rights. No nazi bullsh*t.
I agree, but I do not agree with painting people that disagree as 'Nazi'.
*edit: that quote was from the Gleam website, not the website linked.
I would be with you till I experienced South Korea.
Here in South Korea, there is institutionalized racism or something we call as institution enabled racism. People who are not Korean or white aren't even allowed in most clubs or jobs and it isn't illegal to do so.
Labeling deters bringing exclusionary views into tech projects, It could be just words, but I am happy to see the privileged society at least care for the minority in the west. I wish there was more of this in Korean tech websites, but xenophobia is so ingrained that people don't realise that it is wrong. People openly admit that they are xenophobic but don't see anything wrong with it.
In korea, labeling someone a nazi doesn't work as they don't care and can't relate. But the label that works here is calling someone "poor" or "ugly".
Here in South Korea, there is institutionalized racism or something we call as institution enabled racism. People who are not Korean or white aren't even allowed in most clubs or jobs and it isn't illegal to do so.
Labeling deters bringing exclusionary views into tech projects, It could be just words, but I am happy to see the privileged society at least care for the minority in the west. I wish there was more of this in Korean tech websites, but xenophobia is so ingrained that people don't realise that it is wrong. People openly admit that they are xenophobic but don't see anything wrong with it.
In korea, labeling someone a nazi doesn't work as they don't care and can't relate. But the label that works here is calling someone "poor" or "ugly".
Are they killing unwanted minorities and political dissidents on an industrial scale? No, they aren’t. Ergo, they aren’t N*is. Labeling them as such is unfair to them and an insult to the memory of those killed by the actual kind.
There can be widespread bigotry that falls far far short of N*ism. Words and precision matter.
There can be widespread bigotry that falls far far short of N*ism. Words and precision matter.
Not letting people into clubs is bad, but it’s not the same thing as starting the most destructive war in history while also murdering millions of innocent people. So no, racist Koreans are not comparable to nazis.
Very uninformed take.
There are still people out in the world that call themselves Nazis. Its not directly comparing "todays" people to those that started world war II.
Its calling out white nationalist by the name some of them have chosen for themselves.
There are still people out in the world that call themselves Nazis. Its not directly comparing "todays" people to those that started world war II.
Its calling out white nationalist by the name some of them have chosen for themselves.
Yes, they should just say on there website:
We don't tolerate racism of any kind.
Unless they want to express something different with their "No nazi bullsh*t". Unfortunately plain and clear statements are not used often. But (esp. younger) people are more often echoing political main stream slogans. That is by the way the key thing to understand when talking about the history of Nazis.
We don't tolerate racism of any kind.
Unless they want to express something different with their "No nazi bullsh*t". Unfortunately plain and clear statements are not used often. But (esp. younger) people are more often echoing political main stream slogans. That is by the way the key thing to understand when talking about the history of Nazis.
The statement ("No nazi bullsh*t") is an uninformed political slogan directed at all non-left-wing opinions. There's a lot we all must learn from the history of Nazis. Or the history of the USA (genocide of the Native American and slavery of millions of Africans).
If they are against racism, why don't they just write this? Because they want to sneak in a political statement. That's where they lost me.
If they are against racism, why don't they just write this? Because they want to sneak in a political statement. That's where they lost me.
What is even happening in this comment?
You can learn from history _and_ berate Nazis. Those aren't mutually exclusive.
I don't know where you're from, but there are also _modern_ Nazis who proudly identify as such and they can and should be told to fuck off.
You can learn from history _and_ berate Nazis. Those aren't mutually exclusive.
I don't know where you're from, but there are also _modern_ Nazis who proudly identify as such and they can and should be told to fuck off.
I think if I were reading a statement like "no nazi bullshit" and thought it applied to me, I'd probably wonder "are we the baddies?"[1].
1: https://www.youtube.com/watch?v=ToKcmnrE5oY
1: https://www.youtube.com/watch?v=ToKcmnrE5oY
The person you replied to doesn’t suggest anywhere that they think the comment applies to them.
Sadly I have seen this all too often. A lot of seemingly "anti-fascist" activism is just a saviour complex.
Consider a great evil, claim to be against that great evil and become the greatest hero in the process. The problem is that we are running of Nazis, so the bar for someone being called a Nazi or fascist keeps dropping, because of the great demand by saviours.
Consider a great evil, claim to be against that great evil and become the greatest hero in the process. The problem is that we are running of Nazis, so the bar for someone being called a Nazi or fascist keeps dropping, because of the great demand by saviours.
It's off putting. It should say "please be respectful and polite toward one another".