Have anyone of you guys ever build a medium or large application with golang? I mean small services with 3000 lines of code are just fine but what about 10k, 20k or 100k loc? Does anyone has experience with such an app?

.

Yes.
about 30 microservices, around 20k loc.
Running into migration problems now, bc The idiots who rushed it to production.... never mind.

@magicMirror 20k loc each?

--[]
I

@magicMirror - curious here, is it in your mind more an issue of the people who built it or the language itself? Our 'technical advisor' wants us to migrate a big .NET app to something like go at some point... not sure if it is worth the time investment...

@fullstackchris i my opinion go has a big advantage in processes that involves data processing.
For example this process:
Incoming -> a -> b -> c -> outgoing
Where a b and c are goroutines that process data without order.
a, b and c can be starting themself or by an master routine new instances of these routines, so that the pipeline adapts itself to the incoming load.

@bosi No. A microservice with 20k lines is not a microservice. my project has a total of 20k lines across the microservice stack.

@fullstackchris Depends on your arch. Using Go has clear advantages when coding stongly typed, highly parrallel stuff, like lots of quick Rest calls, or cases where a single trigger event will cause large amounts of parallel processing. Go lacks generics - and you can can work around it, but .net tends to overuse generics - so it will be hard to rewrite stuff. Specailly when the devs are overusing generics.

The idiots I refer to, made code decisions a long time ago - and cut corners to deliver the thing. Caused lots of tech dept, that I have to pay....

@magicMirror now it's clear for me. So you are using multiple microservices instead of one larger app with all functions in one place.

So it seems that go was build for microservices and is used for exactly that. Thanks everybody :)

@bosi
.... Kind of hard to explain.
The idiot Architect I worked with, decided to use a single project, that has multiple Binary targets. each target is a Microservice, and all of them are wrapped into a single docker image. That project is 20kloc.

The reason for this, is to allow quicker changes to the Microservices Contracts. If we had any documented contracts....

@magicMirror doesn't this defeats the idea of microservices?

@stop Yes. Yes it does.
I tried to explain, but He "designed orgaincally".
It is not that bad, as some requirments are easy to implmenent, and version tracking is easy across the MS stack. But rolling updates are a nightmare.

@magicMirror oh wow. That sounds the worst. I can understand the basic idea for quick changes but this is nothing a well disigned ci pipeline cannot solve. Moreover you create overhead in communication.
If you want to put it all together in one place you directly can put it one app.

@stop Interesting... seems like a totally different paradigm compared to average .NET API programming...

@magicMirror hahaha our codebase is covered in generics :) we're screwed

@fullstackchris No worries. Go 1.18 due in feb/2022 will support generics. Kinda? think Java "type as a parameter".Your team might like it.

Also, take a look at class composition and interfaces in go.

@magicMirror wait a sec, I thought go doesn't have the notion of classes? Though I saw there are ways to write accessors that make types 'seem like classes'. I'm a mega newb though, only gone halfway or so through the "tour of go"

@fullstackchris both is correct. Go does not actually have classes but "structs" which can in some cases behave like classes. They can have methods or inherit from each other. The difference is that it's not called inherance bur composition. This sometimes feels like inherance but is more like gluing multiple structs into one.

@fullstackchris
@bosi
True - Go does not use the Class keyword. But they do have Interfaces, and Structs along with Struct Composition. And Interfaces have abstract methods, vs the concrete Methods implementation for structs. Also, Functions can be declared as types. When you want to add new functionality to an exsiting struct, you define a new struct, and embed the current one, adding new methods/fields as required.
What you cannot do - is override a method.

@magicMirror spent some more time this weekend looking into Go as an API... of course the first instinct I have coming from C# is to jump into the model / repository / service pattern - which may be halfway correct, I guess it's just MVC that is a bad idea with Go? I think service / repository patterns are still ok? Anyway, I kind of like the idea of writing many small first-class functions to organize your back end - it's similar how one would write modern React. (Plus you can easily write a huge variety of unit tests and be pretty sure everything works as it should) I've too long been in the camp (or rather, only heard repetitively) "the backend MUST be OOP, there is no other way!" but Go is enlightening me. :)

@fullstackchris
I'm not sure what you are talking about here. Any code organisation paradigm will work with Go. You can use MVC, you can use Dependency Injection, you can Mock/Test whatever you want. You can even use an event bus pub sub.

Just try to avoid "Enterprize Java" coding, where everything is abstract/factoried/singelton-ed to death, for a single concrete implementation. Go takes a much more direct approach when doing things.