Hi! This is a little microproject I want to do: I want to compress my years of experience building the API backend of a top-50 Steam game into a bunch of weird, rambling advice that I can deliver with all of the authority of someone who can’t differentiate success due to merit from success due to luck.
I’m really enjoying learning about Elixir, and Phoenix. They constitute, in my opinion, an extremely thoughtfully designed language and framework. So far my biggest gripe about the language is that prominent library developers keep choosing names for their products and libraries that are not terribly Google-able. “Phoenix”? “Hex”? “Cowboy”?
Anyways, Phoenix got really popular in 2017, at which point it seemingly dropped off of the face of the planet.
I want to put that wholly at the feet of their pursuit of Phoenix LiveView, a stack so fundamentally cursed that it undoes almost every iota of goodwill earned from Phoenix or Elixir.
about once every ten thousand years, the prophecy states a frontend developer will realize that they spend most of their time carefully using RPCs to curate a little miniature in-client database in order to keep their UI data up-to-date and sane,
and, in an effort to solve this problem for themselves in perpetuity, end up nerd sniping themselves for multiple consecutive years on a synchronization or complex query solution to perma-solve this problem, like Meteor.js or GraphQL
These solutions tend to be so powerful that they make simple applications like the well known Todo App seem almost magically trivial
but the black-box, complex and highly bespoke nature of these solutions keeps them niche: RPC over HTTP is a well-understood model for a reason, it’s much harder to reason about access control or rate limiting in a Custom Sync Protocol made by Some Guy
it’s even worse when, once every ten thousand years, a backend developer decides that they will refuse to learn Javascript and end up inventing some fabulously, wildly elaborate system to write everything in a unified environment
like ASP.NET WebForms or Elixir’s Phoenix Live Views
part of my job remains explaining to people that MongoDB and JavaScript are good, actually
a thing that, after many years, I well and truly believe, now
no, really! they’re good! there have been instances in the past of them not being good but they actually can be used to build very impressive services at scale!
you have to learn to write MongoDB like you would Cassandra/Scylla/Dynamo a little bit, though
the thing you lose going to Mongo from a SQL database is “joins”, but - if you’re building a system that needs to write-scale, you’re not going to be able to use joins anyways, joins won’t work across shards, so maybe you should be considering “only application side joins and as few of them as possible” from the get-go anyways
of course, “building with scale in mind from the outset” is a bad strategy for most products because honestly: the chance any given product is going to NEED to scale that big is like 1/1000, most companies literally just need POSTGRES and then SQL already has decades of lore and understanding and tooling behind it
use postgres, dummy
but the fact that we started with Mongo and built with Mongo and now have a product that’s on Mongo is not a bad thing, and is, in fact, better than if we had a hugely interconnected SQL database that we had to try to unknot every time write performance against a table became a problem
each individual Mongo collection is an utterly self-contained entity that can live on a completely different server, if necessary
did you know you can just take a problem table and move it to its whole own cluster? it’s expensive but try and do that with something that has a load of joins pointed at it and you’ll discover why that’s not often a viable strategy in SQL land
and you know what? Mongo’s schemaless, flexible design and easy post-hoc application of indexes to remedy slow queries? that creates a pretty buttery smooth experience to develop an experimental new product with.
In lots of systems, you don’t need a load of joins anyways: do you really ACTUALLY have a lot of relationships or does everything just have the single back-link to a “userId”?
In many cases, you have nested relationships, like a TodoGroup filled with Todos, but
wait a minute, that can just be a nested object, sharded by userId.
As for JavaScript, most of the haters are hating on the JavaScript of 2004 and a couple of NaN memes they saw once. Digging in nowadays, JS is, IMO, equivalent in its power and expressiveness to Python, but with a much clearer model for cooperative multitasking. Not a lot of folks out there hating on Python.
“Oh, template based inheritance is bad” yeah, well, so are deeply nested inheritance hierarchies which are basically impossible to build in JS thanks to its comparatively slim object model.
I will say that I’m not in love with TypeScript: if you want strict, static typing there are languages that do it way, way better, why not just use one of those? C#, or Rust, or Kotlin, or hell, just admit you’re a Java developer.
the tow capacity of a Miata is a sternly worded note in the manual saying “no”
“do not do this, it is an extremely bad idea”
of course, most folks on the internet perceive that as a challenge which is why there are loads of pictures of Miatas towing things, presumably out of spite
This might be one of my more controversial opinions, but…
JavaScript doesn’t benefit much from having a whole-ass type system bolted on a la TypeScript. It’s like attaching a tow-ball hitch to a Miata: just adding the capability doesn’t make it practical to use. JavaScript is not the right environment for type safety.
If you want byzantine type safety, just program in a language that was designed from the ground up with byzantine type safety in mind, like Rust, or C#, or Scala.
the thing I like about javascript conferences is that they only have one room for talks but they just get whoever’s on the mic at any given time to hand it over when they need time to set something up, so you can quickly catch loads of talks so long as you don’t mind that they’re in kind of a jumbled order
the thing I like about C conferences is that if you find the end of a line and stand two spaces behind it, the building will explode
the thing I like about Erlang conferences is that if anything goes wrong in one of the rooms, everyone will just leave, get back into the room, and pretend like nothing happened
i can’t remember what I liked about memcached conferences because there was a power outage
the thing I like about rust conferences is that they’re a huge amount of effort to set up but once they do they run really smoothly
the thing I like about PHP conferences is that they’re easy for anybody to set up and that it’s really hard to predict what will happen at them, which is also a thing that a lot of people do not like about PHP conferences
the thing I like about Go conferences is that they’re exactly like C conferences, but with a guy who comes around and collects the garbage every now and again
the thing I like about Postgres conferences is the consistency, but they only ever throw the one and honestly if they can’t find a bigger venue they’re going to start running out of space
i’m not such a big fan of AWS conferences, they seem reasonably priced at first but then you wander from one region to another and suddenly you owe them fourty eight thousand dollars
i’ve never managed to get in to a RabbitMQ conference but I’ve had a great time just waiting in line for one
I wasn’t sure which mastodon conference to attend, there were so many and most of them seemed like they were run by amateurs, so I just went to the biggest one
the thing I like about lisp conferences is that there aren’t a lot of standards or guidelines for them so each of the big ones just kind of makes up its own rules
the thing I like about retro emulation conferences is that you go into a huge, modern conference hall and they’ve set up a perfect recreation of a conference from 1993 in there, all the way down to the carpeting
the thing I like about roguelike conferences is that if you miss a talk you just have to leave
the thing I like about VC-funded conferences is how fun they are in the first few years, before they inevitably need to justify their massive investment and start to get weird
the thing I like about C# conferences is how much they improved over Java conferences, which they were clearly modeled after, but honestly I haven’t seen or thought about either in years and I think I’m a lot happier for it
the thing I like about scrum conferences is that they’ve clearly never put any more than two weeks worth of effort into planning them so they’re always just all over the place
(I would, of course, refuse to attend any scrum conference that took more than 2 weeks to plan: that would just be a waterfall conference and who wants to go to one of those?)
I attended a pure functional programming conference and as a result I changed my mind about functional programming, which , when I think about it, means it can’t have been a pure functional programming conference after all.
The thing I like about quantum computing conferences is that they’re run in a lot of different states at the same time
The thing I liked about AI conferences in the 80s were that you could set your booth up in a part of the conference hall that nobody could get to, and, in doing so, bring the entire convention to a halt.
my myers-briggs type is [Object object]