Best practices can slow your application down

> The best practice would have been to build the parts which matter most in a language which allows them to be blazingly fast and write nice testable and easy to understand code. Something like Rust or Go. But no, they stuck with C# for god knows what reason

Whilst for work I've done approaching two decades of C#, for my own stuff I have largely used Go for years now so I'm far from an MS apologist, but that impression of C# is wrong. To be fair, the article leads partly to your conclusion so that's understandable.

C# with .Net Core, almost by design and by default, massively encourages "nice testable and easy to understand code" - much more so than most languages out there.

And unless the codebase is a hacked together monstrosity of the type that can be created using any ecosystem, .Net Core and C# are massively performant (pre-Core .Net was just about up there with some competitors but Core is in another league over the old Framework).

It's a shame that it doesn't have the mindshare outside of enterprise that it deserves, as C# on .Net Core basically gives you (practically, not syntactically) type-safe Node in terms of async/await, Go-like performance, Java-like power, and Ruby-like simplicity. Though to be honest it can take a fair while to advance from "hello world" given the atrocious naming and versioning mistakes Microsoft have made and how that impacts documentation and research.

That's interesting, it didn't used to be linear, particularly on the very large instances. Oddly when looking at the prices for RHEL those are much closer to what all the prices used to look like (I hadn't actually looked at AWS pricing in a few years). I wonder if AWSes virtualization tech has just reached the point now where all processing is effectively fungible and it's all really just executing on clusters of mid-range CPUs no matter how large your virtual server is.

C# is one of the best choice at the time (and still). Adopting Windows at the time is trade off.

> Go-like performance, Java-like power, and Ruby-like simplicity

You massively overestimate C#. Microsoft devdiv marketing is working.

I don't mean this as insulting, but let's think this through, with the exception of the scale SO is a forum (a QA where the OP post is a question - a topic in a forum - and the following posts are answers). It does have many details that were built throughout time (moderators, different exchanges, job posts, etc) that can significantly increase the complexity of it all when thought as a single platform, but it's nothing ground-breaking per se, even in 2008 (again, not saying that the scale and amount of exchanges and keeping all that working together non-stop is trivial or not worthy of note by itself).

But you can imagine that, perhaps, the slow down in what they can do with all these platforms - most developments seem to be things in separate bolted on to the main QA idea, others take a long time to see the light of day - is that it has become quite difficult/slow to move without breaking half of it? That would explain why they want to move towards writing code in a more testable manner.

I don't even need to experience their scale to know what the pains are of trying to refactor or add functionality to an existing code base that is untested and where I was the one writing the code - ALONE - it has happened to me, with my perfect code writing abilities and clear pure thought more than I would like to admit.

And the same is true when we talk about mocks and etc. Yeah, if you don't think in using them from the beginning it becomes usually really problematic to implement tests and mocks after the fact. You don't need to write them but your code needs at least to know they're going to be used and written in a way that does - the problem with this approach is that you really need to know what you're doing to write it in a way that is testable without writing the tests, so my takeaway from my own endeavours is, write the tests as they'll show you exactly if something is well or not written, because when you start digging deep into 3 nested layers and building complex mocks of responses to mock a signup you know something is wrong. If you don't do it from the beginning guess what, you would have to have studied whatever you're integrating with and written that mock (even if mentally) to write that code ANYWAY, with the difference being that now all that work you did went to the bin because it only exists the execution path. What you learned from it is nowhere to be used and provide small guarantees.

If you don't write them, once it's all working and working correctly, you're in a world of pain, and you're probably going to be overtaken at some point by something new that sees what you're doing and do it better (because in the end it's not rocket science) - the ones who can ignore this and can punt all the way usually have some deep pockets.

> If they where successful without test driven development then why do they need TDD? They were also funded in total up till now with $153M, one year after being beta they had a $6M funding. I think these kind of posts do a disservice. I know I said to myself "you don't need that, look at X doing without it". Sometimes I look at the industry and think we pat ourselves way too much on the back when we shouldn't.

As an example that isn't web based. I used to work with Adobe Suite, CS5/6 - as an aside the current experience for me is an awful thing, so awful that I went to GIMP instead - but forgetting that, for instance they had and still have a batch utility (Image Processor) to do bulk transform pipelines on collections of images through scripts recording your actions. It had and still has many small stupid things but it mostly worked well. At some point, they decided to do a better one and touted it as the replacement so they did. Result, it's way slower to operate and, guess what, it can only work on an image at a time. What? It does better compression of gifs for instance, but it can't do batch processing. There's tickets open for years asking for the batch processing. Not done. Probably won't ever be. The previous processor also didn't get the benefits of this new compressing algorithm. What? How can it be that switching the used algorithm on the old one or adding the ability to do multiple images is more than a one man month work?