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

What I've Learned (So Far) Building Online Mini Games with Elixir and Swift

calvinflegal.com

Post reply on HN
Print view View original

11–20 of 44 posts

Re: What I've Learned (So Far) Building Online Mini Games with Elixir and Swift

#11

Post by frail_figure »

apt-apt-apt-apt wrote: post #9

Really interested in hearing more about the architecture. Especially (1) why you chose Elixir, Phoenix over TS (2) how you dealt with real-time multiplayer. Aside: The links to the web game in the post don't lead to being able to play.

Not OP, but TS (as in TypeScript, right?) is not even in the same universe as Elixir with Phoenix when it comes to building backend services.

It's a very productive and readable programming language with excellent documentation and conventions, and the most ergonomic way of handling concurrent operations (thanks BEAM) I've encountered.

The VM it runs on was originally designed for telephone switches, which, it turns out, cleanly translates to the internet/http era.

It makes it trivial to do soft-realtime because it's just actors (GenServers) passing messages.

I invite you (and others) to try it out and do a small weekend project. It'll make you reconsider reaching for TS on the backend :)

Re: What I've Learned (So Far) Building Online Mini Games with Elixir and Swift

#12

Post by frail_figure »

zuzululu wrote: post #7

was expecting a bit more substance but always interesting to read different approaches. but I do wonder if BEAM is a bit of an overkill, even fly.io (known among developer threads to be very unreliable uptime) wouldn't be my first pick. Cloudflare Durable Objects really is generous, not often can you get replicated database and realtime sync for such low barrier in cost and implementation. I do wonder tho what Cloudf…

> Cloudflare Durable Objects really is generous, not often can you get replicated database and realtime sync for such low barrier in cost and implementation.

BEAM gives it to you for free, and you don't rely on an Internet-scale monopoly to run it.

Re: What I've Learned (So Far) Building Online Mini Games with Elixir and Swift

#13

Post by mcintyre1994 »

apt-apt-apt-apt wrote: post #9

Really interested in hearing more about the architecture. Especially (1) why you chose Elixir, Phoenix over TS (2) how you dealt with real-time multiplayer. Aside: The links to the web game in the post don't lead to being able to play.

I’d guess that 2 is a huge part of the answer to 1 here - Elixir makes real-time multiplayer easy.

Re: What I've Learned (So Far) Building Online Mini Games with Elixir and Swift

#14

Post by apt-apt-apt-apt »

frail_figure wrote: post #11
apt-apt-apt-apt wrote: post #9

Really interested in hearing more about the architecture. Especially (1) why you chose Elixir, Phoenix over TS (2) how you dealt with real-time multiplayer. Aside: The links to the web game in the post don't lead to being able to play.

Not OP, but TS (as in TypeScript, right?) is not even in the same universe as Elixir with Phoenix when it comes to building backend services. It's a very productive and readable programming language with excellent documentation and conventions, and the most ergonomic way of handling concurrent operations (thanks BEAM) I've encountered. The VM it runs on was originally designed for telephone switches, which, it turns…

Thanks, interestingly Elixir handles concurrency in what seems like a natural way, actors passing messages to each other. It's cool that this way is used in production, though it seems to be used mainly in niche distributed scaling.

Re: What I've Learned (So Far) Building Online Mini Games with Elixir and Swift

#15

Post by nesarkvechnep »

apt-apt-apt-apt wrote: post #14
frail_figure wrote: post #11

Earlier quoted context omitted.

Not OP, but TS (as in TypeScript, right?) is not even in the same universe as Elixir with Phoenix when it comes to building backend services. It's a very productive and readable programming language with excellent documentation and conventions, and the most ergonomic way of handling concurrent operations (thanks BEAM) I've encountered. The VM it runs on was originally designed for telephone switches, which, it turns…

Thanks, interestingly Elixir handles concurrency in what seems like a natural way, actors passing messages to each other. It's cool that this way is used in production, though it seems to be used mainly in niche distributed scaling.

Not at all. It’s used to build standard web applications too.

Re: What I've Learned (So Far) Building Online Mini Games with Elixir and Swift

#16

Post by w10-1 »

> Also, I would encourage others to target Mac in addition to iOS for a reason you might not expect: build times. The simulators and Xcode are really pretty slow. It’s all a lot faster if you’re targeting Mac.

Yes, this makes my day: (also) target macOS for continuous rapid loops on one project, or target iOS and end up flitting back and forth between many projects. ("mac (made for iPad)" does not work.)

Re: What I've Learned (So Far) Building Online Mini Games with Elixir and Swift

#17

Post by simoncion »

zuzululu wrote: post #7

was expecting a bit more substance but always interesting to read different approaches. but I do wonder if BEAM is a bit of an overkill, even fly.io (known among developer threads to be very unreliable uptime) wouldn't be my first pick. Cloudflare Durable Objects really is generous, not often can you get replicated database and realtime sync for such low barrier in cost and implementation. I do wonder tho what Cloudf…

> but I do wonder if BEAM is a bit of an overkill...

Why would it matter if something's overkill? If it's not much more work, and it runs on the systems you're targeting, it's better to start with something that's more reliable than you might strictly need than to start with something that you believe to be "proper kill", only to discover that you underestimated the amount of "kill" required. Retrofitting things like proper supervision and data/crash isolation can be a huge, huge pain in the ass.

Re: What I've Learned (So Far) Building Online Mini Games with Elixir and Swift

#18

Post by Doohickey-d »

A question for OP: why did you choose Crunchy Data for your database, instead of Fly's own managed postgres offering? Because the latency between Fly and Crunchy Data must be quite high, given that they are probably not in the same datacenter.

Re: What I've Learned (So Far) Building Online Mini Games with Elixir and Swift

#19

Post by hosh »

apt-apt-apt-apt wrote: post #14
frail_figure wrote: post #11

Earlier quoted context omitted.

Not OP, but TS (as in TypeScript, right?) is not even in the same universe as Elixir with Phoenix when it comes to building backend services. It's a very productive and readable programming language with excellent documentation and conventions, and the most ergonomic way of handling concurrent operations (thanks BEAM) I've encountered. The VM it runs on was originally designed for telephone switches, which, it turns…

Thanks, interestingly Elixir handles concurrency in what seems like a natural way, actors passing messages to each other. It's cool that this way is used in production, though it seems to be used mainly in niche distributed scaling.

What people are finding now when building agenic AI orchestrators is that they are reinventing some of the ideas behind BEAM and OTP. The big one being queues (mailboxes), but also fault isolation.

Async runtimes can’t really do preemptive scheduling so those end up using other methods that, while getting low latency, may not improve reliability or reduce variance in latency.

Orchestrating tasks across a number of different services that are not in your control becomes a distributed system where not everything is reliable.

Re: What I've Learned (So Far) Building Online Mini Games with Elixir and Swift

#20

Post by aquariusDue »

w10-1 wrote: post #16

> Also, I would encourage others to target Mac in addition to iOS for a reason you might not expect: build times. The simulators and Xcode are really pretty slow. It’s all a lot faster if you’re targeting Mac. Yes, this makes my day: (also) target macOS for continuous rapid loops on one project, or target iOS and end up flitting back and forth between many projects. ("mac (made for iPad)" does not work.)

Yeah, I do the same thing with Flutter when I'm in "rapid iteration mode" and build for desktop Linux in my case, though wireless debugging on Android is almost fast enough it's more that I don't want to dart back and forth between my laptop and phone.
Post reply on HN