[erlang-questions] Any Erlang Devs Contemplating Elixir?

[Oliver Korpilla]

Hi.

I'm currently pursueing Elixir at work, and find that the elegance and power of its language core is something which I do appreciate a lot.

Elixir's community seems to be still small but growing. The core libraries are sound, and Erlang OTP is always just one call away when needed which is arguably one of its biggest advantages and definitely one any language could wish for. 

I find the idea that libraries that have been published so far outside the language core are somehow a defining feature of Elixir a bit contrived. So, is there something to be criticized with the language itself, its design philosophy, or with its libraries? So far, I could only wish for a bigger core library and more documentation and examples of its trove of features.

I do agree that packages out there can be hard to get support for. I would say that this actually poses an argument for expanding the community, bringing people with experience in that might have another mindset. As far as I see it the community is still in flux and it is too early to see where it will go.

Oliver
 

Gesendet: Freitag, 22. April 2016 um 23:31 Uhr
Von: "Andrew Berman" <rexxe98@REDACTED>
An: "Mikael Pettersson" <mikpelinux@REDACTED>, "Torben Hoffmann" <thoffmann@REDACTED>
Cc: erlang-questions <erlang-questions@REDACTED>
Betreff: Re: [erlang-questions] Any Erlang Devs Contemplating Elixir?

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[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[mikpelinux@REDACTED]> wrote:Torben Hoffmann writes:
 >
 >
 > Mikael Pettersson <mikpelinux@REDACTED[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[erlang-questions@REDACTED]
http://erlang.org/mailman/listinfo/erlang-questions_______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]