easychris

Hm. 4.6M „voters“, and I know a couple of persons who were not able to vote due to server issues. I also doubt that the way the voting was setup was safe against the most basic manipulations (e.g. voting multiple times).

I’d say that this was not a representative poll. ;)

Unfortunately directly booking with the hotel has drawbacks as well. 6 months ago I booked The Pullman Hotel in London directly (they had the same pricing as the online agencies).

When I arrived late in the evening my room was not available: the (online, credit card backed) reservation I've made was "lost" and no more rooms available.

There was no way to sort it out easily so I booked another Hotel (higher price, and had no time to do some Tripadvisor/Rating research).

The exactly same thing happened when I booked a hotel in Czech last year via HRS. When I arrived I was told by the hotel guy that there was only 1 room available instead of the booked 2. I tried to sort it out directly with the hotel - no chance after 10 min. of discussions.

I then called the HRS hotline, the service agent put me on hold while he called the hotel. I saw the guy at the reception pick up the phone, a few seconds later he came to me and told me that 2 rooms were available. :/

That said: it seems that the OTAs (HRS, booking, expedia) have enough "arguments" (e.g. threaten with delisting etc) that as a customer you may also have benefits from this kind of oligopoly.

I think it's also about the ecosystem. With Elixir all third party packages etc. can be relied on having no side-effects / immutability.

If you try to code functional in an OOP language, you would have to make sure that no third party modules (or coworkers accidentally) write code that "misbehaves" in such aspects. Just like you currently have to make sure that the Ruby code you use is threadsafe.

With immutability you gain all those features baked into Erlang/OTP (scalability, reliability).

That's true for threads (although most of your threads should be blocked by IO, e. g. DB queries, and that means the GIL lock isn't a big issue).

But the beauty of HTTP is that you can scale simply by adding more "endpoints". That means you can add as many processes (workers) as necessary to utilize all CPUs, or even add as many servers as you can afford.

I'm not saying that Elixir does not do a better job with it's lean processes and built-in OTP stuff.

But it's not true that you can't utilize all CPUs with a Rails app.

I think that's not true. If you have e. g. 4 cores, and you start Puma with 4 workers (i. e. processes) it will utilize all cores.

I guess you're mixing up processes with Ruby threads.

You normally start as many Puma processes as your CPU/Core count with probably additional threads per workers.