[erlang-questions] Any Erlang Devs Contemplating Elixir?

[Andrew Berman]

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!

On Fri, Apr 22, 2016 at 3:15 PM Michał Muskała <michal@REDACTED> wrote:

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