One year after switching from Java to Go

Agree. Go is a joy to use. Java is okay but struggles with scaling unless you have the money to burn for this.

To scale up servers in Java requires spinning up highly priced servers with lots of RAM, which that is a lot of money. Using a low spec server is cheaper but you will get more JVM crashes and have to waste time doing more JVM tuning to prevent them. This is not even talking about having lots of 'microservices' to scale which that also means more money spent per month.

Using Go just reduces all of that and saves lots of money and is extremely efficient enough to rely on and it directly compiles to a single binary for deployment.

From a cost and efficiency perspective, Java is just not the answer even though it is a sound language, unlike JavaScript or TypeScript. Given a choice I'd rather use Java or even Kotlin or JS/TS. But the cost reduction, performance gains and onboarding experience with Golang is hard to beat for backend.

Would stay really far away from JavaScript or TypeScript for anything backend.

> Would stay really far away from JavaScript or TypeScript for anything backend.

IDK, TypeScript types are extremely ergonomic, and if you're not overzealous makes everything very readable, and given many things are I/O bound anyway, it doesn't matter much.

Big problems for APIs though because TS types disappear at runtime.

So now you need to add in Zod or Valibot as well to validate your types. If you have view models and DTOs, then you add more Zod. Might as well use a statically typed language?

Working with OpenAPI is much easier when you already have a static type system.

How about database transactions? Ran into an interesting issue this week. In a .NET world, every ORM can participate in an ambient transaction because everyone uses System.Transactions. Not the case in Node because there's no such thing.

Would not build backends in TS except for true microservices. The ergonomics of a Nest.js vs .NET Web API are night and day.

> How about database transactions? Ran into an interesting issue this week. In a .NET world, every ORM can participate in an ambient transaction because everyone uses System.Transactions. Not the case in Node because there's no such thing.

I mean you could say the same thing about TypeScript - if your entire stack is TypeScript then there's no need for the type validation either.

Even if your entire stack is TS, you still need validation because the submitted data from an external interface (API call) might not be valid.

You can't just accept any JSON payload and expect it to be valid.

In Java or .NET, it will fail at serialization when the runtime tries to map it to a static type (automatic). This is not the case at runtime with JS (because at runtime, it's no longer TS). Thus you need a Zod or a Valibot to ensure the incoming payload is actually valid by describing the valid types (even if your whole stack is TS at dev time because schema mismatches are a runtime problem).

.NETs System.Text.Json does the mapping and validation using either reflection or AOT generated serializers transparently and automatically because it has static types.

I think CharlieDigital's point is that a bad payload will fail right at the serialisation boundary in case of .NET. We know the problem right there. Now we only need to fix the bad payload.

For TypeScript with only types and without validation, a bad payload gets through, and there is no telling where in the workflow it will explode. This could waste more time and developer resources in debugging.

Again this isn’t an inherent property of .net, you have to add validation. There are plenty of ways to do this in node so the point is moot.

Here is a .NET web API

    var builder = WebApplication.CreateBuilder(args);
    var app = builder.Build();

    app.MapGet("/{userId}", (int userId) => userId);
    app.Run();

See `int userId`? If I call this API with `http://localhost:5123/asdf`, I will get an error because the types don't match. If I call this with `http://localhost:5123/1234` it will work fine. The same would be true if I required a class `User` here. The router is able to introspect the type at runtime to determine if the types match; both basic types like this as well as complex types using the built-in serializer. It is built in.

I've put it into a short clip for you: https://imgur.com/a/WNbGUQD