s3cur3

The biggest thing missing from this analysis is "is there a business case for supporting those 2% of users?". (Maybe, maybe not.)

The second biggest thing is progressive enhancement. The author picked a CSS feature (nesting) that is basically all-or-nothing: the site will basically be entirely broken for those 2% if you swap Sass for native nesting. Most features aren't like that; maybe the site won't look pixel-perfect on old browsers, or one bit of functionality won't work, but by and large it will still be functional. In those cases, I think it's a much easier decision in terms of where to draw the cutoff.

Having been a happy customer of Blacksmith, Depot, and Ubicloud at various points (all three of which offer GitHub Actions runners at cheaper prices than GitHub themselves), I agree the billing here is weird. It's worth pointing out, though, that you have to use a lot of CI minutes to incur a $1000 bill. You're well outside of hobbyist levels, and that same level of usage would have previously cost double from GitHub themselves. This a business with serious compute needs, being asked to pay real money.

I dunno… it’d break a looooot of code if structs were suddenly not also maps. My bet is this becomes a new option you have to manually migrate to.

No sweat, I get it! :D

Author here! I've not been compensated by the Petal Pro devs at all. I've interacted with them exactly twice—once in support and once to submit the world's tiniest PR. I'm just a happy customer.

(If that's not enough, you can dig in to the Petal Components repo and see I'm not a contributor.)

I had no idea Gumroad et al. took their percentage on top of taxes. Seems shady.

It's... kind of his¹ thing. :) For instance: https://austinmeyer.com/why-does-god-hate-lancairs/

¹ Austin Meyer, creator of X-Plane

Enbala | Denver, CO / Vancouver, BC / Remote for strong candidates | Full-time | https://www.enbala.com

We're working to make the future of energy production more sustainable by helping energy utility companies balance the grid. This includes everything from helping lower peak energy usage (removing the need to, say, build an expensive new coal power plant that would only be run a few days a year) to balancing decentralized production from household solar.

Our back-end is written primarily in Elixir, and our front-end is Elm. We also have microservices running Python on AWS Lambda. We have a strong cultural focus on things that make devs' lives better day-to-day—things like testing, being kind & helpful to one another, code reviews that are valuable for both parties, continual improvement in our processes, etc.

Selected open roles at the time of this writing:

- Software Development Engineer in Test (SDET)

- Senior DevOps Engineer

- Senior Security DevOps Engineer

- Senior software engineer (Elixir)

- Senior software engineer (Python)

- UI/UX product designer

More info here: https://www.enbala.com/about/careers/

Enbala | Denver, CO / Vancouver, BC / Remote for strong candidates | Full-time | https://www.enbala.com

We're working to make the future of energy production more sustainable by helping energy utility companies balance the grid. This includes everything from helping lower peak energy usage (removing the need to, say, build an expensive new coal power plant that would only be run a few days a year) to balancing decentralized production from household solar.

Our back-end is written primarily in Elixir, and our front-end is Elm. We have a strong cultural focus on things that make devs' lives better day-to-day—things like testing, being kind & helpful to one another, code reviews that are valuable for both parties, continual improvement in our processes, etc.

Selected open roles at the time of this writing:

- Software Development Engineer in Test (SDET)*

- Senior DevOps Engineer

- Senior software engineer (Elixir)

- Senior software engineer (Python)

- Product owner

- UI/UX product designer

More info here: https://www.enbala.com/about/careers/

* On a personal note, we really value our QA folks and treat them well. (I think the posted salary range hints at that.) We want QA deeply involved with the whole software development lifecycle, rather than something that gets tacked on at the "end" (ha!) of development.

Enbala | Denver, CO / Vancouver, BC / Remote for strong candidates | Full-time | https://www.enbala.com

We're working to make the future of energy production more sustainable by helping energy utility companies balance the grid. This includes everything from helping lower peak energy usage (removing the need to, say, build an expensive new coal power plant that would only be run a few days a year) to balancing decentralized production from household solar.

Our back-end is written in Elixir, and our front-end is Elm. We have a strong cultural focus on things that make devs' lives better day-to-day—things like testing, being kind & helpful to one another, code reviews that are valuable for both parties, continual improvement in our processes, etc.

Selected open roles at the time of this writing:

- Senior devops engineer

- Senior software engineer

- Software engineer

- Product manager

- UI/UX product designer

More info here: https://www.enbala.com/about/careers/

Enbala | Denver, CO / Vancouver, BC / Remote for strong candidates | Full-time | https://www.enbala.com

We're working to make the future of energy production more sustainable by helping energy utility companies balance the grid. This includes everything from helping lower peak energy usage (removing the need to, say, build an expensive new coal power plant that would only be run a few days a year) to balancing decentralized production from household solar.

Our back-end is written in Elixir, and our front-end is Elm. We have a strong cultural focus on things that make devs' lives better day-to-day—things like testing, being kind & helpful to one another, code reviews that are valuable for both parties, continual improvement in our processes, etc.

Selected open roles at the time of this writing:

- Senior QA test automation engineer*

- Senior software engineer

- Software engineer

- Product manager

- UI/UX product designer

More info here: https://www.enbala.com/about/careers/

* On a personal note, we really value our QA folks and treat them well. (I think the posted salary range hints at that.) We want QA deeply involved with the whole software development lifecycle, rather than something that gets tacked on at the "end" (ha!) of development.

Enbala | Denver, CO / Vancouver, BC / Remote for strong candidates | Full-time | https://www.enbala.com

