I think WhatsApp is still using Erlang and they are biggest messaging app in the world. Discord is using Elixir but it's more niche. I think if you look at use cases where they excel, you will find them there.
Overkill I suppose, in the past for similar stuff I've used a microcontroller with a GPRS modem, but since the 2g switch off I'm not sure it can be done that simply.
Their security team should vet all of these devices, create environments where it's safe for them to be on the network, and ensure they're kept up to date also?
The point is they shouldn’t need to test everything and someone self submitting an add on for review to be featured isn’t what triggers an additional device.
Does toilet training your cat introduce a significant health hazard through toxoplasma gondii into the surrounding environment? It's so hard to tell if your local wastewater plant takes care of this...
I could have sworn I read something to this effect, that this is ill advised because waste treatment plants aren’t really equipped to handle animal parasites
There have been multiple instances of games being anounced to release on Steam/others and then some time later Epic signed an exclusive contract with them. This even happens with crowdfunded indie games [1] or games that had already started pre-orders. Even though moves like that are unpopular, Epic said they will remain a core part of their strategy [2].
(True the developers themselves agree to that exclusive contract, so they share some of the blame of disappointing people, but if you're an indie developer it is hard to say no to that much money)
I own Rocket League on Steam. They bought the game, took it off the Steam store and eventually my operating system entirely, to push their launcher. Not chuffed.
Epic can't do that alone... it requires cooperation from and agreement with the game publisher.
Don't blame Epic for spending money to bring customers to their product. Epic aren't using shady tactics to do this, and Valve is free to do everything Epic is doing.
Also, as a game buyer, you DEFINITELY want a multi-source purchasing ecosystem; you definitely want to avoid a monopoly if the price you pay for games is important to you.
Exclusives are explicitly not multi-source. I want to be able to buy the games I want to play on the platform I want to play them on. This isn't always feasible, and that's OK, but it really grates when it's deliberately pushed in that direction.
they are trying by buying out publishers to only release it on epic or only release it on epic for the first year.
their client is super garbage. like battlenet if you leave it open it hogs your cpu.
the fact that a game can turn the store color into a white client is insane to me.
> I think the big difference between is how Epic treats its customers and how Valve treats its customers. Epic could've gone the GOG Galaxy route ("use it, or not, your choice"), but they decided to force people into their watered down launcher before it was ready. Even Xbox is being more open lately.
> You can't just match your competition, you have to exceed it in some special way before people will switch.
GGP:
> how are they forcing anyone?
I answered that question. That Steam is also doing it is whataboutism, but also entirely besides the point. Steam however is a much more full-featured client, which also factored into GGGP's argument.
But a more pointed answer to GGP would've been that Epic has paid external developers for (timed) exclusives.
Erlang has a bunch of tools to help enforce determinism or at least suss out concurrency issues. For example: you can specify multiple receive statements to process your queued messages in a specific order, there is also a process manager (pman:start()) that allows you to explore concurrency related events, and not to mention Mutex Semaphores as a pattern to mitigate those issues.
There doesn't seem to be a real solution to deadlocks. I got the oreilly book in front of me and it's basically saying: be careful, but don't worry.
And I don't think erlang has a shared mutable states. In fact a google search for "erlang shared mutable state" has you as the first result.
You have ETS and Mnesia that are technically shared mutable state, and people have built Raft / Paxos / DeltaCRDT / etc. which also provide some form of it -- albeit a safe one -- but while it does exist, actually sharing the state between PIDs is a very rare thing ime. I don't have super in-depth experience in the Erlang ecosystem, so take this with a pinch -- or handful! -- of salt ofc.
ETS is isomorphic with a data table process that processes get and set (and etc) messages, but happens to be quite a bit faster.
If ETS is shared mutable state, so is a process with state that accepts changes, as chrisseaton posits. Of course, shared mutable state with clear boundaries between mutations is a lot better than shared memory where everyone can write and read things in bits and pieces.
> And I don't think erlang has a shared mutable states.
Arguably (well, of you ignore the process dictionary, which everyone seems to) Erlang lacks local mutable state, but has shared mutable state through actors.
I feel like this whole thread could stand to have people more clearly define the way they are using the term. I don't know of any "immutable" system that literally never changes or something. If Erlang is "mutable" in t sense, what system isn't?
I've seen such ideas tossed around, but I don't think I've ever seen an implementation.
> And I don't think erlang has a shared mutable states
An actor has state. It's mutable - each message can modify it. It's shared - two process working with a shared actor share that state. To me, that's shared mutable state. It causes classic race conditions.
(I know this is an unpopular opinion, and somewhat deliberately contrary and provocative, but ultimately truthful.)
While this is technically "shared state" (in the same way that a "database", or "the console/log output" is "shared state"), it's not a problem in the classical data race sense. And because you're forced to think about it in an explicit fashion, it's generally not a problem for the working programmer in the BEAM vm.
Also note that erlang is not a pure actor system. It is relatively hard to accidentally write a deadlock in erlang with OTP. In about 3 years of programming elixir I've only written a deadlock three or four times (and caught them all in tests). Even so if I had pushed it to prod, it would have timed out certain operations that would have triggered dynamic restart of the relevant processes.
two process working with a shared actor share that state
I think this is where I disagree. They may share an actor but the state of the actor belongs to the actor. To say they share it implies they can always change it independently but that's not the case. Actors don't trample on each other's internal states. For example a simple mutex semaphore pattern fixes your race condition.
> They may share an actor but the state of the actor belongs to the actor. To say they share it implies they can always change it independently but that's not the case. Actors don't trample on each other's internal states. For example a simple mutex semaphore pattern fixes your race condition.
The actor's state is shared in the sense that both processes can change it in ways that are visible to each other. The actor can control access to it, but unless the actor never changes state in response to messages (in which case why bother with actors at all?) there's still something that changes. Constrained state is still state.
yeah I would say in principle this makes sense but in practice a junior will typically say "this is beyond me but you're the senior so if it works, it works!"
It is an opportunity to go through the code and concepts at least.
