<div dir="ltr">Totally agree. Very happy that it exists and it's growing.<br><br><div class="gmail_quote"><div dir="ltr">On Fri, Apr 22, 2016 at 2:52 PM Shane Utt <<a href="mailto:shaneutt@gmail.com">shaneutt@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I have tried Elixir but have not felt the need to use it for anything over Erlang, because all of my current needs are met.<div><br></div><div><div>The two main compelling reasons I have found for using Elixir are however:</div><div><br></div><div> * People I've shown it to (who don't work on Erlang projects) seem to be more receptive towards the Elixir syntax</div><div> * Phoenix and Ecto</div><div><br></div><div><div class="gmail_extra">I personally think its a good thing and a sign of health for N languages to be sharing Beam, and so I welcome Elixir and I follow its progress despite not needing it at the moment.</div><div class="gmail_extra"><br></div><div class="gmail_extra">If I was to use Elixir for future projects, I expect it would be because of a desire to implement a new application using Pheonix.</div></div></div><div class="gmail_extra"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 22, 2016 at 5:31 PM, Andrew Berman <span dir="ltr"><<a href="mailto:rexxe98@gmail.com" target="_blank">rexxe98@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Reviving this thread I started. I did decide to stick with Erlang. While I think Elixir has a lot going for it and I'm happy that people are migrating to it, I started to get a bit put off when I saw repos like this: <a href="https://github.com/johnotander/is_url" style="outline:transparent solid 1px" target="_blank">https://github.com/johnotander/is_ur</a>l. That is actually published to Hex, by the way. <span style="line-height:1.5">While Hex might have solved the problem npm had a little while ago, it looks like Elixir is breeding the same mentality of relying on tiny libraries. Also, the Erlang motto of just letting it fail seems to have gotten lost somewhere. Based on the dev's code (and I could be very wrong on this), it doesn't look like Elixir's URI.parse actually throws any error when it cannot parse a valid URI. Even found a stackoverflow on it: </span><a href="http://stackoverflow.com/questions/30696761/check-if-a-url-is-valid-in-elixir" style="line-height:1.5" target="_blank">http://stackoverflow.com/questions/30696761/check-if-a-url-is-valid-in-elixir</a>. One of my favorite things about Erlang is just letting things fail since it saves me tons of keystrokes!<div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Mar 16, 2016 at 8:45 AM Mikael Pettersson <<a href="mailto:mikpelinux@gmail.com" target="_blank">mikpelinux@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Torben Hoffmann writes:<br>
><br>
><br>
> Mikael Pettersson <<a href="mailto:mikpelinux@gmail.com" target="_blank">mikpelinux@gmail.com</a>> writes:<br>
><br>
> > [ text/plain ]<br>
> > Zachary Kessin writes:<br>
> > > I for one would love to see an ML-family language on the beam!<br>
> ><br>
> > I'm working on a Standard ML (SML'97) compiler targeting the<br>
> > Erlang/OTP VM. I hope to have it finished enough to make it<br>
> > public sometime this year.<br>
><br>
> I have been thinking about this a bit, so I'll throw in some questions.<br>
><br>
> What kind of type system are you using?<br>
<br>
The SML'97 one, with minimal extensions for interfacing with Erlang<br>
(see below), and possibly fixes from the Successor-ML effort.<br>
<br>
> I have been told that a type-and-effect system would be the way to<br>
> capture the effects of statements on the mailboxes.<br>
><br>
> Have you given any thought to upgrades?<br>
><br>
> The problem is that an upgrade can change the types, so that leads to<br>
> some thinking about versioning the types. Tricky business.<br>
> Without some attention to this it will be hard to evolve a distributed<br>
> system.<br>
<br>
Yes. Basically, we'd need to redo type checking before allowing calls<br>
to or from a dynamically upgraded module. Unfortunately the VM doesn't<br>
give us a hook for that. I'm still thinking about the best way to<br>
address this. Initially I'll ignore the problem.<br>
<br>
In fact, there isn't even a cast-in-stone mapping between SML and Erlang<br>
modules. While I could compile each functor or top-level structure to<br>
a module (Erlang-like), I could also compile entire applications to<br>
single modules (at least two SML implementations already do that).<br>
<br>
> And then there is interfacing to the external world.<br>
> My instinct tells me that it would make sense to attach some sort of<br>
> adapter code that will have the type signature<br>
> val adapt: binary -> some_type<br>
<br>
My plan is to support something like typecase on values of type dynamic,<br>
as I've seen other functional languages do before. That's enough to<br>
enable safe import of data from the dynamically typed world.<br>
<br>
> Which leads me to... how will you describe binary pattern matching?<br>
<br>
Binary matching is already statically typed, so I don't see any<br>
problem there. binary_to_term would have result type dynamic.<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div>