We help energy utility companies balance the grid. This includes everything from helping lower peak energy usage (removing the need to, say, build an expensive new coal power plant that would only be run a few days a year) to balancing decentralized production from household solar.

Our back-end is written in Elixir, and our front-end is Elm. We have a strong cultural focus on things that make devs' lives better day-to-day—testing, being kind & helpful to one another, code reviews that are valuable for both parties, continual improvement in our processes, etc.

Selected open roles at the time of this writing:

- Product manager

- QA test automation engineer

- Senior software engineer

- Software engineer

- UI/UX product designer

Learn more & apply here: https://www.enbala.com/about/careers/

Griefing, yes. The audience for our mobile app skews young and, shall we say, less "serious aviators" than the desktop sim, so to some degree people like that you can buzz a 747 on short final in an F-22. :D

Long-term we've talked about things like a reputation system, where flying responsibly would earn you points to get into a separate "world" filled with people who also want to do more serious flying.

In general, we send each player all the planes that their in-game map could possibly show (which is usually something like 140 statute miles by 140 statute miles).

We could one day be smarter about this and only send you everything if your map is actually open, and otherwise limit it based on your field of view. That hasn't been a priority yet, though.

The core of the X-Plane server is our RakNet UDP protocol, which is open sourced under the MIT license here:

https://github.com/X-Plane/elixir-raknet

It's not a full game server, but the "Usage" section of the README provides a sketch of what the rest of the server (the part that implements the business logic) looks like.

Correct! Sorry about that. :)

The limitation is more about the number of players we can have in the same area—if you had a bunch of players equally spaced around the globe, I'm pretty sure we'd saturate the Ethernet link before running out of CPU on a big (say, 32-core) VM. The CPU cost (and outbound network bandwidth) of a player scales with the square of the number of other players who can potentially "see" them.

In my scalability testing, we could handle upwards of 1000 players in the same 50 nm by 50 nm square on my 8 core dev workstation. That's pretty far beyond the limit of what would actually be _fun_ to fly the sim with. It becomes pandemonium even with 100 planes in the same area. We could easily do a dozen pockets of 100 planes in the same area even on our current 8 core VM.

This post on our dev blog gives some detail on the language decision here:

https://developer.x-plane.com/2021/01/have-you-heard-the-goo...

Sorry, to clarify, our thinking on this point was: our players aren't particularly motivated to lie to the server since there isn't a "goal" to a flight simulator. Given the choice between shipping (much, much) faster and completely locking down the experience against the vague, yet-to-be-realized threat of people sending fake packets to the server, we opted for the former.

YMMV, but:

- Memory consumption in production peaks at like 300 MB for us

- Scalability (i.e., being able to go wide on, say, a 64-core CPU) was more important to us than raw, synchronous speed

- Garbage collection is not something I've ever had to think about with Elixir (which hasn't been my experience with Python and Java)

- Because it's a sim and not something like a FPS, we don't have to worry about cheating (what would cheating even mean?), so we don't have to do any physics on the server side

- Despite being way more familiar with C++, I can't imagine going from zero to production in 6 months (or even 2 years) if we'd tried to do this in C++

Hey folks, I’m Tyler! I’m the guy who did the original work on this. I’m happy to answer any questions!

You might also be interested in the discussion happening on the associated Twitter thread: https://twitter.com/elixirlang/status/1420782381825503240

Here in Missouri (or rather in Missourah country), we have a ver-SAILS, MAH-l'n (Milan), New MAD-rid (Madrid), BALL-ah-ver (Bolivar), and La PLATE-ah (La Plata). :)

This. If your form is broken with autofill, your form is broken.

Not in C++ or Swift, no—to do it in the general case requires trying to cast each member of the array to the Derived type, and returning the null optional if any of those conversions fails.

E.g., given an array of Animal, you’d like to see if you can convert it to an array of Dog. Neither the compiler nor the runtime stores information on the array itself to say “it just so happens that the concrete Animal type of all the things I hold is [Dog/Cat/a mix of both],” so you have to go through the elements one by one.

True! It’s only an annoyance when you need to pass a std::vector<Derived> to a function that only accepts std::vector<Base>.

Swift's Array type is just so well designed. It's a delight to use.

Two things stood out to me here as being really nice for someone coming from C++:

- Implicit upcasting to convert `[Derived]` to `[Base]` in O(1).

- Checked conversions convert `[T]` to `[U]?` in O(N) via `a as [U]` in O(n).

These are both operations I've manually written the C++ code to do, because there's no ergonomic way to do it with `std::vector`.

Link to the (great) CppCon talk: https://www.youtube.com/watch?v=bSkpMdDe4g4

The one thing I would say is: as you dig more into C++ perf, you can develop an intuition for the kinds of things the compiler can and can't optimize. For instance, the C++ example from the article uses `std::unordered_map`, which is just an absolute mess from a cache locality perspective—the best compilers today (or of the foreseeable future) can't do a thing to fix that. Improving the programmer's choice of data structure is just not on the radar. :(

Reading that, I finally understood so many hours of debugging throughout my life.

Agreed. And the fact that disk access might end up being a bottleneck is not a good argument for making disk access APIs less ergonomic. I say give the programmer the nicest set of tools possible and let them make informed decisions about what’s appropriate to use when.

I think it’s important to note that the 3060 is not for sale yet. Nvidia is telling everyone up front that this is how it’s going to work.

The analogy is improved like this: Ford announces in advance that their upcoming truck requires a certain usage, and if you want whatever special commercial usage, you need to pay a premium. You might be grumpy about the upcharge, but this is a very different situation from them changing the terms of the deal after the sale.