HN Theater @HNTheaterMonth

The best talks and videos of Hacker News.

Hacker News Comments on
ElixirConf 2015 - Keynote by José Valim

Confreaks · Youtube · 121 HN points · 1 HN comments
HN Theater has aggregated all Hacker News stories and comments that mention Confreaks's video "ElixirConf 2015 - Keynote by José Valim".
Youtube Summary
Help us caption & translate this video!

http://amara.org/v/HOkZ/
HN Theater Rankings

Hacker News Stories and Comments

All the comments and stories posted to Hacker News that reference this video.
Something this article misses a bit (which is fair, because it's about the language) is that the Elixir community has already put together a very impressive amount of tooling for such a young language. For package management, hex seems mature and well-designed, and I've found their task / compilation management tool, mix, to be a dream to work with. José Valim spent a lot of time talking about the entire ecosystem in his recent keynote at ElixirConf 2015[0].

[0]: https://www.youtube.com/watch?v=9RB1JCKe3GY

Oct 15, 2015 · 121 points, 31 comments · submitted by clessg
fuzzythinker
All other videos on http://confreaks.tv/events/elixirconf2015
djKianoosh
I dont know why you'd get downvoted for this. Thanks for linking it. There are some interesting talks here.
lectrick
I really liked the Elm talk as well as Garth Hitchens' talk on Embedded Elixir, which was a pretty effin' sweet demo if I say so myself
aaron-lebo
Seems unreal how in command Valim is both of himself and the project at his age.

With some of the other language designers reaching maturity (GvR, Matz, Wall), it should be interesting to see where he and Elixir are at in 20 years time.

kaiwen1
I hired Jose in 2007 when he was an unknown college student and have since watched his career unfold. José's productivity borders on the supernatural. On top of that, he's very humble, gracious and helpful. Betting Elixir is betting on José. That's good bet.
lukev
I've been learning Elixir and liking it very much.

One question I have, though, coming from Clojure, is how to quantify the cost of sending large data structures between processes. I'm so used to shared-memory concurrency that it isn't clear to me how to efficiently write an Elixir/Erlang program in which multiple processes need to have (read-only) access to the same data.

Are there any good practices for that, or ways of thinking about how much it will cost to copy the data between processes?

lectrick
What's your impression of Elixir coming from Clojure, other than that?

I wanted to get into Clojure but I really wanted a language that almost entirely forced me to forego mutability (due to the large class of bugs I've seen in the past because of it) and Elixir seemed to provide that, Clojure did not, it was more live-and-let-mutability-live... and I didn't like that.

Regarding your question, it's my understanding that (again, due to everything being immutable), larger data sent between nodes in the same BEAM VM is not copied, it is reference-counted and garbage-collected and any changes are copy-on-write but only for that part of the data structure (due to implementation of Persistent Data Structures underneath).

One thing I'm VERY curious about with regards to Clojure is Datomic. Elixir (IMHO) could really use a fully queryable, immutable DB. After I drank the immutable kool-aid, it was jarring to have to think about mutation in global state again whenever I touch a database, to the point that I'm considering foregoing SQL as long as possible and just dealing with Mnesia or Basho's Riak and writing implementation-agnostic wrappers around my datastores (the latter is probably a good idea anyway).

Mutexes need to die in a fire. ;)

andrewmutz
I am not an Elixir expert, but as I understand it, passing data between processes is pass-by-value but copy-on-write, if the processes are within the same BEAM instance.
None
None
lukev
Yes. They're also very isolated from eachother (compared to processes in most other languages) and, notably, do not share the same object heap. Hence my question.
adambrod
Oh gotcha, sorry didn't read it thoroughly enough :)
andrewmutz
I believe large objects are on a shared heap. Source: https://hamidreza-s.github.io/erlang%20garbage%20collection%...
vezzy-fnord
ETS?
seiji
Yeah, ets is the solution when you need cross-process "global variables" in Erlang.
ryeguy
ETS still gives you a copy of the data when you retrieve it, so it doesn't really help there.
rubiquity
Here's a few thoughts on sending large data between processes:

1) Don't unless you really have to. Does the receiving process really need all that data to do its job?

2) Define big? Most database adapters are multi-process so lots of message passing happens. I've had some large database rows (122 columns (sigh. I know) per row) and sending those between hasn't been a problem.

3) Is the large data a binary? In that case, binaries over 56 bytes are reference counted and not copied between processes. The binary will be GC'ed after all references are gone.

4) Measure measure measure. You don't know that you have a problem unless you measure.

adambrod
Elixir has really changed the way I code in other languages for the better... even in JS. Now I tend to think of programming as a series of transformations and heavily use the underscore chain/pipe feature to mimic Elixir's pipes, trivial ex:

https://gist.github.com/AdamBrodzinski/fff116fb8c5dc20aa0db

fuzzythinker
You can use many of the functional programming constructs like piping, (pretty limited) pattern matching, function composition, etc. with livescript [1]. Its translated js code is as readable as one coffeescript produces.

Or, if you really like elixir and don't mind its alpha status, you can look into elixirscript [2]. He gave a talk [3] in the conf.

