News for hackers. Stuff that matters.
Re:Gleam: a type safe language on the Erlang VM by 698969 on Wednesday November 08, 2023 @12:36AM (#38187156)
The only part that rubs me the wrong way is,

> The pipe operator will first check to see if the left hand value could be used as the first argument to the call, e.g. a |> b(1, 2) would become b(a, 1, 2).

Optimizing for one less _ typed is a really bad trade-off in terms of clarity here.

Re:Gleam: a type safe language on the Erlang VM by xixixao on Wednesday November 08, 2023 @02:08AM (#38187554)
I actually agree, this is the most questionable piece. I prefer (and have argued for in JS) Hack-style pipes, where the value "placement" always has to be specified.

That allows arbitrary expressions on the RHS of the pipe, so for example this would be valid Gleam:

pub fn main() { io.println( "Hello" |> (_ <> " world") ) }

Re:Gleam: a type safe language on the Erlang VM by pharmakom on Wednesday November 08, 2023 @02:14AM (#38187576)
Gleam has curried functions by default so F# style pipes make sense imo.
Re:Gleam: a type safe language on the Erlang VM by hayleighdotdev on Wednesday November 08, 2023 @03:45AM (#38188066)
Gleam doesn't have auto currying! Often folks find this (currying) a bit confusing to wrap their head around when learning functional programming and we don't feel like it really affords you much that couldn't already be achieved with just a little bit more work by the programmer.

Applicative builder APIs are the only thing we've found would be much much better if we had auto currying.

Re:Gleam: a type safe language on the Erlang VM by pharmakom on Wednesday November 08, 2023 @04:49AM (#38188402)
Ah my mistake. So this is a deviation from Elm?
Re:Gleam: a type safe language on the Erlang VM by jcparkyn on Wednesday November 08, 2023 @05:22AM (#38188598)
I think you are confusing Gleam with Gren (a fork of Elm)?
Re:Gleam: a type safe language on the Erlang VM by lpil on Wednesday November 08, 2023 @11:01AM (#38192270)
Gleam did used to have this, but the community collectively decided that it was actually quite annoying in practice to always have to write `_, ` after every function