[HN Gopher] Exploring the Gleam FFI
       ___________________________________________________________________
        
       Exploring the Gleam FFI
        
       Author : lawn
       Score  : 43 points
       Date   : 2024-01-11 12:08 UTC (1 days ago)
        
 (HTM) web link (www.jonashietala.se)
 (TXT) w3m dump (www.jonashietala.se)
        
       | malkosta wrote:
       | > This is what drew me to Gleam, which feels like Elixir but with
       | Rust types on top
       | 
       | FYI the next big elixir launch is a gradual type system.
        
         | giraffe_lady wrote:
         | I would imagine most people using gleam are aware. But it's not
         | here yet, and will be implementing a novel type system with no
         | major forerunners. I have very high confidence in the elixir
         | folks, but still it's hard to estimate how quickly it will
         | arrive and what its practical advantages and tradeoffs will be
         | when it lands. Whereas ML type systems are venerable and
         | proven, with well-understood contours and constraints and
         | people have deep expertise at applying them to certain problems
         | successfully.
         | 
         | So idk, I'll probably still keep an eye on gleam even once
         | elixir has types. In a sense I think my ideal language would be
         | like "rescript but for erlang instead of js" and typed elixir
         | definitely isn't that. Gleam isn't quite that either but it's
         | from the same neighborhood.
        
           | throwawaymaths wrote:
           | Actually isn't this the problem? ML type systems are not
           | designed for the beam, which has datatypes that are difficult
           | to express in ml
        
             | giraffe_lady wrote:
             | Yes I was trying to be careful not to say that the ML-type
             | approach was _better_ than the incoming typed elixir
             | approach. Just that it has well-understood limitations and
             | tradeoffs that people are already familiar with, which is
             | an advantage in certain situations.
             | 
             | But, and I'm certainly not a type systems expert, I think
             | something like ocaml 5's algebraic effects can model
             | anything in beam? I'm not a beam expert either though so
             | maybe I'm wrong. It might be unusably hairy though.
             | 
             | Anyway though again I have high confidence that elixir will
             | come up with an excellent type system _for elixir_. But a
             | project starting from a well-understood type system and
             | building towards beam will get a different result and I
             | think that 's likely also valuable.
        
             | weatherlight wrote:
             | I thought it wasn't that the data types were hard to
             | express but the dynamic nature of messages across nodes...
        
       ___________________________________________________________________
       (page generated 2024-01-12 23:02 UTC)