mxz3000

> Ignoring the fact that relational databases and SQL are permanently entrenched, an alternative database technology cannot succeed unless it also supports a high-level query language. The advantages of such a language are just overwhelming.

You seem to be ignoring the success of highly scalable managed NoSQL databases that has been all the rage when building high TPS services. What is your opinion on those?

What do you mean? If you compose functions (and objects) together then you have to mock things out one way or another, inject them in, and assert that your code interacts correctly with its dependencies.

This doesn't seem like a go specific issue but an engineering one.

But you can obviously DRY without inheritance?

I'm not sure that Go pushes you to duplicate code... Do you mean copy a slightly tweak code for different use cases and types ?

That made me chuckle

100% this. You can fix lots of small issues that would otherwise just be noise on the PR just by reviewing it yourself beforehand, as if it was somebody else's code!

When I onboard junior engineers, this is one of the things I tell them to do.

In my experience, most APIs my teamed designed/built were not meant to ever be publicly available. That is, we never considered public availability as a design factor. So I think this rule doesn't actually apply anymore.

Then again, I don't know how public availability would change the API design really...

Not all companies/teams have dedicated QA and Ops teams.

In the (very large) company I work at, the engineers are responsible for writing the code, testing it, and supporting it once it's live. That includes being Oncall and being paged if something goes wrong.

Tbh, That's why for our new projects we've completely ignored relational databases. They're a pain in the ass to manage and scale poorly.

DynamoDB, on the other hand, trivially scales to thousands (and more!) of TPS and doesn't come with footguns. If it works, then it'll continue to work forever.

The given, when, then breakdown is interesting, though I've never seen language test utilities actually enforce that structure. Maybe an interesting potential experiment (regardless of language) ?

I feel like your last point is especially important. Sooooo many times have I seen over-abstracted unit tests that are unreadable and are impossible to reason about, because somebody decided that they needed to be concise (which they don't).

I'd much rather tests be excessively verbose and obvious/straightforward than over abstracted. It also avoids gigantic test helper functions that have a million flags depending on small variations in desired test behaviour...

This. This allows sensitive data to never leave the storage layer.

I'm more than happy to lose the jack to get a bigger battery or thinner/lighter phone.

I'm never going back to wired headphones anyways, wireless is the future. Far too used to not having my head tethered to my phone (or laptop for that matter).

Working with multiple AWS accounts is definitely a pain, but it definitely should get better in the future given that it's a super important use case for internal services.

Internally we have best practices that dictate to split services into their own accounts, with one account per stage (i.e. beta, gamma, prod).

I'd like to also mention that CDK also makes working with cross-account/cross-stack resources a lot easier.

Do people actually use UML in industry?

I've never actually seen it used (or mentioned for that matter) in the few years I've been a software engineer...

If you're going all in on AWS, I'd recommend trying out CDK!

They definitely didn't replace oracle with dynamo, those are very different beasts and would require complete redesigns of the migrated service. RDS sounds much more appropriate/realistic.

That's where AWS CDK comes in, it's great. Infrastructure as (actual) code.

Typescript is the best supported language.

CDK is amazing, we use it in typescript and it's just great, so much easier than raw cloudformation or SAM.

I can't compare to TF as I have no experience with it, but I would assume CDK is better just because you can use a well established language (instead of some custom lang that needs to be learned)

I took this course during my time at Imperial. Tom Clarke is a great lecturer, and is actually passionate about teaching (which cannot be said about other lecturers...)

Totally, cloudformation is terrible and verbose. [Cloud Development Kit](https://aws.amazon.com/cdk/) however, is superb.

That's a pattern I use in a lot of Typescript, it's pretty useful!

This is exactly the sort of problem solved by cdk: https://docs.aws.amazon.com/cdk/latest/guide/home.html with cdk you generally don't have to mess with IAM constructs, and can just use the provided APIs to setup necessary permissions (and those permissions are always as narrow as possible by default)

When you're Oncall you aren't Oncall 24/7 forever. It usually rotates amongst the engineers in the team. I'm on a team with about 10 engineers in it so you're on call about a week every two months. I call that manageable.

Engineers should 100% be responsible for owning their code, and fixing any issues that arises from it. After all they're the ones that wrote it, aren't they the best people to fix it when it breaks?

Dynamo is great. All new projects I work on that require a db use it. We're slowly moving away from SQL databases entirely. Far more scalable, no more horrible SQL issues, at the cost of not being as flexible. But that's alright in the context of micro-services that do one thing and do it well/fast.

I guess the main issue is that languages outside of English generally don't have equivalent words for all of CS terms. I always have trouble explaining what I do (software engineering) in French without resorting to using English words, just because most words don't exist in French, or they don't mean exactly what you mean.

This reminds me that I can't stand people coding in languages other than English. Variable names/comments in French? No thanks.

Cheaper/faster hardware probably

Faster/cheaper hardware probably

Not op, but I have experience with TS and some things are more difficult than they should be. For me the biggest issue is the lack of typesafe deserialisation. This makes it super painful to do IO (of which there's _a lot_ of in the serverless infrastructure I'm currently working on). While you can validate with a manually written type guard, that's a pain... It would great if you could do JSON.parse<T>() and have TS auto-generate the type guard for you... There's also no easy way to switch on union types (à la ocaml), sure you can define an enum and use a JS switch, but that's not as nice, and enforcing exhaustiveness of the switch requires some type hackery with `never`...

+1 for CDK. It's the way forward. CloudFormation sucks.

I routinely go over 10GB of ram with a bunch of chrome tabs, IDE windows, Spotify, chat app, outlook, etc... It's really not hard.