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

Elixir and Phoenix after two years

nts.strzibny.name

Post reply on HN
Print view View original

71–80 of 111 posts

Re: Elixir and Phoenix after two years

#71

Post by literallyWTF »

dmitriid wrote: post #47
astrowilson wrote: post #25

Earlier quoted context omitted.

> and perhaps there could be a more concise enhancement of Erlang which would get the job done Erlang already is a more concise language than Elixir but also noisier as there are more punctuation characters. I would love if Erlang would drop some of its punctuation, as some of it is frankly unnecessary. Elixir syntax is definitely simpler than Ruby’s. Probably in the same ballpark as Python complexity wise: Elixir ha…

> Erlang already is a more concise language than Elixir but also noisier as there are more punctuation characters. What? Here's more-or-less the entirety of Erlang's "noisier syntax with more punctuation characters" -spec f(A :: any(), B :: some_type(), C :: list()) -> any(). f(A, {B}, [C | _]) -> A1 = fun() -> io:format(a, []) end, A1(), case C of > -> 1; _ -> #person{ok = ok, field = C} end. Edit: %% plus map synta…

My god, it’s like Perl but somehow worse. How do you even keep track of what’s going on?

Re: Elixir and Phoenix after two years

#72

Post by TylerE »

toolz wrote: post #10
blunte wrote: post #3

To add to the author's experience, I spent 18 months of production time with Elixir and Phoenix. As he says, the templates are compiled and are blindingly fast compared to Rails. Pattern matching is really really nice when used in the right places (and you'll miss it if you go back to Ruby); but it can be overused. There's a faction of Elixir folks who attempt to avoid all conditionals and instead seem to prefer mult…

sqlalchemy is an ORM - I'm not sure it can be compared against a web framework, but my experience with phoenix vs python web frameworks is that phoenix is easily faster even for single-threaded web requests (which of course will utilize many threads for things like DB thread pooling etc.)

sqlalchemy contains an ORM.

You can do a ton with it without ever importing sqlalchemy.orm.

Re: Elixir and Phoenix after two years

#73

Post by jfim »

dnautics wrote: post #60
jfim wrote: post #55

Earlier quoted context omitted.

Pretty curious about this, are there more details that are publicly available? The only thing I can find about this is some meetup from 2018 with a speaker from Pinterest.

I, too, want to hear about this mythical columnar database in Elixir (or databases!!, if there are two!).

If not we'll have to write our own by duct taping multiple instances of DuckDB. :)

Re: Elixir and Phoenix after two years

#74

Post by innocentoldguy »

void_mint wrote: post #54
heipei wrote: post #46

Earlier quoted context omitted.

Let me tell you the single reason I haven't switched to Elixir yet: I develop backend and frontend (SPA) so I'd rather just stick with a single language and library catalog. It helps that there's plenty of libraries in JS land too. I would love to just write elixir code but at the end of the day I feel sticking with node+browser js is the more pragmatic choice right now.

Isn't phoenix meant to remove the JS dependency on FE dev? (Not arguing with any of your points btw, JS is matter-of-factly more popular and pragmatic).

I agree that JavaScript is more popular, but I think it is the least pragmatic language I've ever used.

In my mind, a pragmatic language doesn't do things like:

1. Have multiple ways to define a function. 2. Handle functions differently depending on how they're defined. 3. Allow silly things like 2 + "2".

Re: Elixir and Phoenix after two years

#75

Post by gregors »

onlyrealcuzzo wrote: post #39
blunte wrote: post #18

Earlier quoted context omitted.

In my case it was a team of 1 working on OTP 19 and 20. Since that is now 3+ years ago, it is quite possible things have improved in the single-thread performance area.

Elixir single thread performance /is/ much faster than Ruby and Python [1]. Are you sure you weren't just doing something sub-optimal with Ecto? [1] https://amp.reddit.com/r/elixir/comments/46v1l1/is_elixir_fa...

I'm a huge elixir fan, but in micro made up benchmarks I consistently see Ruby win over Elixir. I haven't run it with the jit.

One specific case that cripples Elixir - is as far as I know Elixir can't handle large multiplications efficiently. Ruby, Python use karatsuba or some derivative - from what I can tell multiplication in Erlang doesn't. Though I haven't actually asked anyone and was just poking around on my own.

example: Multiplying the first 100_000 numbers together I get

ruby multi.rb 3.47s user 1.91s system 99% cpu 5.396 total

elixir multi.exs 14.32s user 0.62s system 103% cpu 14.441 total

Re: Elixir and Phoenix after two years

#76

Post by toast0 »

ch4s3 wrote: post #33
blunte wrote: post #16

Earlier quoted context omitted.

I should have been clearer in my final note. My Elixir vs Python example was for standalone batch (script) processing. It was not in the context of a webapp. The case was a recurring calculation system which would take a few hundred thousand records and do about a dozen different calculations against those (some calculations requiring additional lookups). The original script was in Python, and then after the new weba…

