One year after switching from Java to Go

Post by CharlieDigital » Wed, Feb 19, 2025, 12:27 PM UTC

lelanthran wrote: post #146

throwaway2037 wrote: post #100

Earlier quoted context omitted.

> The biggest selling point of Go to me is that I can usually just look at anyone’s code and know what it’s doing This is not possible in Java or C#? Both of those languages are so simple to grasp.

> This is not possible in Java or C#? Both of those languages are so simple to grasp. Not really, no. Apart from the cognitive burden of knowing the test framework in use, the DI tooling in use, the Mocking framework in use, plus all the annotations that each framework may want/need, almost none of which applies to the Go projects I've seen, the languages themselves have drifted away from simplicity. I used to progra…

Post by llm_nerd » Wed, Feb 19, 2025, 12:32 PM UTC

pjmlp wrote: post #169

This looks like one of the typical "we switched from A to B, whithout actually mastering A, so B is alright" kind of posts. Just on the monitoring part, Go has nothing even close to VisualVM, Flight Recorder, JRebel, VM agents, JMX. No mention of AOT compilers, JIT caches, and so forth.

Post by unscaled » Wed, Feb 19, 2025, 12:37 PM UTC

roncesvalles wrote: post #185

someothherguyy wrote: post #182

Earlier quoted context omitted.

So, write python in go instead, gotcha.

The idiomatic way to write Go is as naively as possible after you fully understand how it works. Otherwise it'll just feel like Java with shitty ergonomics. If you're ever writing Go and wish you had real classes instead of this deconstructed "mess" with struct types, methods, and interfaces, you're writing Go totally wrong.

Post by CharlieDigital » Wed, Feb 19, 2025, 12:41 PM UTC

dgunay wrote: post #35

epolanski wrote: post #26

Very ignorant about Go, is dependency injection not a thing there? E.g. I like declaring interfaces in other languages that model some service (e.g. the database), focus on the API, and then be able to provide different implementations that may use completely different technologies behind them. I know that some people don't see the point, but I'll make an example. At my primary client the database layer is abstracted…

DI in its most fundamental form is common in Go via interfaces. People just declare that arguments to their functions must implement some interface, and the caller provides something that satisfies it. "DI" in the sense of having a more complex purpose-built DI container is less common. They exist, but I don't see them used a lot. If your application code has a ton of dependencies, the direct injection/low magic styl…

    // Resolve the concreteImpl in DI
    IBlobStore concreteImpl = switch (config.BlobStoreType) {
        case "Azure": new AzureBlobStore();
        case "Aws": new AwsBlobStore();
        default: new FSBlobStore();
    };

    // Register
    services.AddSingleton(concreteImpl)
    services.AddScoped();
    services.AddScoped();

    // Services just use primary constructor and receive impl
    public class Svc1(IBlobStore store) { }
    public class Svc2(IBlobStore store) { }

    // But I can also manually supply (e.g. unit testing)
    var mockBlobStore = new MockBlobStore();
    var svc2 = new Svc2(mockBlobStore);

Post by pylua » Wed, Feb 19, 2025, 12:46 PM UTC

gf000 wrote: post #272

pylua wrote: post #66

Earlier quoted context omitted.

I’m also a long time java spring developer. I started writing a game recently and was really surprised about how bad the performance can be when you run it in a tight game loop. The startup time is also a real problem, as you really want to be able to scale up pods quickly. That said, it’s good enough right now. You can make it work at scale, and it’s worth the cost trade off of trying to do it more efficiently in a…

Could you expand on "how bad the performance can be" part? If you are doing graphics, it is entirely more likely that you do something dumb there - there are many pitfalls. Also, unless you are doing something very CPU-heavy, there won't be any noticeable difference as web servers are doing IO predominantly. Maybe slightly less RAM usage (but you could also just decrease the heapsize to tradeoff a bit of CPU-time for…