[erlang-questions] Any Erlang Devs Contemplating Elixir?
Sat Apr 23 00:15:10 CEST 2016
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.
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:
> 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>
>> 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 mailing list
More information about the erlang-questions