[HN Gopher] Caramel: An OCaml to Erlang Compiler
       ___________________________________________________________________
        
       Caramel: An OCaml to Erlang Compiler
        
       Author : signa11
       Score  : 83 points
       Date   : 2020-11-21 12:24 UTC (1 days ago)
        
 (HTM) web link (caramel.abstractmachines.dev)
 (TXT) w3m dump (caramel.abstractmachines.dev)
        
       | mcintyre1994 wrote:
       | If this works well, and can eventually interface nicely with
       | Elixir libraries like Phoenix, I think it'll be really exciting.
       | Definitely going to keep an eye on this :)
        
       | rubyn00bie wrote:
       | So... does this work with distributed Erlang or hot code
       | reloading? Because those are the reasons[1], to my knowledge,
       | that statically typed language won't fly.
       | 
       | Really stoked to give this a whirl!
       | 
       | [1] I know, and in-case others don't, almost no one (literally)
       | uses hot-code reloading. Still... Instead of killing it, as in
       | the case of Lumen (I think), I'd like to see it become
       | easier/better...
        
         | rkangel wrote:
         | Users of hot code reloading are probably on the minority but
         | there are definitely more than 'almost no-one'.
         | 
         | There is a common misconception that 'no one on HN does
         | something' means that 'no one does something'. HN is heavily
         | biased towards startups and Web companies and large segments of
         | the industry are very underrepresented. Pretty sure telecoms is
         | one.
        
         | filmor wrote:
         | Where do you derive this "almost no one" from? I use it all the
         | time in production, and I guess quite a few other users use it
         | to fulfill their very high uptime requirements.
        
           | macintux wrote:
           | I suspect there may be two different features (or degrees of
           | features) here. Hot code reloading is indeed frequently used,
           | but the corresponding ability to upgrade the entire
           | application live ("hot swap") is less so.
        
             | rkangel wrote:
             | I don't think so. Hot code reloading is hot code reloading.
             | The parent to your comment is talking about in production
             | so it's the 'real thing'.
        
               | macintux wrote:
               | I'm not sure what exactly you're disputing.
               | 
               | I would wager that nearly everyone who has run Erlang
               | code in production has upgraded code ( _edit for
               | precision: a module_ ) live.
               | 
               | To engineer the entire application to support an upgrade,
               | and to do all the testing required to make sure it will
               | work correctly, is very resource-intensive, and (lacking
               | real numbers, just from observing the industry working
               | for Basho) I'd wager very few people do so.
        
       | natchy wrote:
       | So does this mean you are effectively writing OCaml-looking
       | erlang? meaning, you are using Erlang libraries (not OCaml libs)
       | to perform any IO or iterate over a list?
       | 
       | Where does OCaml end and Erlang begin?
        
       | brightball wrote:
       | Can this work? People have been scrambling for static typing on
       | the BEAM for a while. Is this the one?
        
         | filmor wrote:
         | As far as I'm aware there are a few major problems with static
         | typing in Erlang that can't be solved so far and are not solved
         | here either:
         | 
         | 1. If you have a function that calls into other modules like
         | `other_module:some_func(X)`, then the typing of this call can
         | change at runtime. You could first have
         | some_func(N) when is_number(N) -> N + 1.
         | 
         | and later load a new version with
         | some_func(N) when is_integer(N) -> N + 1.
         | 
         | The older version accepts all numbers, i.e. floats and
         | integers, while the second only accept integers.
         | 
         | 2. Erlang message passing can not be typed statically in a
         | meaningful (i.e. non-trivial) way, as the typing may be state-
         | dependent:                   Pid = spawn_link(fun () ->
         | receive                 first -> ok;                 _ ->
         | error(bad_message)             end,             receive
         | second -> ok;                 _ -> error(bad_message)
         | end         end)
         | 
         | Now, the static typing of sending to `Pid` depends on what
         | you've sent before. This could maybe be handled by
         | "enumerating" the receives, but I think that invites the
         | halting problem into your type system.
        
       | macintux wrote:
       | Obligatory link to my list of alternative BEAM languages.
       | 
       | https://gist.github.com/macintux/6349828#alternative-languag...
        
       ___________________________________________________________________
       (page generated 2020-11-22 23:00 UTC)