4 ms·

I honestly gave gleam a serious look, considering it to build a system that might really benefit from it's concurrency model. However the lack of Macros/macro-s

I honestly gave gleam a serious look, considering it to build a system that might really benefit from it's concurrency model. However the lack of Macros/macro-style reflection capabilities really put me off. It makes working with SQL databases needlessly verbose. It's the same with go, though go posses the capabilities to directly unmarshal SQL rows into a structure with tags, it's far from straightforward.

Alupis 2y ago
This is the sentiment many have when transitioning from OOP -> FP paradigms. That's not to say ORM's don't exist in FP, but they are not nearly as common because their concept doesn't directly translate into what you expect from a functional language. That is to say this is not a Gleam problem, it is a FP problem, if we can even call it a problem (it's mostly just different).
- throwawaymaths 2y ago
  Lisp and elixir, Julia are all fps with macros? Hell even Erlang has macros
  - Alupis 2y ago
    I was speaking to the ORM situation, or lack-thereof the parent seemed to be expressing. Regarding macros - Gleam has stated they are interested in adding metaprogramming, but it's not a huge priority because of the goals of the language. Macros, and metaprogramming in general have a tendency to complicate a language, and encourages ad-hoc DSL's. One of Gleam's goals is to be dead simple to pick up, read, and contribute - metaprogramming makes that much harder. Macros are not necessary, even if their absence is a bit of a shock at first. I used to firmly think they were necessary, but now my mind has changed on this for the most part.
- written-beyond 2y ago
  There are two ways to understand your reply, one is that you're talking ORMs that provide query building as an alternative to writing raw SQL. The other is you're talking just about the deserialisation into structures. If what you meant was the first one then, no I'm not expecting anything like that. I honestly like using a language that gets off of the way and let's me focus on what I want to build. I've done very little OOP and I've written a lot of Rust. There are many situations where I feel like r rusts verbosity is limiting my freedom but the grind of unmarshaling hashmaps into structures is way too much for me. Why shouldn't I want to use my languages typing support to help me write more maintainable code? I can hardly get over how dart sometimes outright refuses to cast Object types to dynamic types without some syntactical voodoo.
  - Alupis 2y ago
    You might be interested in looking at the Squirrel library for Gleam[1]. It kind of reverses the SQL problem in a very nice, elegant way I've found. It gets rid of some of the issues you are bringing up, which are quite valid. [1] https://hexdocs.pm/squirrel/ https://hexdocs.pm/squirrel/
- lawn 2y ago
  Nah this is wrong. Ecto for Elixir is a big counterexample. You're focused on OO ORMs as the way to simplify working with queries, but FP approaches it slightly differently.
lawn 2y ago
For me the big problem with the lack of macros is the unergonomic json conversions. In Rust for example you use a simple declarative approach and it uses the type system to serialize/deserialize properly. But in Gleam you need to do everything manually. Even with libraries that's a ton of manual work you need to do. It's the single reason why I shy away from using Gleam actually.
klabb3 2y ago
> It's the same with go, though go posses the capabilities to directly unmarshal SQL rows into a structure with tags Go also has best-in-class support for code generation. It isn’t as good as the best macro systems, but it works really well in my experience, despite the duct-tape. It also doesn’t obliterate compile times. Check out Ent - it’s a really pleasant “ORM”.

Alupis 2y ago

This is the sentiment many have when transitioning from OOP -> FP paradigms. That's not to say ORM's don't exist in FP, but they are not nearly as common because their concept doesn't directly translate into what you expect from a functional language. That is to say this is not a Gleam problem, it is a FP problem, if we can even call it a problem (it's mostly just different).

throwawaymaths 2y ago
Lisp and elixir, Julia are all fps with macros? Hell even Erlang has macros
- Alupis 2y ago
  I was speaking to the ORM situation, or lack-thereof the parent seemed to be expressing. Regarding macros - Gleam has stated they are interested in adding metaprogramming, but it's not a huge priority because of the goals of the language. Macros, and metaprogramming in general have a tendency to complicate a language, and encourages ad-hoc DSL's. One of Gleam's goals is to be dead simple to pick up, read, and contribute - metaprogramming makes that much harder. Macros are not necessary, even if their absence is a bit of a shock at first. I used to firmly think they were necessary, but now my mind has changed on this for the most part.
written-beyond 2y ago
There are two ways to understand your reply, one is that you're talking ORMs that provide query building as an alternative to writing raw SQL. The other is you're talking just about the deserialisation into structures. If what you meant was the first one then, no I'm not expecting anything like that. I honestly like using a language that gets off of the way and let's me focus on what I want to build. I've done very little OOP and I've written a lot of Rust. There are many situations where I feel like r rusts verbosity is limiting my freedom but the grind of unmarshaling hashmaps into structures is way too much for me. Why shouldn't I want to use my languages typing support to help me write more maintainable code? I can hardly get over how dart sometimes outright refuses to cast Object types to dynamic types without some syntactical voodoo.
- Alupis 2y ago
  You might be interested in looking at the Squirrel library for Gleam[1]. It kind of reverses the SQL problem in a very nice, elegant way I've found. It gets rid of some of the issues you are bringing up, which are quite valid. [1] https://hexdocs.pm/squirrel/ https://hexdocs.pm/squirrel/
lawn 2y ago
Nah this is wrong. Ecto for Elixir is a big counterexample. You're focused on OO ORMs as the way to simplify working with queries, but FP approaches it slightly differently.

lawn 2y ago

For me the big problem with the lack of macros is the unergonomic json conversions. In Rust for example you use a simple declarative approach and it uses the type system to serialize/deserialize properly. But in Gleam you need to do everything manually. Even with libraries that's a ton of manual work you need to do. It's the single reason why I shy away from using Gleam actually.

klabb3 2y ago

> It's the same with go, though go posses the capabilities to directly unmarshal SQL rows into a structure with tags Go also has best-in-class support for code generation. It isn’t as good as the best macro systems, but it works really well in my experience, despite the duct-tape. It also doesn’t obliterate compile times. Check out Ent - it’s a really pleasant “ORM”.