`mix phx.new foo --no-live` does that. LiveView is completely optional. Node/npm has been completely replaced by esbuild and even that is optional if you want to rip it out and handle assets another way.
338 karma · joined September 18, 2015
Not sure I feel the same warm feelings about umbrella apps and I definitely don't think you can compare them to general-purpose container orchestration like docker-compose, but that's totally an optional part of the language.
Otherwise, yes, Elixir/BEAM is an excellent soft real-time environment for developing chat applications. If your scale goes off the charts (millions of concurrent users), you can extend with Rust for the slower operations in your critical path. See https://discord.com/blog/using-rust-to-scale-elixir-for-11-m...
As mentioned, Phoenix Channels is a great place to start and will get you very far. The other nice and unique things in Elixir & Phoenix (OTP, LiveView, etc.) are just a bonus.
This is not an editorial document, it’s a legal complaint by the Attorneys General of 17 U.S. states and commonwealths demanding a jury trial (among other things). The allegations are unproven at this point. The demanded trial process (discovery, examination, etc.) is what will provide the evidence.
One way or another though, we’re going to see if all of these claims are true. It just will take some time.
Though, in fairness to ljf, your tl;dr at the top says "Please stop; write a blog post instead."
“The law generally treats a failure to return money that is wired by mistake as unjust enrichment or conversion and requires that the recipient return such money to its sender. Under New York law (which applies here), however, there is an exception to this rule: The recipient is allowed to keep the funds if they discharge a valid debt, the recipient made no misrepresentations to induce the payment, and the recipient did not have notice of the mistake.”
I’m assuming no debt was owed to these random people.
>It got most of its (now faded) hype by trashing Ruby, which rubbed me the wrong way.
It's a programming language, not a sports team. Developers excited about a new language are allowed to be excited and compare with other languages. I don't know what trashing you saw that offended you, but commenting on every HN post to try to steer people away is unproductive.
I understand you needed an example, but a better comparison would be a heavy SPA with real-time interactivity. In that case, if your server is down your API calls will fail and you're going to have to handle the failure and let the user know something went wrong any way. If anything, Live View's built-in buffer and retry can actually provide a better user experience because the UI will automatically "catch up" when the client reconnects.
> You also don't want to disable this visual warning because on slower devices it might take 2 seconds to load the page which is much different than an uncontrolled disconnect.
Live View loads the entire initial page over HTTP, then mounts the Live View. Your slow device won't see any difference if the visual warning is disabled or not.
Here is the documentation for Phoenix channel authentication (what Phoenix Live View is built upon): https://hexdocs.pm/phoenix/channels.html#using-token-authent...
Additionally, here is some documentation on the security considerations specific to Live View: https://hexdocs.pm/phoenix_live_view/security-model.html
Searching can probably find you more information.
Because you can do things stateless HTML alone cannot do.
No one is trying to re-implement HTTP, or even remove it from the equation.
What people are trying to reimplement (or rather, replace) is the HTML + JSON:API + React + Redux mess. Websockets is a means to that end.
You are exactly correct: Apple silicon. Intel is calling out a singular competitor. Apple called out all PCs.
> They want Apple to use Intel chips for refreshes on the bigger devices (MBP16 still ships with 9th-gen Intel, iMac with 7th-gen).
If there are generation-bump Intel refreshes for those machines coming, they have either been planned all along or will be a result of unexpected problems getting the M1X (or whatever would be in the those machines) ready or available. Intel isn't going to convince Apple to delay their architecture transition, especially now that they have released ads attacking their products.
> Anything they can do to delay Apple Silicon market takeup will dampen the attractiveness of post-M1 models running Apple Silicon, because nobody wants a machine with sparse software availability and that's a problem that won't get resolved until the user base is much bigger.
Oh, I agree this is their intent. But trying "Anything they can do" means they aren't coming from a position of strength.
If the Apple ad said "Mac is so much better than the Dell XPS", that would be different.
They are not suggesting the ad is making people aware of Apple. They are suggesting that the ad is making people aware that Intel sees the M1 as a legitimate competitor, therefore suggesting to buyers that it is a worthy alternative to Intel's products. An unintended consequence of attacking a specific competitor or product is that you can raise awareness of the value of your competitor's product.
I'd guess the building is named after the Library of Alexandria – one of the largest and most significant libraries of the ancient world – and not because of a god complex as the story implies.
I know little about lambda. Provisioned capacity, as in an instance running 24/7? Like a server?