[erlang-questions] Any Erlang Devs Contemplating Elixir?

[Andrew Berman]

Totally agree.  Very happy that it exists and it's growing.

On Fri, Apr 22, 2016 at 2:52 PM Shane Utt <shaneutt@REDACTED> wrote:

> 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.
>
> The two main compelling reasons I have found for using Elixir are however:
>
>   * People I've shown it to (who don't work on Erlang projects) seem to be
> more receptive towards the Elixir syntax
>   * Phoenix and Ecto
>
> 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.
>
> 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.
>
>
> On Fri, Apr 22, 2016 at 5:31 PM, Andrew Berman <rexxe98@REDACTED> wrote:
>
>> 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_ur
>> <https://github.com/johnotander/is_url>l.  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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160422/bdac4cc1/attachment.htm>