alt Hacker NewsI 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.
Replies
> 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”.
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.
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).