Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Gleam Programming Language

gleam.run

Post reply on HN
Print view View original

41–50 of 189 posts

Re: The Gleam Programming Language

#41

Post by pkos98 »

nesarkvechnep wrote: post #36
pkos98 wrote: post #27

Coming from Elixir, I gave Gleam a try for a couple of days over the holidays. Reasons I decided not to pursue: - No ad-hoc polymorphism (apart from function overloading IIRC) means no standard way of defining how things work. There are not many conventions yet in place so you won’t know if your library supports eg JSON deserialization for its types - Coupled with a lack of macros, this means you have to implement ev…

I’ve been doing Elixir for 9 years, 5 professionally. Nobody cares about ad-hoc polymorphism. The community doesn’t use protocols except “for data”. Whatever that means. Global singleton processes everywhere. I’m really discouraged by the practices I observe but it’s the most enjoyable language for me still.

Well, for the specific example I gave (JSON serialization), you certainly do care whether Jason.Encoder is implemented for a struct.

Re: The Gleam Programming Language

#42

Post by phplovesong »

Gleam is nice. However it is still very lacking in the stdlib. You will need lots of dependencies to build something usable. I kind of wish Gleam could target something like Go, then you would have the option to go native without a "heavy" VM like the BEAM.

Re: The Gleam Programming Language

#43

Post by hayleighdotdev »

pkos98 wrote: post #27

Coming from Elixir, I gave Gleam a try for a couple of days over the holidays. Reasons I decided not to pursue: - No ad-hoc polymorphism (apart from function overloading IIRC) means no standard way of defining how things work. There are not many conventions yet in place so you won’t know if your library supports eg JSON deserialization for its types - Coupled with a lack of macros, this means you have to implement ev…

> Gleam doesn’t have access to most of the Erlang / Elixir ecosystem out of the box.

Gleam has access to the entire ecosystem out of the box, because all languages on the BEAM interoperate with one another. For example, here's a function inside the module for gleam_otp's static supervisor:

    @external(erlang, "supervisor", "start_link")
    fn erlang_start_link(
      module: Atom,
      args: #(ErlangStartFlags, List(ErlangChildSpec)),
    ) -> Result(Pid, Dynamic)
As another example, I chose a package[0] at random that implements bindings to the Elixir package blake2[1].

    @external(erlang, "Elixir.Blake2", "hash2b")
    pub fn hash2b(message m: BitArray, output_size output_size: Int) -> BitArray

    @external(erlang, "Elixir.Blake2", "hash2b")
    pub fn hash2b_secret(
      message m: BitArray,
      output_size output_size: Int,
      secret_key secret_key: BitArray,
    ) -> BitArray
It's ok if you don't vibe with Gleam – no ad-hoc poly and no macros are usually dealbreakers for certain types of developer – but it's wrong to say you can't lean on the wider BEAM ecosystem!

[0]: https://github.com/sisou/nimiq_gleam/blob/main/gblake2/src/g...

[1]: https://hex.pm/packages/blake2

Re: The Gleam Programming Language

#44

Post by misiek08 »

pjmlp wrote: post #33

Glean is interesting from language nerd point of view, however I never had a reason to use Erlang at work, and probably never will, and I suspect that relates to most folks.

It’s funny how we avoid the technologies we can’t complain about much. Seeing an Elixir projects on production I always wonder „why we are not using it more often”. More talking about Elixir here.

For Elixir I saw a simple distributed job scheduler - it was dead simple in code and was ripped, because it didn’t require maintenance for ~8 years just working without issue and people who knew anything about it left company or switched part of company and acted as they forgot everything.

The other example is medium sized (in terms of features and code) web app - maintained by <30 people now, delivering more than 800 people at the other company, no stress, no issues and with great DX because of the BEAM (other company is drowning in JVM based nano-services).

Re: The Gleam Programming Language

#45

Post by phplovesong »

tombert wrote: post #8

I remember playing with Alpaca a few years ago, and it was fun though I didn’t find the resulting code to significantly less error-prone than when I wrote regular Erlang. It’s inelegant, but I find that Erlang’s quasi-runtime-typing with pattern matching gets you pretty far and it falls into Erlang’s “let it crash” philosophy nicely. Honestly, and I realize that this might get me a bit of flack here and that’s obviou…

You seem to have a fundamental misunderstanding about type systems. Most (the best?) typesystems are erased. This means they only have meaning "on compile time", and makes sure your code is sound and preferrably without UB.

The "its only bits" thing makes no sense in the world of types. In the end its machine code, that humans never (in practice) write or read.

