Hacker News Reader

Comment by salimmadjd | Hacker News Reader

Looks interesting. I only wish it used Haskell's type annotation. I've been learning Haskell recently and I'm really liking how easy it is to read and digest codes.

I feel like Haskell in general is yielding much cleaner code and once you start learning it, so much easier to follow the logic of a code and not get lost in all the noodles of commas, parentheses and unneeded brackets.

View on HN

Hi! I'm the author of Gleam!

Originally Gleam had a more Haskell-like (or rather a more OCaml-like) syntax. Over time people generally expressed a preference for a more familiar C-like syntax, citing the unfamiliar syntax making it seem unapproachable.

Originally I thought these thoughts on syntax were unimportant (after all, syntax doesn't really matter) but after looking at the success of ReasonML (an alternative syntax for OCaml) and how it brought FP to a much wider audience, I decided that it would make sense to use this more C style syntax.

Gleam aims to be very accessible and welcoming to as many people as possible, so in this area we've gone for something I personally prefer less as it it may help others more.

It's why I am learning Zig instead of Rust really. I think it is more like C, and is a lot less to bite off. Probably a wise choice for Gleam, but I do like Haskell/Idris syntax too wrt to types.

There is quite a learning curl on Rust, for sure!

I was always more of a Haskell user and had little C experience, so I found Rust a good fit for me. The type systems are quite similar :)

For someone who is unfamiliar with ML-type languages, can you summarize some good use-cases for Gleam?

i.e. why would I learn and/or use this language?

Or is that too open-ended a question? I work with Elixir so I'm a big BEAM/OTP proponent, so I am curious to know about Gleam..

Existing BEAM languages such as Elixir and Erlang do an incredible job when it comes to scaling and fault tolerance, however I believe that other languages do a better job at providing the programmer with a fast feedback loop for rapid development and refactoring.

When refactoring in an ML language I like to think the compiler as being like a pair programming partner with excellent knowledge of the codebases. You indicate what change you wish to make, and the compiler shows you how to update the code to make that change quickly and safely with minimal testing.

I think ML's static analysis (potential error detection) and the BEAM's fault tolerance (implicit error handling) can compliment each other well, and I want to explore that space in Gleam.

I'm hoping to create a langauge that brings a new set of advantages to the BEAM ecosystem, to sit alongside Elixir and Erlang.

I've more detail in my conference talk from Code Mesh last year: https://www.youtube.com/watch?v=HaKR2kt-DXI

Thank you for all this detail, for the link to the talk.. :)

Martin Odersky followed the same logic with Scala and he has since expressed some regret, especially as more and more people become familiar with Python, which is more succinct:

https://github.com/lampepfl/dotty/issues/2491

I remember that post, interesting stuff! :) I'm hoping to be more concise than Scala and Java, and to have a much simpler grammar. It is a tricky middleground to reach

Worry not! He is already doing it - Scala 3 will be indentation based:

https://dotty.epfl.ch/docs/reference/other-new-features/inde...

> Gleam aims to be very accessible and welcoming to as many people as possible

As a Haskell developer I can appreciate this. We really take pride in our terse syntax, but it can be really jarring for people not familiar with an ML-style language. You are going to rob a lot of people the experience of using your implementation if you don't cater to their familiarness with other more common syntax. This is my first time hearing about your project, but I sincerely look forward to reading more about it!

Thank you for the support. I'm feeling positive about the trade off here with syntax, hopefully it pays off.

fair point! I guess we can also look at the success of Golang and attribute it to similarity to C.

I remember I was able to do all the Go's online tutorial in couple of hours because it was so familiar to me.

To your point, if you want to make BEAM more accessible to broader audience, making it more C like will increase the odds of success.

Thanks for the detailed reply! I'll keep an eye on it for sure. I never liked Elixir's syntax, so maybe Gleam will be the way to go if someone like me wants to play with Phoenix.

Phoenix relies heavily on Elixir's metaprogramming features, so we'll always be very limited in what we can with it from Gleam I'm afraid.

One day I would like to have a similar convention based framework for Gleam, but we have a long way to go before then.

Well, you can't make everyone happy. Personally, I've started with the C family of languages (C, C++, C#, bit of Java), but after going through Python, Ruby and Elixir I never want to go back to curly braces. The other thing that puts me off is mixing types into the declarations - I treat types as comments and only reach for them if I need to dig deeper; in most of the cases the names of the arguments are self explanatory and types make it really hard for me to parse the function declaration. So instead of this:

  pub fn any(tree: Tree(a), check: fn(a) -> Bool) -> Bool

I'd really prefer something like this (preferably with a syntax highlighter that would grey out the types):

  fn(Tree(a), fn(a) -> Bool) -> Bool
  pub fn any(tree, check)

For some people, including myself, type annotations in Python are killing the spirit of the language. For me, there's no way to format those declarations to look reasonable, except for doing it like in Haskell or Elixir (@type).

While what you've suggested is my preference I've found us to be in the minority, so we moved away from it.

The syntax well not be changing again I'm afraid.

It's true, I like the feel of Haskell type annotations as well, but I'm working with js/flow in day-to-day job; finding mysqlf moving towards those one-line-type-annoations to mimick Haskell, I'm surprised flow actually handles most of the code, even not so trivial ones; inference is good enough that those one liners are most of the time all that's needed, examples are here [1] [2] [3] if somebody wants to peek.

[1] https://github.com/appliedblockchain/tsql/ [2] https://github.com/appliedblockchain/parser-combinators [3] https://github.com/appliedblockchain/assert-combinators

Check out https://github.com/purerl/purerl

Reply on news.ycombinator.com