
Elixir v1.4.0 released - njade
https://github.com/elixir-lang/elixir/releases/tag/v1.4.0
======
sotojuan
My favorite part about Elixir is that it doesn't try to reinvent the wheel.
It's not an untested, trendy new paradigm or tool. It's based on decades of
Erlang/BEAM/OTP experience and Ruby/Rails/last 10~ years of programming
ergonomics. The only things that are added are those that actually add to the
experience.

An example: A large part of the Erlang standard library is not translated in
Elixir. Instead, you call Erlang methods with a seamless interop. José & co.
understand that there's no need to reinvent the wheel and no benefit in
another abstraction. I like that.

My least favorite part about Elixir is that it has become a "trendy" language
among the web crowd. While the community is overall great, there's always a
loud minority of "beginner experts" both claiming it's the best thing ever and
deriding those for using other tools. I've seen a lot of random, unwarranted
Rails bashing and Elixir shilling (never from a team member or community
leader though!).

~~~
xiaoma
It's actually very much like the situation was with Rails a decade ago.
Actually that was more extreme. Anybody remember all those "Rails vs _____"
commercials from the Rails Envy people?

[https://www.youtube.com/watch?v=Y7Jte6NvLGU](https://www.youtube.com/watch?v=Y7Jte6NvLGU)

~~~
sotojuan
Yes, Rails isn't innocent in this (most web things aren't). Just wanted to
give an example.

------
josevalim
Link to the official announcement: [http://elixir-
lang.org/blog/2017/01/05/elixir-v1-4-0-release...](http://elixir-
lang.org/blog/2017/01/05/elixir-v1-4-0-released/)

~~~
qaq
Thanx for all the great work José we all really appreciate it.

------
themgt
Coming from Ruby, Elixir feels like a powerful, beautiful language with a
surprisingly radical but ultimately simple approach to concurrency thanks to
Erlang/BEAM, and Phoenix is like Rails 2006, as far as the framework to sell
Elixir's advantages to the masses. It's very powerful and scaling "just
works". All Elixir needs now is a viable ElixirScript that can compile down to
JS/WASM, and along with Nerves it's ready for world domination. ;)

~~~
rubyn00bie
I'm not sure why you want to compile Elixir or Erlang to JS... Most of the
magic of the language is provided by BEAM and OTP which for a multitude of
reasons cannot be properly implemented in any JS engine/backend I'm aware of.
If anything I'd think the abstractions of Elixir/Erlang would be cumbersome
and very awkward when writing performant code which had to be transpiled to
JS. The biggest reason being is BEAM can do preemptive scheduling,
interrupting a running process to ensure all have equal execution time. This
is a stark contrast to everything I know about how most any other VM or
runtime work (which cannot preempt).

While yes the language is nice, I think using something like Opal would
provide most of the syntactic pleasantries while being easier to understand
when it comes to tuning and debugging.

If what I'm saying is nonsense, I'm missing the point, or short sighted please
learn me! :)

~~~
btown
With the right abstractions and (adhered-to) guidelines, a library in a non-
preemptive language can allow your code to effectively yield to the scheduler
so often that you get many of the benefits of preemptiveness. React is moving
in this direction with their ongoing Fiber project [0] - since components are
encouraged to be granular, and must be loosely coupled, the new React
scheduler can take well-structured React code and plan the rendering of
various subtrees with high levels of control. In fact, there's a TON of
similarities between React's component model and the BEAM actor model: a
component's "mailbox" consists of inbound props, outbound async callbacks to
the component that requested its instantiation, and outbound assertions that
the component desires to communicate props to new instances of other
components.

One could imagine a compiler that inserts a yield around the calculation done
in each Elixir AST node, and/or one which allows first-class representation of
React components as Elixir processes, complete with JSX-like syntax. Very
interesting to think about.