Re: The Gleam Programming Language

#46

Post by nesarkvechnep »

pkos98 wrote: post #41
nesarkvechnep wrote: post #36

Earlier quoted context omitted.

I’ve been doing Elixir for 9 years, 5 professionally. Nobody cares about ad-hoc polymorphism. The community doesn’t use protocols except “for data”. Whatever that means. Global singleton processes everywhere. I’m really discouraged by the practices I observe but it’s the most enjoyable language for me still.

Well, for the specific example I gave (JSON serialization), you certainly do care whether Jason.Encoder is implemented for a struct.

Yes, I just ranted, sorry. I share your view about Gleam.

Re: The Gleam Programming Language

#47

Post by pkos98 »

hayleighdotdev wrote: post #43
pkos98 wrote: post #27

Coming from Elixir, I gave Gleam a try for a couple of days over the holidays. Reasons I decided not to pursue: - No ad-hoc polymorphism (apart from function overloading IIRC) means no standard way of defining how things work. There are not many conventions yet in place so you won’t know if your library supports eg JSON deserialization for its types - Coupled with a lack of macros, this means you have to implement ev…

> Gleam doesn’t have access to most of the Erlang / Elixir ecosystem out of the box. Gleam has access to the entire ecosystem out of the box, because all languages on the BEAM interoperate with one another. For example, here's a function inside the module for gleam_otp's static supervisor: @external(erlang, "supervisor", "start_link") fn erlang_start_link( module: Atom, args: #(ErlangStartFlags, List(ErlangChildSpec)…

Isn’t this the proof of my point - How does the need of writing „@external“ annotations by hand not contradict the point of being „out of the box“ usable?

Hayleigh, when I asked on the discord about how to solve my JSON problem in order to get structured logging working, you replied that I’m the first one to ask about this.

Now reading this: > It's ok if you don't vibe with Gleam – no ad-hoc poly and no macros are usually dealbreakers for certain types of developer

Certainly makes me even more feel like gatekeeping.

Re: The Gleam Programming Language

#48

Post by nesarkvechnep »

krainboltgreene wrote: post #40
nesarkvechnep wrote: post #36

Earlier quoted context omitted.

I’ve been doing Elixir for 9 years, 5 professionally. Nobody cares about ad-hoc polymorphism. The community doesn’t use protocols except “for data”. Whatever that means. Global singleton processes everywhere. I’m really discouraged by the practices I observe but it’s the most enjoyable language for me still.

IMHO this is an education problem.

Problem which plagues 90% of the people? How to overcome it?

Re: The Gleam Programming Language

#49

Post by folex »

tombert wrote: post #26
the-grump wrote: post #25

Earlier quoted context omitted.

With all due respect, you can use all of those languages and their type systems without recognizing their value. For ensuring bits don't get lost, you use protocols like TCP. For ensuring they don't silently flip on you, you use ECC. Complaining that static types don't guard you against lost packets and bit flips is missing the point.

With all due respect, you really do not understand these protocols if you think “just use TCP and ECC” addresses my complaints. Again, it’s not that I have an issue with static types “not protecting you”, I am saying that you have to encode for this uncertainty regardless of the language you use. The way you typically encode for that uncertainty is to use an algebraic data type like Maybe or Optional. Checking agains…

> ends up being the same checks you would be doing with a dynamic language

Sure thing. Unless dev forgets to do (some of) these checks, or some code downstream changes and upstream checks become gibberish or insufficient.

Re: The Gleam Programming Language

#50

Post by hayleighdotdev »

tombert wrote: post #8

I remember playing with Alpaca a few years ago, and it was fun though I didn’t find the resulting code to significantly less error-prone than when I wrote regular Erlang. It’s inelegant, but I find that Erlang’s quasi-runtime-typing with pattern matching gets you pretty far and it falls into Erlang’s “let it crash” philosophy nicely. Honestly, and I realize that this might get me a bit of flack here and that’s obviou…

> Honestly, and I realize that this might get me a bit of flack here and that’s obviously fine, but I find type systems start losing utility with distributed applications. Ultimately everything being sent over the wire is just bits.

Actually Gleam somewhat shares this view, it doesn't pretend that you can do typesafe distributed message passing (and it doesn't fall into the decades-running trap of trying to solve this). Distributed computing in Gleam would involve handling dynamic messages the same way handling any other response from outside the system is done.

This is a bit more boilerplate-y but imo it's preferable to the other two options of pretending its type safe or not existing.

Post reply on HN