[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)