Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elixir v1.3 released

elixir-lang.org

Post reply on HN
Print view View original

81–90 of 125 posts

Re: Elixir v1.3 released

#81

Post by paulruby »

eddd wrote: post #61

I use phoenix and elixir, I agree with the statement that Elixir is awesome. But don't drink too much cool-aid - Elixir might be dangerous as well. It is essentially a big pile of macros, so sometimes number of keywords that you have to keep in your head is staggering. Also, Elixir is a pretty big language - I knew Erlang before diving into it - so the barrier and number of concepts that you have to get familiar with…

> Elixir is a pretty big language

Compared to? Perspective matters a lot. It is definitely bigger than Erlang but I would still classify it as considerably smaller than languages like Scala and C++ and still smaller than Ruby and Python.

> It is essentially a big pile of macros

Since "a big pile of macros" is not quantifiable in anyway, I have decided to check for macros and function definitions in Elixir source and I got 1687 functions and 169 macros throughout the whole standard library. It is roughly 10%.

The Kernel module (imported by default) has 60 functions, 78 macros, which is, for example, considerably smaller than Haskell's prelude (about 300 last time I checked?).

Considering things like `defmodule`, `def`, `defp`, `case`, `&&`, `in` are regular macros in Elixir instead of syntax keywords (as they would be in many languages), I wouldn't personally call it a big pile. Although I agree that's a matter of perspective and that's why I decided to measure it).

> the barrier and number of concepts that you have to get familiar with is huge

I definitely agree with this. There are functional aspects, like pattern matching and immutability, the concurrency aspects and the OTP bits. There is definitely a learning curve although most patterns, as you said, are necessary for building the kind of systems Erlang/Elixir enable you to.

Re: Elixir v1.3 released

#82

Post by alehander42 »

shrugger wrote: post #49
insulanian wrote: post #30

