[erlang-questions] Any Erlang Devs Contemplating Elixir?

[Michał Muskała]

Andrew,

while there are many factors in play, I find the idea of deciding on a
merits of whole language based on a package that over 6 months was
downloaded 22 times appalling.
I'm not sure you can go anywhere near stating that such a library is
representative of any ecosystem.

Michał.

2016-04-22 23:31 GMT+02:00 Andrew Berman <rexxe98@REDACTED>:
> 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:
> https://github.com/johnotander/is_url.  That is actually published to Hex,
> by the way.  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:
> http://stackoverflow.com/questions/30696761/check-if-a-url-is-valid-in-elixir.
> One of my favorite things about Erlang is just letting things fail since it
> saves me tons of keystrokes!
>
>
>
> On Wed, Mar 16, 2016 at 8:45 AM Mikael Pettersson <mikpelinux@REDACTED>
> wrote:
>>
>> Torben Hoffmann writes:
>>  >
>>  >
>>  > Mikael Pettersson <mikpelinux@REDACTED> writes:
>>  >
>>  > > [ text/plain ]
>>  > > Zachary Kessin writes:
>>  > >  > I for one would love to see an ML-family language on the beam!
>>  > >
>>  > > I'm working on a Standard ML (SML'97) compiler targeting the
>>  > > Erlang/OTP VM.  I hope to have it finished enough to make it
>>  > > public sometime this year.
>>  >
>>  > I have been thinking about this a bit, so I'll throw in some questions.
>>  >
>>  > What kind of type system are you using?
>>
>> The SML'97 one, with minimal extensions for interfacing with Erlang
>> (see below), and possibly fixes from the Successor-ML effort.
>>
>>  > I have been told that a type-and-effect system would be the way to
>>  > capture the effects of statements on the mailboxes.
>>  >
>>  > Have you given any thought to upgrades?
>>  >
>>  > The problem is that an upgrade can change the types, so that leads to
>>  > some thinking about versioning the types. Tricky business.
>>  > Without some attention to this it will be hard to evolve a distributed
>>  > system.
>>
>> Yes.  Basically, we'd need to redo type checking before allowing calls
>> to or from a dynamically upgraded module.  Unfortunately the VM doesn't
>> give us a hook for that.  I'm still thinking about the best way to
>> address this.  Initially I'll ignore the problem.
>>
>> In fact, there isn't even a cast-in-stone mapping between SML and Erlang
>> modules.  While I could compile each functor or top-level structure to
>> a module (Erlang-like), I could also compile entire applications to
>> single modules (at least two SML implementations already do that).
>>
>>  > And then there is interfacing to the external world.
>>  > My instinct tells me that it would make sense to attach some sort of
>>  > adapter code that will have the type signature
>>  > val adapt: binary -> some_type
>>
>> My plan is to support something like typecase on values of type dynamic,
>> as I've seen other functional languages do before.  That's enough to
>> enable safe import of data from the dynamically typed world.
>>
>>  > Which leads me to... how will you describe binary pattern matching?
>>
>> Binary matching is already statically typed, so I don't see any
>> problem there.  binary_to_term would have result type dynamic.
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>