Ahh, ok. You've sort of hit a weird spot for Elixir. Python will just start up faster and that will be noticeable. Math is much better optimized in Python, though this is changing with NX. The real gain here would probably be streaming chunks of rows out of ecto and maybe firing those off to tasks per CPU core. Which is easier than it sounds. That said, you had working code so no real reason to rewrite it except as a…

Typical ways to start beam end up doing a lot of work you might not need.

Taking some time to fiddle with the startup settings for a short running task can make a big difference. You might actually get better results by setting it to single cpu, because there's less setup that way. Really depends on how much total cpu time your work takes. If your VM is going to run for a year (or more), startup time hardly matters and so the defaults aren't highly tuned for a 30 second script.

Re: Elixir and Phoenix after two years

#77

Post by aantix »

ch4s3 wrote: post #44
davidw wrote: post #36

Earlier quoted context omitted.

Rails has a ton of high quality code available for it. It looks to me like Phoenix is certainly 'good enough' for a lot of tasks, but it just hasn't been around as long. I'm looking for those use cases where someone picked Phoenix and it was just clearly a better tool than, say, Rails because of X, Y, and Z, despite maybe being inferior for one or two other things.

Having done both, I think Rails has a ton of baggage around ActiveSupport and ActiveRecord that are full of gotchas. Ecto prevents N+1 queries by default, which I think is clearly better. I also think that the lack of lifecycle hooks in Ecto is a better decision than the pile of foot guns in ActiveRecord hooks. I would also argue that Plug is a large improvement over Rack, and the idea of explicitly passing a single…

>Ecto prevents N+1 queries by default, which I think is clearly better

How does it know what associations to eagerly load without knowing about the views? It can't eagerly load all of the data on complex objects.

Re: Elixir and Phoenix after two years

#78

Post by AlchemistCamp »

iudqnolq wrote: post #66
AlchemistCamp wrote: post #62

It's always interesting to read these and I completely agree with the author's comments on productivity (both on Phoenix and Rails). It's a major reason why I learn and teach Elixir, even though it's niche. I genuinely want the skills! One thing to that stood out was how the author found deployment easy, the same as I first did 5 years ago: > "The deployment of Phoenix can be as easy as copying the Mix release I alre…

I've found the release story to be lacking. For example, the suggestions I've seen for automatically running migrations after launch can blow up if you have traffic between the deployment start and the migration end. Even if I accept downtime, I've found mix annoyingly low level.

How do you run database migrations on Rails, Laravel or whatever your framework of choice is?

Re: Elixir and Phoenix after two years

#79

Post by AlchemistCamp »

aantix wrote: post #77
ch4s3 wrote: post #44

Earlier quoted context omitted.

Having done both, I think Rails has a ton of baggage around ActiveSupport and ActiveRecord that are full of gotchas. Ecto prevents N+1 queries by default, which I think is clearly better. I also think that the lack of lifecycle hooks in Ecto is a better decision than the pile of foot guns in ActiveRecord hooks. I would also argue that Plug is a large improvement over Rack, and the idea of explicitly passing a single…

>Ecto prevents N+1 queries by default, which I think is clearly better How does it know what associations to eagerly load without knowing about the views? It can't eagerly load all of the data on complex objects.

It doesn't eagerly load anything. It preloads exactly what you tell it to.

Ecto Repo vs Active Record: https://youtu.be/IFKG4Hgt-zM

Re: Elixir and Phoenix after two years

#80

Post by strmpnk »

gregors wrote: post #75
onlyrealcuzzo wrote: post #39

Earlier quoted context omitted.

Elixir single thread performance /is/ much faster than Ruby and Python [1]. Are you sure you weren't just doing something sub-optimal with Ecto? [1] https://amp.reddit.com/r/elixir/comments/46v1l1/is_elixir_fa...

I'm a huge elixir fan, but in micro made up benchmarks I consistently see Ruby win over Elixir. I haven't run it with the jit. One specific case that cripples Elixir - is as far as I know Elixir can't handle large multiplications efficiently. Ruby, Python use karatsuba or some derivative - from what I can tell multiplication in Erlang doesn't. Though I haven't actually asked anyone and was just poking around on my ow…

I was curious to see what my JIT build looked like for me so I ran the following: https://gist.github.com/cararemixed/c232b888b9dbdaeb67967f35...

This shows a significantly different story between the two with at least similar code. Note I am not trying to optimize for the fastest factorial here as both can be made much quicker but roughly equivalent code seems to tell a different story for me.

(NOTE: I put the code in a module as iex interpreted expressions on the top level are always slower than compiled modules, even when pasting them into iex. Doing the same for Ruby didn't show any difference for me.)

Post reply on HN