I'd say if you know and like Rust, then Gleam should be easy to pick up but otherwise I'd try Elixir. You can learn most of the language in a few days and be experimenting with BEAM and supervision concepts basically on day one. As a learning exercise I think its worth peoples' time because actors/processes are one of the concurrency models you don't see everywhere but solve interesting problems well.

I don't think that's the case, Rust and Gleam have almost nothing in common beyond having static type systems, and those type systems are very different too.

https://gleam.run/frequently-asked-questions/#How-does-Gleam...

You don't think that Gleam has more familiar syntax to a Rust dev than Elixir? Or that the type system might feel more familiar?

I think a Rust programmer is more likely to prefer Gleam to Elixir, but I don't think there is much link between Gleam and Rust, and I especially do not thing that Gleam should only be considered over Elixir if you are already a Rust programmer.

So I said:

> I'd say if you know and like Rust, then Gleam should be easy to pick up

And you think that:

> a Rust programmer is more likely to prefer Gleam to Elixir

Are we maybe splitting hairs here?

You said: >I'd say if you know and like Rust, then Gleam should be easy to pick up but otherwise I'd try Elixir.

This is way too strong and narrow statement. Gleam is statically typed garbage collected language, closer to OCaml than Rust. Elixir if you like dynamically typed instead.

Obligatory comment that elixir is now gradually typed: https://news.ycombinator.com/item?id=48388324

Tbh gradual typing sounds like a nightmare. Probably impossible to implement correctly, whatever your definition of "correctly".

Nah, the gradual angle is not what makes a type system tricky to implement. Plus we have published a few papers discussing how we are typing Elixir and how our approach is sound.

It's very possible that I'm misunderstanding you! I'm mostly just saying that Gleam is very unlike Rust, so if you pick it or avoid it for Rust related reasons you may not be making the most informed decision.

The languages that Gleam is most like might be Standard ML, OCaml, Elm, and F#.

You seem to be interpreting the statements as technical comparisons of the languages, but ch4s3 was (by my read) commenting on the overall ability of a programmer to jump from one language to another.

That is: they aren't similar languages on a technical level, but if you know Rust, you should be able to make the jump to Gleam pretty quickly.

Aye, I am saying that jumping from Rust to Gleam isn't easy because the languages are so different. "How do I do X in Gleam like I would in Rust" is one of the most common categories of support question from newcomers who assumed they were similar.

It can take a moment to understand that things are done quite differently in the two languages due to being so different: https://gleam.run/frequently-asked-questions/#How-does-Gleam...

> The languages that Gleam is most like might be Standard ML, OCaml, Elm, and F#.

And guess which languages inspired several things in Rust.

The ML family clearly inspired Rust greatly, but the end result is very different.

I use Rust and prefer Elixir over Gleam because Elixir has Lisp-style macros (Gleam doesn't), uses OTP directly, has the fantastic IEx REPL (Gleam has no counterpart), and has Phoenix, the best web framework I've ever used.

Yes, exactly my point! Being a Rust user doesn’t mean you are going to prefer or even understand Gleam.

> I'd say if you know and like Rust, then Gleam should be easy to pick up

I think by sentiments like this, people mean if you know unions, records, and pattern matching then you'll more easily pick up another language that has unions, records, and pattern matching.

Yep, that's essentially what I mean. There's even this official cheatsheet[1] that shows a lot of overlap.

[1] https://gleam.run/cheatsheets/gleam-for-rust-users/

This shows only the base syntax and has nothing of the language functionality, so is incapable of showing overlap between the languages.