Elixir 1.9 • Hacker News Board

Re: Elixir 1.9

#171

Post by pdimitar » Tue, Jun 25, 2019, 9:59 PM UTC

59nadir wrote: post #162

enraged_camel wrote: post #161

Earlier quoted context omitted.

Friend, you're making a lot of assumptions and claims about people you don't know (including me), and have a certain streak of arrogance that is difficult to get past. This makes it impossible to have a productive conversation, if having a productive conversation is your goal. I advise some humility, as well as some effort to recognize that your opinions sound very dogmatic. You are of course free to like or dislike…

> Friend, you're making a lot of assumptions and claims about people you don't know (including me), and have a certain streak of arrogance that is difficult to get past. This is rich, coming from someone who claimed that anyone who wants a type system in elixir hasn't actually used elixir. > You are of course free to like or dislike any language you want, ... This is the most common reaction within the elixir communi…

> This is the most common reaction within the elixir community, to assume that anyone who doesn't put the language on a pedestal dislikes it or hates it.

Not sure you and I read the same forum. My reaction to Elixir criticism usually is -- "well, if you dislike it for this or that reason, or simply don't find it useful, then don't use it, there are a lot of other languages out there". Many others do the same.

I haven't noticed cargo-culting on ElixirForum in a long time. You might simply be too cynical to differentiate people whose work life has been genuinely improved (and they express that sentiment on the forum) and people who overhype something you dislike (for valid reasons for your use-cases).

Re: Elixir 1.9

#172

Post by brightball » Tue, Jun 25, 2019, 11:01 PM UTC

cryptica wrote: post #143

brightball wrote: post #78

Earlier quoted context omitted.

Eh...it’s basically a 1 line command with distillery. Another for the rollback capability. It’s pretty magical. There’s a reason people love it. Certainly, don’t use it if you don’t need it...it introduces extra complexity...but if you do it’s really hard to beat.

Having to support two different versions of the Elixir service during the rollout period is risky... What if something goes wrong during the rollout? For example, if you change the database schema or upgraded your database engine or changed your back end authentication approach, it can break the old code. Then how will you know whether it's a problem with the old code or new code if many nodes are running both?

Those are things you have to account for in any zero downtime deploy situation though. It’s mostly minor changes in how you roll out schema changes.

Re: Elixir 1.9

#173

Post by gamache » Wed, Jun 26, 2019, 10:31 AM UTC

nivertech wrote: post #163

gamache wrote: post #60

Earlier quoted context omitted.

The cognitive load is quite low when deploying changes which only involve your app code (i.e., no dependency upgrades). My app has a few tens of millions of open websockets at a time, and it's worth it to me to avoid mass reconnects. I'm not everyone, but my use case isn't totally unique either.

"Few tens of millions of open websockets" is more than Slack and Discord combined, not? BTW: we were the first who did 1M long-living connections load test with Cowboy on a single EC2 instance back in 2011. And 3M long-polling HTTP requests on a single beefy physical server. It was before WhatsApp upstreamed their optimizations and before Phoenix team made it easy.

I imagine both Slack and Discord have much higher numbers than this, as well as a very different workload (they're doing chat, we're not).

I don't want to give the impression that this is happening on a single server, either! I did the cowardly thing and threw more boxes at the problem. :)

Re: Elixir 1.9

#174

Post by yellowapple » Wed, Jun 26, 2019, 6:15 PM UTC

yellowapple wrote: post #108

superdisk wrote: post #14

Earlier quoted context omitted.

Wait, what? I wrote an Elixir/Phoenix webapp around 2015 and one of the major selling points was the ability to hot-upgrade code that was inherited from Erlang. What changed?

Nothing changed; hot code reloading is still possible through the mechanisms that have always existed. What's being stated here is that the new Elixir support for "releases" does not include support for this, so you would have to use a separate mechanism to perform the hot code reload. That "separate mechanism" could be as simple as a plug that tells Mix to recompile and reload. Example (designed for - and part of -…

As a bit of a correction here to my own comment, it looks like Elixir releases don't ship with Mix, so the above example probably wouldn't work in that particular scenario (unless maybe you figure out some way to include Mix).

So the better option would be to figure out a way to compile a new release, get the modules in place where the currently-running release expects them, then write up a plug similar to the above to check for new module versions and load them (or just do it as part of whatever mechanism you'd use to get the updated modules into the running release in the first place).