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.

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.. :)

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.