Elm [4] is another alternative, but it wants to not just replace js, but html as well, with its very unique and useful "time travel" feature. Alan gave a talk in usage with Phoenix [5].

[1] http://livescript.net

[2] https://github.com/bryanjos/elixirscript/blob/master/FAQ.md

[3] http://confreaks.tv/videos/elixirconf2015-elixir-in-the-brow...

[4] http://elm-lang.org/

[5] http://confreaks.tv/videos/elixirconf2015-phoenix-with-elm

adambrod
Oh wow Livescript snuck past me. However I don't care for the bracket-less syntax. For some reason, it's always hard to read quickly. I think this is why I never could get behind Elm.

ElixirScript looks like it will be nice in time, although seems a bit awkward to use with JS libs. Can't wait to see how that matures!

I've been tinkering with an old language project RedScript to make it more functional (Elixir like). Just a toy though:

https://github.com/AdamBrodzinski/redscript

fuzzythinker
The parans-less is optional, so you can always include them. Redscript seems very elixir like. Now that elixirscript is out, do you see any advance of it over elixirscript? Such as smaller output source or more readable output source. Have you used it yourself in a medium to large size project?
adambrod
I think ElixirScript has more legs. RedScript was just a project I tinkered with 2 years ago and recently refreshed it post ES6 era and after getting into 'functiona' programming.

RedScript is more like CoffeeScript and ElixirScript is more like Elm/ClojureScript IMHO. It has little to no overhead overhead after transpiling however 2.0 will use seamless-immutable (via CommonJS) to help with copying data.

Here's the 1.0 before/after conversions: https://github.com/AdamBrodzinski/RedScript/blob/master/spec...

It still needs a proper compiler, this is basically using RegEx to match/replace (it was a project to learn RegEx). It's surprising how far it takes you. I've built a small web app with it and it works well. I don't trust the compiled output without testing though (due to the RegEx strategy).

I haven't had to the time to make the changes in the complier but shouldn't take more than a few beers and a weekend :)

cpursley
The RedScript syntax looks really great.

Also, +1 for LiveScript.

It's a powerful little language when combined with prelude:

http://learnxinyminutes.com/docs/livescript/

http://livescript.net/blog/10-things-you-didnt-know-livescri...

adambrod
Thanks! I'll check those out.
binaryapparatus
I did smaller projects in Haskell before, then some tests with elixir month ago. Amazing language, simple to grasp even for somebody knowing only imperative languages. Probably the hottest tech around this days, at least from my point of view. Phoenix framework on top of it is most probably next rails. Hot.
zensavona
I am rooting hard for José and Elixir.

I picked the language up about a month ago after hearing Chris McCord talk about his web framework, Phoenix, which is seriously great, but Elixir as a whole is the most fun I've had programming in a long time.

Also, it's quite something when you post a question on the mailing list and usually receive an answer from the creater of the language in a matter of hours. He seems like a really smart and kind guy, and I love working with Elixir, so I hope they both go far.

sgt
So is Elixir the future?
adambrod
I think more cores is the future. Elixir makes it easy (and pragmatic) to utilize all cores. You can write it without parallelism and add it back in later when needed.
lectrick
As a person who once struggled to parallelize a test suite when the entire thing was not written with parallelization in mind (until its runtime became onerous)... I would highly, highly recommend using some parallelization framework from the get-go to uncover any concurrency issues immediately.

In Elixir this is literally as simple as adding "async: true" to your test modules.

It will also force you to write tests that can run concurrently... which has a few nice side effects for your code design generally.

dave_ops
LWPs and OTP patterns are a "parallelization framework". You have to try pretty hard to design an OTP application that can't be trivially parallelized, and that includes parallelization across machines, not just cores.
mrmondo
As someone who's primarily worked in ops engineering I've mostly worked with scripting languages and DSLs (bash, puppet, etc) and cobbled together ruby/Python as required but my strength has never been in programming. I picked up someone's tutorial on Elixir thinking it would be as mind bendingly mathematical as when I looked at Haskell but I was quite taken back - it seemed to make sense to my fickle mind and I found I could quite enjoyably read most basic examples / tutorials with no experience or documentation (also within reason). For me it had the humanised beauty(?) of ruby and logical power of Python without as many 'wtf does that do?' moments. I don't have a lot of use for Elixir in my job (yet), but I am tempted to learn a little.

Am I ignorant because I don't have a programming mindset or 'real' language experience?

unoti
Sounds like you're doing great! Be careful about "Am I ignorant" questions: it's usually straightforward to find others who will tear you down for just about any reason you can imagine!
aaron-lebo
No, I think your lack of language experience makes sense. Elixir, being functional as it is doesn't get caught up in the difference between functions/methods, and you don't have the mental overheard of grokking classes (which imo make sense once you get them, but take awhile to really get).

Elixir distils down to pretty basic concepts of functions returning values and pattern matching and processes. If you can wrap your heard around those you've really got the language.

HN Theater is an independent project and is not operated by Y Combinator or any of the video hosting platforms linked to on this site.
~ yaj@
;laksdfhjdhksalkfj more things
yahnd.com ~ Privacy Policy ~
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.