Elixir v1.4.0 released | Hacker News Reader

Elixir v1.4.0 released

github.com

229 pointsnjade60 comments

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!).

What's wrong with getting excited about a new language and framework that's better? Being vocal about how awesome something is gets people involved which grows the community. A larger community translates to more educational material and tooling.

I think zealotism has a fine line, but I don't think it's all bad. It's almost like protestors that believe in something strongly. Sometimes they cross the line, but them protesting gains visibility which results in change.

Better than what?

Erlang was developed to solve problems that are quite common in Web Development like concurrency, high availability and so on. I see Elixir basically as a user-friendlier version of Erlang with some added goodies. So I think it makes perfect sense for it to be popular among the Web crowd. It definitely has it's own problems(ease of deployment, package maturity, imo). But if your problem involves networks I think Elixir is at the very least worth having a look at.

Deploying Elixir is extremely easy with Distillery, I think.

https://github.com/bitwalker/distillery

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

I started using rails pre 1.0 when in university, inexperienced as I was I totally drank the coolade.

I remember laughing to myself thinking how much more productive I would be than my classmates.

Boy was THAT a rude awakening.

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

I believe the rails hype was quite warranted. Both the framework as well as ruby were probably the largest leap in their space I've witnessed. When rails first came out, the dominant competitors were Java/spring and all things PHP. The former was an IBM-sponsored attempt to reduce competition using xml-induced suicides. PHP was the land of config.backup.do-not-change-line-endings.php3~.

It's incredible how much dhh got right from the start, and I believe the opinionated nature taught a generation of developers how to structure a project. It's unfortunate that ruby stagnated.

+1! You bring up some excellent points, I think. For example, Elixir is based on decades of Erlang success, and a decade of Ruby and Rails success. I've been using it as the backend to a mobile app for about a year now, and it has far exceeded my expectations in learning curve, ease of writing concurrent code, maintainability, scalability, and performance.

I also agree with you regarding Ruby/Rails. Ruby and Rails are both elegant technologies, and have had a significant influence on how we write web applications today. You cannot take those contributions away, regardless of how many "better" languages come out. I think both Ruby and Elixir have their strengths and weaknesses, but that doesn't mean either is bad. Saying so would be like trashing a screwdriver because it isn't very good at driving nails.

I like Elixir and am using it but the large amount of Ruby references is starting to annoy me. I've never used Ruby so all those comparisons add no value for my learning it.

But I do like the language and the environment.

Link to the official announcement: http://elixir-lang.org/blog/2017/01/05/elixir-v1-4-0-release...

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

thanks!!

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. ;)

If all you need in js/wasm is the functional layer of the language, that could be easy.

If you want to add processes, that could be very hard.

If you also want the supervisors, that's difficult but probably not has much as adding Erlang style processes.

What's stopping a compile of Erlang to JS via LLVM and Emscripten and just taking the expected performance hit?

Erlang doesn't compile to machine code, but to bytecode that runs into the Erlang VM. So you would probably have to run the Erlang VM on top of javascript... I'm not sure whether it's possible, but it sure sounds heavy.

With WebAssembly, you should be able to compile the Erlang VM itself to it.

There is the LLVM backend in Erlang as of version 17. I haven't seen much info on it. I haven't seen anyone try to go the whole process from Erlang code to LLVM to Emscripten to JavaScript. I am interested to know what hurdles there might be, performance, etc.

AFAIK the VM creates a thread per core (by default) and schedules Processes across those threads and stuff. I'd say this might be possible to do with Web Workers. Sounds like it could be fun, probably a challenge to make it fast.

>All Elixir needs now is a viable ElixirScript that can compile down to JS/WASM

On the off-chance you pulled that name out of a hat, or for the benefit of anyone else who might not realize you are referencing a real project:

https://github.com/bryanjos/elixirscript

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! :)

Even if Elixir had no concurrency goodness I would still prefer it to a language like JS any day of the week. JS is a mess of paradigms and features. Elixir has a small set of great features: modules, functions, pattern matching, immutable data structures, macros.

