Systems engineering is an established discipline, one you can get a degree in. It’s not just a random term I’m making up. https://en.m.wikipedia.org/wiki/Systems_engineering

I don’t think you really have a choice TBH. Trying to do something like that sounds like a world of pain, and a bunch of unidiomatic code. If you can’t actually support 4 to 10 languages, maybe you should cut back on which ones you support?

To be clear, the SDKs themselves are hand-written; I'm not trying to do anything fancy there. In terms of designing and writing the SDKs, we can manage that for the 4 we have now. The issue is testing. The main system is a collection of services that are accessed via an API. That API can be accessed directly through function calls, or via HTTP or RPC. Our integration tests interact with the system through that API. The SDKs have a moderate amount of logic so they're not simple HTTP/RPC clients, but maintaining multiple (idiomatic) versions of that logic is not too much of a burden. The issue is that I want a single test corpus that I can use to validate each SDK without having to rewrite that test corpus in each language. Ideally I'd like the integration tests to be that test corpus.

If neither of those approaches works, everything speaks C FFI, and Rust is a modern language that would work well for presenting a C FFI that the other languages can use. You’re probably not hot on the idea of rewriting your Go tests into another language, but I think that’s your only real option then.

I was assuming I'd need to rewrite my tests in Go given that Go's FFI support for anything other than C is not somewhere I want to go again. I have been meaning to learn Rust so I might just do that.

I absolutely prefer using an ORM for querying but I'm definitely never letting the ORM create the schema for me. I will always do that myself and generate the ORM definitions from SQL, and I will never use an ORM that doesn't have that as an option.

I wouldn't say it was a shit university, part of it is that I knew how to write code before I got there. But the CS program wasn't great. My entire point is, if someone has a CS degree from University X and you don't know if that program at that university is any good, the degree is meaningless. If the university's CS program isn't any good, you can't count on the degree meaning anything.

I like .NET, Visual Studio Code, and SQL Server. The rest is garbage.

Many people ‘learn programming’ only in so much as they know how to write code but they can’t solve a problem to save their life.

And while I wouldn’t say anyone is incapable of learning programming, some people certainly have a much, much harder time of it.

Are you saying the only good programmers are ones who aren’t aware of their worth and think they’re bad?

I’d have to be living under a particularly large rock to be unaware of that. “It’s memory safe” isn’t that big of a deal to me. Even building concurrent systems, memory safety has never been a significant issue for me with Go.

Interesting, but I have no interest in retraining myself when I have tools that already work

Yes. It is still entirely possible to run VSCode or VSCodium locally without any of that cloud crap.

Maybe I'm misunderstanding what "dependency injection" means. When I hear "dependency injection" I think of a DI framework such as Unity, so I thought "using DI" meant using one of those frameworks.

What does Go’s simplicity have to do with dependency injection?

In my experience, following Go's philosophy of simple solutions eliminates the need for complex solutions such as dependency injection.

How do you unit test your extremely complex projects if your business logic carries the additional responsibility of creating objects?

I write modular code that accepts interfaces so I can test the components I want to test. The vast majority of object creation happens at initialization time, not in the business logic. For the projects I've worked on, that would be true with or without DI - I don't see how that's relevant.

perhaps your “extremely complex projects” wouldn’t be so extremely complex if you practiced dependency injection?

When the CTO says, "Make it distributed and sharded," I do what I'm told, but that is an intrinsically complex problem. The complexity is in the overall behavior of the system. If you zoom in to the individual execution units, the business logic is relatively simple. But the behavior of the system as a whole is rather complex, and DI isn't going to change that.

Edit: I was interpreting "using DI" to mean using a DI framework such as Unity, and I would be happy to never need one of those frameworks ever again.