[erlang-questions] Any Erlang Devs Contemplating Elixir?

[Shane Utt]

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/e53c8ac2/attachment.htm>