Earlier quoted context omitted.
You can cast or call ( non blocking, or blocking) you can do either.
how would you get a deadlock with non-blocking requests ?
I never said you did ?
Gleam OTP – Fault Tolerant Multicore Programs with Actors
61–70 of 89 posts
Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors
#62IMHO the actor model is great until you need to share something across processes, then you have a distributed computing problem inside your program. For developing fault tolerant multicore programs I think I'm better off using a functional effects system with software transactional memory like Scala/ZIO than Gleam/OTP. I can still use the actor model where appropriate. Plus the JVM software ecosystem and runtime obse…
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 hardcore, none of that. Just efficient lightweight processes running. This isn't even on "raw Erlang" its on Elixir -> BEAM which is impressive on its own in my eyes. I would love to see equivalent videos on similar hardware today in other languages. ;) Please by all mean, show me your JVM application that can handle this.
I also love that he thinks all those languages that are a decade (and decades) younger than the BEAM which has been in production since 1992 are more production ready and tested. I don't think he realizes the origin story to Erlang whatsoever, it was 100% built to be used in production for a major telecoms provider.
Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors
#63I’m fascinated by the sound of Erlang/BEAM but I’ve never found the time to actually try it. How are people using it in production? Do you write all your service logic using it or delegate specific parts to it?
Come and have a chat at elixirforum.com. Plenty of folks write serious stuff entirely/predominantly in Erlang/Elixir & BEAM and will be happy to answer your questions.
Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors
#64gleam 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
Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors
#65For all you wonderful people using Gleam, do you use Phoenix? Or any other web frameworks? I really would love to do Gleam with something like Phoenix, but I have not had enough time to check out all the options yet. I'm in the process of building a new project with Python, but if there's options with Gleam worth looking into I just might try it out for this new project.
Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors
#66For all you wonderful people using Gleam, do you use Phoenix? Or any other web frameworks? I really would love to do Gleam with something like Phoenix, but I have not had enough time to check out all the options yet. I'm in the process of building a new project with Python, but if there's options with Gleam worth looking into I just might try it out for this new project.
There isn’t really anything like Phoenix or Django or Rails. There are a set of tools though that are commonly used to build web apps. Lustre is the primary view tool. Wisp is the server. And then squirrel and POG, newer but people seem to like it, are used for sql.
- squirrel: https://github.com/giacomocavalieri/squirrel
- Lustre: https://github.com/lustre-labs/lustre
Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors
#67I’m fascinated by the sound of Erlang/BEAM but I’ve never found the time to actually try it. How are people using it in production? Do you write all your service logic using it or delegate specific parts to it?
Come and have a chat at elixirforum.com. Plenty of folks write serious stuff entirely/predominantly in Erlang/Elixir & BEAM and will be happy to answer your questions.
Thank you!
Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors
#68I’m fascinated by the sound of Erlang/BEAM but I’ve never found the time to actually try it. How are people using it in production? Do you write all your service logic using it or delegate specific parts to it?
I'm leading a team that is doing an incremental migration to Gleam by delegating specific parts - we're basically pushing the "functional core, imperative shell" pattern to its macro extreme and having Gleam pick up background jobs from our existing Ruby on Rails codebases where we have heavy calculation tasks.
This approach is notably not making proper or really any use of OTP features, but it was an extremely easy way to adopt a safe, fast, functional language for number-crunching workflows while continuing to lean on Rails for everything else its great at: web interfaces, HTTP APIs, etc.
Rails is basically the configuration tool for the various inputs of a job, and job is passed to Gleam via Redis as an atomic set of config inputs to be used when processing a dataset (usually big CSV files streamed from object storage). We use a very thin Elixir wrapper to do all network and file IO etc, Gleam modules are pure business logic called from Elixir.
Some day soon, I'm going to try and write up a longer technical article about this approach... it comes up surprisingly often in HN conversations.
Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors
#69Earlier quoted context omitted.
I wholeheartedly agree with you that gleam_otp is janky. Still, actor message passing is only part of the picture. Here are some issues that make static typing difficult in OTP: • OTP processes communicate via the actor model by sending messages of any type . Each actor is responsible for pattern-matching the incoming message and handling it (or not) based on its type. To implement static typing, you need to know at…
I suppose I was unclear. It is OTP-style `gen_server` processes that I'm talking about. > OTP processes communicate via the actor model by sending messages of any type. Each actor is responsible for pattern-matching the incoming message and handling it (or not) based on its type. To implement static typing, you need to know at compile time what type of message an actor can receive, what type it will send back, and ho…
I read the code but I'm not sure I understood all of it (I'm familiar with Elixir, not with Gleam).
For normal matters I do believe that your approach works but (start returns the pid of the server, right?) what is it going to happen if something, probably a module written in Elixir or Erlang that wants to prove a point, sends a message of an unsupported type to that pid? I don't think the compiler can prevent that. It's going to crash at runtime or have to handle the unmatched type and return a not implemented sort of error.
It's similar to static typing a JSON API, then receiving an odd message from the server or from the client, because the remote party cannot be controlled.
Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors
#70I’m fascinated by the sound of Erlang/BEAM but I’ve never found the time to actually try it. How are people using it in production? Do you write all your service logic using it or delegate specific parts to it?
I'm leading a team that is doing an incremental migration to Gleam by delegating specific parts - we're basically pushing the "functional core, imperative shell" pattern to its macro extreme and having Gleam pick up background jobs from our existing Ruby on Rails codebases where we have heavy calculation tasks. This approach is notably not making proper or really any use of OTP features, but it was an extremely easy…
Did I understand correctly you’re using it for file processing? If so does it yield reliability benefits?
We have an assortment of jobs written in Go that process files of various types (CSV, Parquet, TXT) in S3 too. The issue we have is that our Kubernetes jobs crash all the time when they encounter something unexpected. Obviously we should invest into making them more robust but what we really want is some way for the jobs to continue processing whatever they can instead of crashing and starting over.