[0] [https://github.com/acdlite/react-fiber-
architecture](https://github.com/acdlite/react-fiber-architecture)

EDIT: Should also add that the shared-nothing messaging model translates very
well to the requirements for Web Worker interop, so you actually could get
multithreading.

~~~
felixgallo
there's essentially no similarity at all between React's component model and
the BEAM actor model, except that there's handlers. React and JS have no
notion of backpressure, work-stealing schedulers, NUMA, per-actor GC, the list
goes on forever.

~~~
btown
All true and duly noted, though readers may be interested in how sophisticated
Fiber's scheduler may end up being:
[https://github.com/facebook/react/blob/39278c41e2f98d357f166...](https://github.com/facebook/react/blob/39278c41e2f98d357f166a5523e3194fc5242d9d/src/renderers/shared/fiber/ReactFiberScheduler.js#L634)

------
_asummers
Congratulations to José and the Elixir team! It will be nice to finally settle
the bare words debate and fix all the new warnings and deprecations. We
compile with warnings as errors, so that should be a fun morning when we
upgrade.

------
securingsincity
> [Kernel] Recognize merge conflict markers in source and provide a readable
> error message

Great idea, having to track down a merge conflict that may have been committed
can be a drag.

~~~
zegerjan
This confuses me, as I can think of any language where `<<<<<<HEAD` would be
valid? This is why its formatted this way.

I'd say the compiler or interpreter should tell you within no time where it
encountered invalid tokens?

~~~
lostcolony
The point of this change is to make the error message, when the compiler
encounters such a line, something like "Unresolved merge conflict detected in
source code at (file:line)", rather than whatever it previously was (some sort
of nebulous syntax error, that may or may not have been well located,
depending on exactly what the parser managed to infer, but certainly was not
well defined).

------
tiffanyh
Will Erlang/Elixir ever be able to attain the raw performance speed of Go?

I'm not talking about concurrency, etc. Just raw computational speed.

~~~
brightball
The trade off is that a runaway process can't compromise everything else. The
inherent performance difference comes from prescheduling vs cooperative
scheduling. Prescheduling is slightly slower in exchange for consistency in
the face of bad behavior.

Add in the supervision tree structure and you end up trading "super fast" for
"very fast, consistent and runs forever"

~~~
tiffanyh
Is there any updates on the JIT work from 2014 to help speed up raw
performance of Erlang?

[1] [http://www.erlang-
factory.com/static/upload/media/1402914329...](http://www.erlang-
factory.com/static/upload/media/1402914329562325jiteuc2014.pdf)

[2] [http://www.erlang-factory.com/euc2014/frej-drejhammar](http://www.erlang-
factory.com/euc2014/frej-drejhammar)

~~~
di4na
Yes. The news is basically "still in the roadmap, we got a bit more of time
budget from it" from the OTP team. It is not something you will see tomorrow,
but it is a long standing thing in the roadmap for the team.

Of course, if you want to sponsorise the work...

------
transfire
> [Kernel] Deprecate support for making private functions overridable.
> Overridable functions must always be public as they must be contracts

Just lost interest. I thought Elixir was supposed to learn from Ruby.

~~~
brightball
Personally, I've never seen the value in private functions in the real world.
If you are in the same runtime and can see the code, what exactly does a
private function offer you other than ensuring somebody has to duplicate the
method to manipulate it.

Professionally I've never seen a private function/method that had a purpose or
benefit from being private.

~~~
preordained
There are plenty of times. Take a data structure like a hashmap. You know
there are plenty of internal functions to manage the map (rehash, handle
collisions...) that there is no reason for a hashmap end user to see or even
be tempted to muck with. Now, you can could make a new class as an interface
to this hashmap with only the appropriate exposed methods...but that seems
like an excessive sort of pattern.

In a statically typed language like Java, etc., it also gives you the benefit
that when you are auto-completing or discovering methods, you see only the
exposed methods you are meant to call as an API user instead of poring over
every two-line helper method in the class.

~~~
true_religion
When I subclass hashmap, I may desperately want to reimplement collision
handling without also having to rewrite the every other private function it
calls. Private functions close the library off to custom extension.

~~~
mkarklins
... and keeps the library's updates smoother, since there can't be any
tinkering with library's implementation.

~~~
true_religion
You don't have to support users who use your library internals. Django for
instance didn't support everyone who relied on undocumented internals in its
orm. The standardization for the latest release made those internals clean and
documented, but unapologetically broke other people's code including mine.

