Live data from Hacker News

Gleam OTP – Fault Tolerant Multicore Programs with Actors

github.com

81–89 of 89 posts

Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors

#81
post #78

I learned some Gleam a while ago, my familarity with F# helped, but I didn't find a use case for it. Some while ago I wanted to play with raw sockets so I figured, why not Gleam, its binary parsing syntax will be handy so I looked into the erlang sockets module and attempted to write some ffi wrappers for the necessary functions. Turns out it is not as straight forward, especially that the definitions on erlang side…

The semantics of Elixir are much closer to Erlang than Gleam is and Elixir handles dynamic types on the same manner as Erlang, so interop is very seamless (much more than with Gleam).

Don't pay too much mind on the ruby-like syntax. I also prefer the syntax of Gleam, but Elixir really isn't bad when you get used to it.

JSON handling in Gleam was also something that annoyed me and made be scrap a hobby project and go with Elixir instead. I wish they had a proper macro system so you could derive json encoding/decoding like you do in Rust...

Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors

#82
post #44

Earlier quoted context omitted.

how would you get a deadlock with non-blocking requests ?

I never said you did ?

not you per-se no.

but this whole thread started with deadlock on remote calls, and i was curious about how that could be with async calls.

Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors

#83

gleam would be taken more seriously if they didnt plaster their strong political opinions on the project page..i do not understand why they need to talk about politics on a tech project page..this is not about agreeing or disagreeing with the viewpoints..just keep it out of your professional discourse if you want people to take you or your work seriously...otherwise it just deviates the discourse unnecessarily

[deleted]

Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors

#84

Is there any beam language that has regular 'for','while' loops and good OTP support?

Just write 'for' and 'while' yourself if you need it. Here is ‘for’ in Elm/Gren:

    for : Int -> Int -> Int -> (Int -> msg) -> List msg
    for start stop step action =
        let
            range =
                if step > 0
                then List.range start (step) (stop - 1)
                else if step  List.reverse
                else []
        in
            List.map action range

It should be just as trivial to write this in Gleam.

Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors

#85
post #60
post #59

Earlier quoted context omitted.

I disagree. I started with Elixir and its OTP resources are really good. Books like Elixir in Action do a great job. I read Programming Erlang later, but it was just for fun, and I knew most things already at that point.

I've used Elixir since 2015 and in fact learned it first. I still think "Programming Erlang" is a much better book than any other for actually learning Erlang and BEAM/OTP principles. Erlang as a language is simpler, leaving more time and energy for learning the actual important bits about OTP.

Also Elixir abstracts even more of the OTP and does some automagical stuff with it. Erlang is more explicit, which is better for learning, IMO.

Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors

#86

Is there any beam language that has regular 'for','while' loops and good OTP support?

I think that's going to be hard to find, depending on your definition of 'regular', tbh.

The BEAM's grown up along with Erlang and so the culture and optimisations are built up all around function application, list processing, recursion, and pattern matching etc.

https://github.com/llaisdy/beam_languages is a decent list of the diverse languages that have been implemented on it, but nothing quite like 'regular for and while loops'.

The BEAM itself is a plain aul register machine though, so it could be done!

https://www.erlang.org/blog/a-brief-beam-primer/

Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors

#87
post #82

Earlier quoted context omitted.

I never said you did ?

not you per-se no. but this whole thread started with deadlock on remote calls, and i was curious about how that could be with async calls.

Oh, I think that the mailbox access a process has can wont block unless its full, in which case the message will be dropped.

I think you can check message_queue_len using erlang:process_info/2 to find the mailbox size and simply back off, or fail noisly.

Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors

#88
post #23

Earlier quoted context omitted.

This is a wild take. It's one thing to criticise the BEAM for things it's bad at, it's another to criticise it for the thing it absolutely excels at. The BEAM is built around passing immutable messages between cheap green threads, watched over by resilient supervisor trees. This means no data races (immutability), no hung threads (supervisor trees), no boilerplate (all of this is built in). The performance is surpris…

Not only does it do this all very safely, it uses the absolute most minimal of memory to achieve this. This video from 9 years ago... 1 million people in 1 chatroom, on a server with 40+ cores and 128GB of memory, one single physical server, it used up about 30 GB of memory. Show me a language that can do this efficiently. In under a second it went to a million different connections. The cores didn't spin up to grind…

I said BEAM has been in prod since 1992 but I meant OTP. BEAM is even older... Erlang goes back to the 80s.

Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors

#89

Is there any beam language that has regular 'for','while' loops and good OTP support?

No, the VM is functional and immutable so you cannot implement things like `while` on it efficiently. It is highly optimised for the functional immutable style of programming.
Post reply on HN