Live data from Hacker News

Elixir 1.5 released

github.com

141–150 of 167 posts

Re: Elixir 1.5 released

#141

Earlier quoted context omitted.

For single a web api server Elixir is going to be far behind, performance wise, against nodejs, the JVM and Go. Their big feature is reliability/clustering but in the context of web requests, scaling them is real easy today, just use a load balancer. For me Erlang/Elixir have very specific niche use cases(at which it excels at) but its fans confuse beginners promoting it as a "general purpose language" that they shou…

> For single a web api server Elixir is going to be far behind, performance wise, against nodejs, the JVM and Go. To some Go web api frameworks perhaps. To the JVM, not really. The frameworks I used with it in the past (spring/play/coupleOtherSmallOnes) are throttled to the number of threads for concurrent connections. The BEAM (Erlang/Elixir) has no such limitation and it blew away my old Java servers handily just d…

I have a hard time believing it's faster than a JVM solution, especially since you think Go is categorically faster than the JVM.

For example, Jetty will beat every HTTP hello-world you can write in Go. I know because I've tried to beat Jetty in Go.

Re: Elixir 1.5 released

#142
post #136

Could somebody explain the @impl feature in a little more detail. I'm confusing the terminology of callback functions I think.

Before this change, if you wrote a module (let's call it MyFoo) that implemented a behaviour, your only clue would be the `@behaviour Foo` near the top. All the functions in MyFoo would look the same; you'd need to look in the Foo module to look at Foo's list of callbacks if you wanted to know which of MyFoo's functions implemented Foo's callbacks.

Now with this change, you are free to mark those functions in MyFoo with `@impl true`. It's entirely opt-in, but once you use it, it enforces the presence of `@impl true` on all MyFoo's callback implementations. This allows the programmer to make these functions' purpose clear, and uses the compiler to make sure the annotations aren't stale or incorrect.

Re: Elixir 1.5 released

#143

Earlier quoted context omitted.

> there's definitely value in immutable data in a dynamic language. Sure, but there's even more value in immutable data in a statically typed language, because of all the advantages that come with such a language (automated refactoring, better performances, tooling, etc...).

I've been working with the BEAM (via Erlang) for over a decade, and with Elixir for almost 1.5 years, and I'd still give up, well, probably my current job if I could get a fully Hindley-Milner Typed Elixir...

I've always assumed that a statically typed Elixir would look a lot differently, especially, vis a vis, macros. Is that a fair assumption?

Re: Elixir 1.5 released

#144

It's a fast-paced development! That's pretty great. I hope core team would consider slowing down a bit and catch up with Deployment, Monitoring(which Phoenix team working on it) and Platform(e.g. http/2) departments. v1.5 seems to have a bunch of bug fixes and deprecation (Hah! I'm not sure if it's like move fast and break thing). It is potentially the case. In every important part, there seems to have a solo smart p…

You may want to check out the recent 2.0.0 release candidates for the Cowboy HTTP server -- HTTP/2 support is one of the changes. (It's technically Erlang, but most Elixir projects I've seen use it for HTTP, generally through the Phoenix framework.)

https://github.com/ninenines/cowboy

Re: Elixir 1.5 released

#145
post #70

Earlier quoted context omitted.

Also, Bleacher Report is a pretty large site on it: http://www.techworld.com/apps-wearables/how-elixir-helped-bl... They went from 150 Rails servers to 5 BEAM servers "and could probably get away with two" (!)

This seems to be the dominant use case for Elixir; migrate legacy Rails code to Elixir. When deciding between Go and Elixir for our startup I looked at both ecosystems. Go was significantly ahead in all categories: traction, articles on the web, packages on git, git activity, editor support ... I don't regret choosing Go but I always keep an eye out on Elixir. Pattern matching, pipe operator, immutability, supervisor…

Go doesn't quite have the right level of abstraction for building CRUD apps. In particular, working with relational databases is very manual. Even using things like sqlx.

Re: Elixir 1.5 released

#146

Earlier quoted context omitted.

Elm works very well with Elixir[0] [0] https://www.dailydrip.com/topics/elixirsips/drips/phoenix-an...

In what way does Elm work better with Phoenix than, say, with Rails or Django?

For me it was that the mindsets of Elm and Elixir were very similar. Create small functions that accept data, and emit data, sometimes create a message with some data attached to it. Using pattern matching is very similar between both languages for matching on message types and shape. Also both languages share a nearly identical pipe operator, which influences the building of very strait forward function pipelines for transforming input or data into responses and output.

Re: Elixir 1.5 released

#148
post #108

Earlier quoted context omitted.

For an improvement of 2 orders of magnitude while maintaining the same level of developer complexity, I'm hard pressed to think of any other web framework besides Phoenix that can deliver this.

Java and C# easily outclass Phoenix i performances, if only because they are statically typed, but also because they run on VM's that are more advanced (and admittedly older, so more optimized) than BEAM.

Minor correction, BEAM is just as old if not a couple years older than JVM.

https://en.wikipedia.org/wiki/Erlang_(programming_language) https://en.wikipedia.org/wiki/Java_virtual_machine

Re: Elixir 1.5 released

#149

Earlier quoted context omitted.

> For single a web api server Elixir is going to be far behind, performance wise, against nodejs, the JVM and Go. To some Go web api frameworks perhaps. To the JVM, not really. The frameworks I used with it in the past (spring/play/coupleOtherSmallOnes) are throttled to the number of threads for concurrent connections. The BEAM (Erlang/Elixir) has no such limitation and it blew away my old Java servers handily just d…

I have a hard time believing it's faster than a JVM solution, especially since you think Go is categorically faster than the JVM. For example, Jetty will beat every HTTP hello-world you can write in Go. I know because I've tried to beat Jetty in Go.

I believe what Overmind meant was that a single request in another language can probably beat Elixir in performance, but Elixirs ability to handle a large amount of requests concurrently means that it'll have better throughput.

For example, if a web request in framework A takes 100ms and framework B takes 200ms, but framework B can handle 4,000 requests concurrently and framework A can handle 1,000 requests concurrently, then framework B will beat framework A in handling 20,000 requests.

framework A - (20,000r / 1,000r) * 100ms = 2,000ms

framework B - (20,000r / 4,000r) * 200ms = 1,000ms

Re: Elixir 1.5 released

#150

Earlier quoted context omitted.

> there's definitely value in immutable data in a dynamic language. Sure, but there's even more value in immutable data in a statically typed language, because of all the advantages that come with such a language (automated refactoring, better performances, tooling, etc...).

I've been working with the BEAM (via Erlang) for over a decade, and with Elixir for almost 1.5 years, and I'd still give up, well, probably my current job if I could get a fully Hindley-Milner Typed Elixir...

I guess your job is mine now :)

https://github.com/alpaca-lang/alpaca

Post reply on HN