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

Elixir – The next big language for the web

creativedeletion.com

Post reply on HN
Print view View original

81–85 of 85 posts

Re: Elixir – The next big language for the web

#81

Post by alco »

laut wrote: post #12
sergiotapia wrote: post #10

I think the next big thing is Meteor. Here's why: 1. Real-time baked in. 2. Uses Javascript (tons and tons of developers know at least enough to use Meteor) 3. Sane templating engine. 4. Same wow effect I had when I first started Rails. 5. Fantastic build system. Pheonix and Elixir may be the bees knees, but unfortunately because it uses a functional language, it drastically cuts down the mindshare of developers. I d…

Javascript has functional features too. A lot of Elixir developers come from platforms such as Python, Ruby, node.js

JavaScript has functions. The list pretty much ends there. There are some libraries that provide "functional features" like functions over collections, persistent data structures, promises. The language itself and the environment it's running in (DOM or Node) do not have a lot going for them in terms of functional programming essentials.

Re: Elixir – The next big language for the web

#83

Post by pbowyer »

pron wrote: post #77
yellowapple wrote: post #74

Earlier quoted context omitted.

I agree with most of your points. However: > though personally, I prefer the JVM, which can do anything BEAM does only better In my experience, this couldn't be farther from the truth. Java's threading model is bloated and slow compared to Erlang's process model, and that process model - the ability to spin up processes so lightweight that they make even Java threads look heavy in comparison - is the key to its succe…

> the ability to spin up processes so lightweight that they make even Java threads look heavy in comparison - is the key to its success when it comes to parallel and distributed computing. Except you can do the same in Java -- see Quasar or Erjang -- the JVM is so powerful that true lightweight threads -- just like Erlangs -- can be added as a library. > I've found Erlang applications with BEAM to perform far better…

> (BEAM is excellent at scheduling, but pretty terrible at running user code; it's notoriously slow, which is why all important Erlang library functions are implemented in C, and why heavyweight Erlang shops do a lot of C coding; when you do Erlang, it's often Erlang and C if performance is important).

That's really useful to know - I'd not heard about this before, only that Erlang was fast!

Re: Elixir – The next big language for the web

#84

Post by pron »

pbowyer wrote: post #83
pron wrote: post #77

Earlier quoted context omitted.

> the ability to spin up processes so lightweight that they make even Java threads look heavy in comparison - is the key to its success when it comes to parallel and distributed computing. Except you can do the same in Java -- see Quasar or Erjang -- the JVM is so powerful that true lightweight threads -- just like Erlangs -- can be added as a library. > I've found Erlang applications with BEAM to perform far better…

> (BEAM is excellent at scheduling, but pretty terrible at running user code; it's notoriously slow, which is why all important Erlang library functions are implemented in C, and why heavyweight Erlang shops do a lot of C coding; when you do Erlang, it's often Erlang and C if performance is important). That's really useful to know - I'd not heard about this before, only that Erlang was fast!

Erlang is actually quite slow; it just responds quickly and has excellent concurrency. The programming language shootout places Erlang HiPe (high performance) at 2x-22x slower than Java (http://benchmarksgame.alioth.debian.org/u64q/erlang.html) and sometimes faster and sometimes slower than Python (http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...).

That's why Erlang is often used as the application control plane, routing requests and the like, while actual data processing is done in C.

Re: Elixir – The next big language for the web

#85

Post by lectrick »

ab5tract wrote: post #68
lectrick wrote: post #22

Earlier quoted context omitted.

> but unfortunately because it uses a functional language, it drastically cuts down the mindshare of developers. I don't even know any developers in real life that use functional languages. 1) Once upon a time, almost no one used object oriented languages except for Smalltalk weirdos. 2) Ruby, javascript and a host of other languages have "functional" features. Does your language have a "lambda" feature, where you ca…

Right... Another fad brought up for the sheer fashionability of it. Saying "mutable state is bad" is just as inane as saying "immutability is bad". There are tradeoffs for either. There is absolutely no reason to pretend that one trumps the other in all cases. Other than looking cool to your peers, I guess.

I spent over 10 years writing and working on (and debugging... many hours of debugging) Ruby code.

Towards the end I started to write all my Ruby code, as much as possible, as so-called PORO objects (Plain Ol' Ruby Objects). These feature zero inheritance, and are initialized with all the state they need to do their work. I started doing this because I found that writing code that way produced more easily testable, more maintainable, more stable code.

Then I realized that functional languages basically all already forced you to do those things, by not holding state anywhere, forcing you to pass it around.

These were all logical steps (with the end goal optimization of "useless work elimination"). There was no faddiness involved, other than having "a good feeling" about working with Elixir (over, say, Clojure, Haskell or the other options out there).

Post reply on HN