Regarding your performance point, I'm skeptical. Is it really so easy to reason about the performance of even plain JS code? Maybe you're more familiar with the deep dark crevices of v8 and spidermonkey than I am, but I find v8 to largely be a black box in terms of fine tuning performance. Of course, the big picture optimization is simple enough, but that wouldn't change whether you are using plain JS, Opal, PureScript, or any other language.

Yes, a BEAM elixir program can run parallel threads and ElixirScript won't be able to do that because in JS, there are no threads. That doesn't make plain JS faster, just means Elixir will be brought down to the same level as plain JS.

I've used what I view to be equally foreign compile to JS languages (ClojureScript, Elm). They of course came with challenges, but fine tuning performance doesn't even make the top 10.

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

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.

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.

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...

No I'm totally aware you wouldn't be able to replicate BEAM/OTP on a JS runtime, but my guess is you could port enough of the syntax and some of Elixir's high-level abstractions, especially to ES7. The point wouldn't be running the majority of existing Elixir/Erlang libraries, but to easily write ElixirScript within a webapp and transparently reference/integrate with server-side models, auth, etc.

Just use elixir on the server, and clojurescript on the client.

Or clojurescript on both sides

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.

> [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.

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?

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).

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.

No, same as Go will never be able to match the unique characteristics of Erlang/OTP.

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"

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...

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

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...

If you need raw computational speed you shouldn't be dealing with erlang / elixir anyway. Rust and go would be a proper comparison here

Anything that's good at handling a lot of I/O or a lot of concurrent processes tends to become CPU bound as more load is given to it.

It's not only about raw computational speed. Being good at concurrency means that you can handle more work, unless you consume too much CPU.

probably not. on mostly io bound workloads they should perform similarly but a beam instruction is inherently more costly than a go instruction so on cpu bound workloads go should dominate

however, if you're using elixir/erlang for something cpu bound you're probably doing something very wrong so this isn't a real world concern for most users

Go is statically typed and compiled, while Elixir/Erlang is dynamically typed and interpreted, so beating Go is unlikely.

A plus for BEAM is that each process (aka Goroutine) has it's own, independent garbage collector that doesn't interfere with anything else.

The point is, though, you don't use the BEAM for it's raw speed, but for it's great concurrency and fault tolerance. Go has decent concurrency, but it's not all roses and butterflies. Also all data is immutable in Erlang/Elixir which makes concurrency a lot easier.

Elixir/Erlang is dynamically typed, but also compiled. At least in Elixir you can use .exs files (usually for tests or config) that are interpreted, but any .ex files are compiled.

> [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.

You'd think they'd learn from Java!

Edit: Not a shallow dig, but I had lots of fun using a 3rd party library that had locked down a lot of methods which prevented some sales driven features...

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.

In Elixir especially, with everything being immutable, I don't really have to worry about state hanging around for my private methods to care about. I wind up just throwing private functions into little helper modules that can be tested independently.

As far as benefit of something being private, an API does not have to be maintained if it is private. Once it's out there, you're locked into doing that for the duration of your deprecation window.

They seem quite useful. Mostly signaling that things should not be used.

What's the largest number of people you've workwe with on a codebase? I would assume the benefits aren't really all that much for small codebases / teams.

On a single code base, the most I've worked with at a time is 12.

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.

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.

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

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.

Private functions permit functional decomposition without a commitment to support the interface implemented by the private functions (meaning the functions can be changed / refactored without breaking clients of the library).

Private (a.k.a. non-exported) functions affect how the compiler optimizes code, at least around inlining.

A function being overridable is a part of the contract, because other functions may rely on it. If you can override truly private stuff, you have no idea about the invariants that you need to uphold to do that correctly.

Am I misunderstanding this or what do you mean learn from ruby? In Ruby I can override private methods without a problem.

Ruby doesn't have private methods. You can always object.send(:method) and the only effect of the private keyword is to disable the object.method() syntactic sugar. No wonder that even methods marked as private can be redefined.

Can you please expand on this a bit? Your comment is very vague.

The comparison with Ruby here doesn't make much sense because private means different things in both languages and Elixir does not have inheritance.

Reply on news.ycombinator.com