Anyone here switched from a statically typed functional programming language (Haskel, OCaml, F#, Scala...) to Elixir? How would you describe the experience? What do you miss? What do you like/love? Overall, would you recommend taking that step?

I switched from Ruby to Scala, and I have had an absolute blast. Elixir is sort of chained to BEAM, which doesn't appear to have as bright a future as the JVM or LLVM does, so Scala seemed like a safer bet. Reading about Elixir is cool sometimes, but then I look at Dotty, and I feel confident that I made the correct choice. I've also been keeping an eye on Crystal (statically typed Ruby-esque language, LLVM), but the…

can you give an example of questionable Crystal desicions?

Re: Elixir v1.3 released

#83

Post by asonge »

davidw wrote: post #80
yelnatz wrote: post #62

Earlier quoted context omitted.

I use elixir (and phoenix) as well, and this is my biggest gripe with the language. When reading (and reviewing) code, sometimes you can't logically follow what's going on since most of the code is hidden behind macros. It's ok if I'm on my IDE that helps expand macros to quickly check the flow, but when it's on a webpage or in a gist somewhere, you're on your own.

Is this a community/culture issue where you can keep things in check if you make a concerted effort to dissuade people from using something too much? Sort of like Rails was big on testing, which was generally a win.

Aside from pretty simple `__using__` macros, most Elixir devs come to appreciate macros and then elect not to use them in the most situations. Most people who do use macros have a very small Macro that just returns the AST for a function call after some tiny little adjustments to the arguments is made.

There are a few exceptions where there are very large projects that make heavy use of macros (Phoenix's router, Ecto), but they are by far the exception. Most of the macros you use every day are simple ones.

Re: Elixir v1.3 released

#84

Post by perishabledave »

hellofunk wrote: post #52
alexgaribay wrote: post #42

Earlier quoted context omitted.

I used to do Scala prior to coming to Elixir, mainly by using Play Framework to create web apps. I can tell you that I love Elixir and that I will not be going back to Scala. I miss nothing from Scala. * Pattern matching in Elixir is superior to Scala's in every way possible (You can pattern match on function parameters!!) * Async code is a breeze with Task.async()/Task.await() instead of mapping on Future's everywhe…

> * No more JVM! You're just trading one VM for another, though. How does having a Beam VM environment differ from a JVM environment?

Having BEAM specifically designed for Erlang concurrency gives it a number of specific benefits. Specifically in how it schedules and handles the VM processes to do efficient concurrency. For example, since the processes are in the VM, it can count the number of function calls to preempt a process that is taking too long.

You can learn more about BEAM here: https://www.youtube.com/watch?v=_Pwlvy3zz9M&feature=youtu.be http://www.erlang-factory.com/upload/presentations/708/Hitch...

Re: Elixir v1.3 released

#85

Post by josevalim »

sctb wrote: post #19
josevalim wrote: post #2

The proper announcement can also be found on our page: http://elixir-lang.org/blog/2016/06/21/elixir-v1-3-0-release... It is slightly better formatted and contains images from the graph commands and ExUnit diff format.

Thanks! We updated the link from https://github.com/elixir-lang/elixir/blob/v1.3/CHANGELOG.md .

Perfect! :D

Re: Elixir v1.3 released

#86

Post by eddd »

bitwalker wrote: post #76
eddd wrote: post #61

I use phoenix and elixir, I agree with the statement that Elixir is awesome. But don't drink too much cool-aid - Elixir might be dangerous as well. It is essentially a big pile of macros, so sometimes number of keywords that you have to keep in your head is staggering. Also, Elixir is a pretty big language - I knew Erlang before diving into it - so the barrier and number of concepts that you have to get familiar with…

The fear about macros in Elixir itself seems a little overblown. Most macros are consumed in the same way you would consume functions or keywords in another language (e.g. defmodule/def/defp/if/unless/etc.). The only one that I can think of that can be problematic is `use`, which is more of a problem with third-party libs where someone might do a lot of "magic", but in general is mostly used to do things like import…

My concern is not about the macros themselves (I don't want to start war on macros and DSLs here) but the amount of them - especially in phoenix.

Hard to grasps at first - later it is a huge benefit.

Re: Elixir v1.3 released

#87

Post by eddd »

paulruby wrote: post #81
eddd wrote: post #61

I use phoenix and elixir, I agree with the statement that Elixir is awesome. But don't drink too much cool-aid - Elixir might be dangerous as well. It is essentially a big pile of macros, so sometimes number of keywords that you have to keep in your head is staggering. Also, Elixir is a pretty big language - I knew Erlang before diving into it - so the barrier and number of concepts that you have to get familiar with…

> Elixir is a pretty big language Compared to? Perspective matters a lot. It is definitely bigger than Erlang but I would still classify it as considerably smaller than languages like Scala and C++ and still smaller than Ruby and Python. > It is essentially a big pile of macros Since "a big pile of macros" is not quantifiable in anyway, I have decided to check for macros and function definitions in Elixir source and…

> Compared to? Perspective matters a lot.

That's why a pasted http://www.slideshare.net/BrianTroutwine1/erlang-lfe-elixir-... - slide 96 (I can't find a direct link). Elixir sits above golang but way below Java or C++. Maintainers are doing pretty good work at simplifying things as language matures - for example merging Dicts and Maps together.

> I wouldn't personally call it a big pile.

Touche.

Re: Elixir v1.3 released

#88

Post by sbrother »

biot wrote: post #51

Any best practice guides for running Elixir in production? How do you handle deployments, hotfixes, multi-node scaling, etc. in an automated way?

We have a small React/Elixir/Phoenix webapp in production, and we deploy it using https://github.com/bitwalker/exrm, https://www.go.cd/, and https://saltstack.com/. I'm not the devops guy myself so I don't fully understand how much work was involved in getting all this set up, but I am extremely pleased with the results!

Re: Elixir v1.3 released

#89

Post by lucidstack »

sotojuan wrote: post #35
matthewrudy wrote: post #29

Elixir 1.3 and Ecto 2.0 are now both released. That means Phoenix 1.2 will be released ASAP. Definitely give the Programming Phoenix book a read if you haven't already. The Elixir/Phoenix stack should be ready for most production environments now. https://pragprog.com/book/phoenix/programming-phoenix

Is there a good guide to Ecto? Aside from OTP, it's the part I have the most trouble with in Phoenix/Elixir.

José Valim (the Elixir creator) is soon releasing a free ebook [0] on Ecto 2.0, and it's probably gonna give some good insights into Ecto in general, so I would definitely recommend getting that :)

[0] http://pages.plataformatec.com.br/ebook-whats-new-in-ecto-2-...

Re: Elixir v1.3 released

#90

Post by asonge »

hellofunk wrote: post #52
alexgaribay wrote: post #42

Earlier quoted context omitted.

I used to do Scala prior to coming to Elixir, mainly by using Play Framework to create web apps. I can tell you that I love Elixir and that I will not be going back to Scala. I miss nothing from Scala. * Pattern matching in Elixir is superior to Scala's in every way possible (You can pattern match on function parameters!!) * Async code is a breeze with Task.async()/Task.await() instead of mapping on Future's everywhe…

> * No more JVM! You're just trading one VM for another, though. How does having a Beam VM environment differ from a JVM environment?

There are a bunch of different performance differences, but a couple basic differences: 1) gc is per-process, not global/stop-the-world 2) the VM is responsible for scheduling processes using threads, and can pre-empt...blocking the scheduler is considered a VM bug.
Post reply on HN