I kind of agree with this. Data in a database is often relational (hey it might not be, but it's still nice to represent it in a struct sometimes, rather than 10–20 different variables which can change anytime your database changes).
I've been using Go recently, and while I'm not convinced on an active-record style ORM in Go (I don't think the language is dynamic enough, and I'm not the biggest fan of codegen), I've been loading the row data from Postgres into a Result struct (pretty much a 1:1 mapping of the Postgres result set into the struct), and then using another function to load the Result struct into struct with their relationships attached (using tags on the structs to define the relationships between them). This has worked great using reflections & generics.
We must have very different definitions of senior engineer from the GP, because I’d put the monthly cost of a senior engineer closer to $30k than $3k, even on a log scale.
Employing people requires insurance, buildings, hardware, support, licenses, etc. There are lower cost locations, but I can’t think of a single market on earth where there is a supply of senior engineers that cost $3k/month. And I say this being familiar with costs in India, China, Poland, Spain, Mexico, Costa Rica, and at least a dozen other regions.
Log scale is just going to distort the picture in favor of your argument nor against it (10 is closer to 3 than to 30, but in log scale 10 becomes closer to 30) so I don't really understand why you're adding that here.
Also having hired senior software engineers in Europe (France, Germany, Nederlands), if it cost you 30k a month in India or Poland, you're just being conned. “Hardware, support and license” are just bogus argument, as it's completely negligible unless you're doing exotic stuff requiring expensive licenses for your engineer. “Insurance” costs pretty much nothing in most of Europe because health insurance is mostly covered by the state, and “buildings” is mostly a self-inflicted wounds nowadays, especially since you'd get the better candidates if you supported full working from home.
The original 3k is indeed way too low, even for a junior developer, but 30k is equally ridiculous really as you should never really spend more than half of that outside of the US.
My personal problem with Kysely is that the migrations are not aligned with what I needed personally.
I would have wanted to see Kysely have the ability to generate migrations for example. I also personally prefer the approach that Drizzle takes when it comes to more adoption (in my case, CockroachDB).
Just a personal preference - the project is awesome.
Drizzle-kit, the migration part of drizzle is not open source, though they said they will open source it in future, but not at this point. Kysley is 100% open source, feature rich and more stable, again back to active development.
atlasgo io looks promising to handle migrations and is open source as well. I am currently using prisma.
To be honest, you're realistically taking a lot of risk. The second the Australian government decided to change/rework how the visa works, you could be in a bit of trouble. I would personally move towards getting something more stable. Multiple citizenships are usually quite nice to have anyway.
Hopefully if the Australian government changes the system, they'll grandfather it for existing residents. They've done that in the past, and New Zealanders who arrived before around 2002 are treated as permanent residents.
I do have an EU citizenship as well, and in fact I'd lose that if I became an Australian citizen.
