<div dir="ltr">Ha, no, I didn't make the decision based on that repo, that was merely a quick example.  I find it so funny when people get defensive about a programming language.  Believe me, Erlang has tons of issues too!<br><br><div class="gmail_quote"><div dir="ltr">On Fri, Apr 22, 2016 at 3:15 PM Michał Muskała <<a href="mailto:michal@muskala.eu">michal@muskala.eu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Andrew,<br>
<br>
while there are many factors in play, I find the idea of deciding on a<br>
merits of whole language based on a package that over 6 months was<br>
downloaded 22 times appalling.<br>
I'm not sure you can go anywhere near stating that such a library is<br>
representative of any ecosystem.<br>
<br>
Michał.<br>
<br>
2016-04-22 23:31 GMT+02:00 Andrew Berman <<a href="mailto:rexxe98@gmail.com" target="_blank">rexxe98@gmail.com</a>>:<br>
> Reviving this thread I started.  I did decide to stick with Erlang.  While I<br>
> think Elixir has a lot going for it and I'm happy that people are migrating<br>
> to it, I started to get a bit put off when I saw repos like this:<br>
> <a href="https://github.com/johnotander/is_url" rel="noreferrer" target="_blank">https://github.com/johnotander/is_url</a>.  That is actually published to Hex,<br>
> by the way.  While Hex might have solved the problem npm had a little while<br>
> ago, it looks like Elixir is breeding the same mentality of relying on tiny<br>
> libraries.  Also, the Erlang motto of just letting it fail seems to have<br>
> gotten lost somewhere.  Based on the dev's code (and I could be very wrong<br>
> on this), it doesn't look like Elixir's URI.parse actually throws any error<br>
> when it cannot parse a valid URI.  Even found a stackoverflow on it:<br>
> <a href="http://stackoverflow.com/questions/30696761/check-if-a-url-is-valid-in-elixir" rel="noreferrer" target="_blank">http://stackoverflow.com/questions/30696761/check-if-a-url-is-valid-in-elixir</a>.<br>
> One of my favorite things about Erlang is just letting things fail since it<br>
> saves me tons of keystrokes!<br>
><br>
><br>
><br>
> On Wed, Mar 16, 2016 at 8:45 AM Mikael Pettersson <<a href="mailto:mikpelinux@gmail.com" target="_blank">mikpelinux@gmail.com</a>><br>
> wrote:<br>
>><br>
>> 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>
><br>
><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></div>