[erlang-questions] Any Erlang Devs Contemplating Elixir?

[Andrew Berman]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160422/7240a333/attachment.htm>