I’ve been getting into Gleam recently as well, and I’ve also really enjoyed it. (And I also came from Rust!)
The language is too simple.
In my opinion, while it can definitely feel like this at first, this is really one of Gleam’s strengths. Having written only Gleam for a little while, then gone back to eg Rust, I’d forgotten how many unrelated things other languages make you think about. Truly having one way to do things makes Gleam so much easier to read.
But I totally understand that the lack of macros or other complex features can put a few people off (for example, I read that currying is dearly missed).
Specifically related to macros, Louis (the Gleam guy) is not opposed to having a macro system, except that no convincing specific use case has come up that can’t be solved more simply with something else. And especially since macros add so much complexity, it’s a high bar. They wrote a whole post about it.
Also, a somewhat limited form of currying is available by using function captures: my_fun(wibble, _, wobble) is the same thing as fn(x) { my_fun(wibble, x, wobble) }. If you need more arguments you’ll need to do the full anonymous function, but it covers most use cases.
…not opposed to having a macro system, except that no convincing specific use case has come up that can’t be solved more simply with something else.
I feel that this is a bit of a self-fulfilling prophecy. It's true that everything I want to do in Gleam with a macro system could be done without a macro system. Of course, you could say the same thing about Brainfuck — it's Turing complete and any features you might add could be done in another way.
One bit that particularly gets to me is the serialisation/deserialisation story. When I last played with Gleam (about two years ago, so this may be out of date), the recommended solution was using a code generator to write those functions. Personally, saying that you don't need a macro system because you have a code generator is like saying your car doesn't need an engine because you also have a tow truck.
There was a lot that I loved about Gleam. The use statement felt like it could drag people 50% of the way to monads and I've always loved BEAM. I'm not even sure that I would want a true macro system — something like Haskell's Rep and Data.Generics would solve 95% of the places where I wanted a macro in Gleam (or even Rust!). However, seeing code generation touted as the solution soured me on Gleam's future.
I am interested in Gleam and this seems to be a nice introduction.
I really like the concept of the pipeline operator. But as I write more and more Python this days I also love easy iterators. Is there a way to merry pipeline operator with iterators? I would like to be able to split on strings in a streaming fashion (something which is not as seamless in Python either other than re.finditer or io.StringIO for newlines).
I don't like cute ligatures (triangle, arrows etc.) on this site, they make it harder for me to read and understand.
JS to remove it via Web Inspector:
for(const ss of document.styleSheets) for(let i = ss.rules.length - 1; i >= 0; i--) {if(ss.rules[i] instanceof CSSFontFaceRule){ss.removeRule(i)}}
You can use pipelines with iterators, but Gleam doesn't commonly use iterators as they are very slow unless your language's compilation model is able to optimise them away at runtime.
I think pipelines largely fills any need for iterators or streams in Gleam, and the underlying runtime being based on linked lists and immutability (erlang is a lisp, fight me) means that for example filtering a list in a pipeline or stream ends up creating new list nodes as necessary but doesn't mutate any data.
Maybe there are usecases that I haven't thought about, but re.finditer would fit very well into a pipeline.
gavinmorrow | 4 hours ago
I’ve been getting into Gleam recently as well, and I’ve also really enjoyed it. (And I also came from Rust!)
In my opinion, while it can definitely feel like this at first, this is really one of Gleam’s strengths. Having written only Gleam for a little while, then gone back to eg Rust, I’d forgotten how many unrelated things other languages make you think about. Truly having one way to do things makes Gleam so much easier to read.
Specifically related to macros, Louis (the Gleam guy) is not opposed to having a macro system, except that no convincing specific use case has come up that can’t be solved more simply with something else. And especially since macros add so much complexity, it’s a high bar. They wrote a whole post about it.
Also, a somewhat limited form of currying is available by using function captures:
my_fun(wibble, _, wobble)is the same thing asfn(x) { my_fun(wibble, x, wobble) }. If you need more arguments you’ll need to do the full anonymous function, but it covers most use cases.rprospero | 6 minutes ago
I feel that this is a bit of a self-fulfilling prophecy. It's true that everything I want to do in Gleam with a macro system could be done without a macro system. Of course, you could say the same thing about Brainfuck — it's Turing complete and any features you might add could be done in another way.
One bit that particularly gets to me is the serialisation/deserialisation story. When I last played with Gleam (about two years ago, so this may be out of date), the recommended solution was using a code generator to write those functions. Personally, saying that you don't need a macro system because you have a code generator is like saying your car doesn't need an engine because you also have a tow truck.
There was a lot that I loved about Gleam. The use statement felt like it could drag people 50% of the way to monads and I've always loved BEAM. I'm not even sure that I would want a true macro system — something like Haskell's Rep and Data.Generics would solve 95% of the places where I wanted a macro in Gleam (or even Rust!). However, seeing code generation touted as the solution soured me on Gleam's future.
hawski | 6 hours ago
I am interested in Gleam and this seems to be a nice introduction.
I really like the concept of the pipeline operator. But as I write more and more Python this days I also love easy iterators. Is there a way to merry pipeline operator with iterators? I would like to be able to split on strings in a streaming fashion (something which is not as seamless in Python either other than re.finditer or io.StringIO for newlines).
I don't like cute ligatures (triangle, arrows etc.) on this site, they make it harder for me to read and understand. JS to remove it via Web Inspector:
lpil | 4 hours ago
You can use pipelines with iterators, but Gleam doesn't commonly use iterators as they are very slow unless your language's compilation model is able to optimise them away at runtime.
krig | 5 hours ago
I think pipelines largely fills any need for iterators or streams in Gleam, and the underlying runtime being based on linked lists and immutability (erlang is a lisp, fight me) means that for example filtering a list in a pipeline or stream ends up creating new list nodes as necessary but doesn't mutate any data.
Maybe there are usecases that I haven't thought about, but
re.finditerwould fit very well into a pipeline.krig | 5 hours ago